DebugViewPP
DebugViewPP copied to clipboard
CobaltFusion
Show a 'busy' dialog when the UI is blocked for a long time
The UI blocks if a new exclude filter is added and there are 10 million lines in the buffer (600mb).
We could process in the background, but alternatively, probably a good notification of the user like 'Please wait while applying filters to xxx lines...' would be fine. This would also make the user understand why it takes a while.
The UI also blocks in case a large file is dragged into debugview (example: 190 MB log file from dbgview)
Proposal interface: (pseudo code)
void CLogView::ApplyFilters()
{
ProgressDlg dlg;
dlg.dispatch ( [this]
{
while (line < count)
{
// do stuff
++line;
if (dlg.IsCanceled()) break;
}
m_logLines.swap(logLines);
});
if (dlg.DoModal() != IDOK)
{
m_logLines.clear();
}
}
Proposal UI:
Ziet er fancy uit maar vereist een extra thread in de ui. Dat opent het gevaar van races, deadlocks en performance problemen door alle extra thread synchronisatie.. Wat gebeurt er bijvoorbeeld met de live logging terwijl deze actie loopt? Ik vind optimale performance van live logging belangrijker dan load/save acties.
G-J
On 15 Sep 2015, at 20:01, Jan Wilmans [email protected] wrote:
@djeedjay https://github.com/djeedjay ik wou hier eens naar kijken, hoe lijkt dit voorstel?
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140484082.
Zou een file loader niet een asynchrone LogSource kunnen zijn? Zo blijft de UI live terwijl de loader op eigen tempo messages blijft toevoegen. Misschien moet een LogSource zijn progress in de status bar kunnen tonen.
Gert-Jan
On 15 Sep 2015, at 20:10, Gert-Jan de Vos [email protected] wrote:
Ziet er fancy uit maar vereist een extra thread in de ui. Dat opent het gevaar van races, deadlocks en performance problemen door alle extra thread synchronisatie.. Wat gebeurt er bijvoorbeeld met de live logging terwijl deze actie loopt? Ik vind optimale performance van live logging belangrijker dan load/save acties.
G-J
On 15 Sep 2015, at 20:01, Jan Wilmans <[email protected] mailto:[email protected]> wrote:
@djeedjay https://github.com/djeedjay ik wou hier eens naar kijken, hoe lijkt dit voorstel?
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140484082.
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
Het is geen extra UI thread, De UI blockt, net als normaal, er komen dus geen timer-events binnen die de logsource input binnenhaald, dus geen race-conditions. Het verschil is dat we nu de UI thread zelf blocken met een Model-progress dialog, en de activiteit op een thread starten.
Ik zie de load/save acties nu ook niet goed samenwerken met live-logging, dus in dat opzicht veranderd er niets. Bovendien zie ik de load/save acties voor de use-case waar je post-mortem een logfile inlaad in een losse instantie van debugview, de live-activiteit, blijft dan gewoon werken in een andere instantie.
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans [email protected] wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225.
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos [email protected]:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans [email protected] wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113 .
Met vriendelijke groeten,
Jan Wilmans
In dat opzicht vind ik het ook niet erg als je even moet wachten, maar wel als niet weet hoelang dat gaat duren en de applicatie 'not responding' zegt.
Groeten,
Jan
2015-09-15 20:38 GMT+02:00 Jan Wilmans [email protected]:
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos [email protected]:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans [email protected] wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113 .
Met vriendelijke groeten,
Jan Wilmans
Met vriendelijke groeten,
Jan Wilmans
Er zijn toch ook echt asynchrone LogSources, anders zou tail of pipe from process niet kunnen werken. Wellicht is dan de ui unresponsive omdat de de log data constant gelockt is voor de updates. Als de ui thread niet kan draaien kunnen we ook geen progress tonen.. Ik moet het probleem eerst maar eens zien om te begrijpen wat het probleem is. Hoe zie je dit het gemakkelijkst voor mensen die niet het wereldrecord logging proberen te verbeteren?
G-J
On 15 Sep 2015, at 20:41, Jan Wilmans [email protected] wrote:
In dat opzicht vind ik het ook niet erg als je even moet wachten, maar wel als niet weet hoelang dat gaat duren en de applicatie 'not responding' zegt.
Groeten,
Jan
2015-09-15 20:38 GMT+02:00 Jan Wilmans [email protected]:
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos [email protected]:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans [email protected] wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113 .
Met vriendelijke groeten,
Jan Wilmans
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140494458.
GJ: waarom File->Open nog synchroon zijn als je al een asynchrone loader hebt? Jan: klopt, moeten we gewoon met de asynchrone loader doen, met een vinkje voor 'keep tailing'. Ik heb dat getest (drag& drop een 150MB files op debugview) en dat gaat prima, geen blocking ui.
Dan blijft over het scenario dat je de logging al in memory hebt en een filter veranderd. Dat blokkeert nog wel steeds de UI.
Dan moet er dus nog een in memory log to view LogSource lomen :)
G-J
On 16 Sep 2015, at 21:51, Jan Wilmans [email protected] wrote:
GJ: waarom File->Open nog synchroon zijn als je al een asynchrone loader hebt? Jan: klopt, moeten we gewoon met de asynchrone loader doen, met een vinkje voor 'keep tailing'. Ik heb dat getest (drag& drop een 150MB files op debugview) en dat gaat prima, geen blocking ui.
Dan blijft over het scenario dat je de logging al in memory hebt en een filter veranderd. Dat blokkeert nog wel steeds de UI.
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140868054.
Hm, daar had ik nog niet aan gedacht, waarom niet eigenlijk, de logfile administratie is movable.
Groeten,
Jan
2015-09-16 22:11 GMT+02:00 Gert-Jan de Vos [email protected]:
Dan moet er dus nog een in memory log to view LogSource lomen :)
G-J
On 16 Sep 2015, at 21:51, Jan Wilmans [email protected] wrote:
GJ: waarom File->Open nog synchroon zijn als je al een asynchrone loader hebt? Jan: klopt, moeten we gewoon met de asynchrone loader doen, met een vinkje voor 'keep tailing'. Ik heb dat getest (drag& drop een 150MB files op debugview) en dat gaat prima, geen blocking ui.
Dan blijft over het scenario dat je de logging al in memory hebt en een filter veranderd. Dat blokkeert nog wel steeds de UI.
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140868054 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140872120 .
Met vriendelijke groeten,
Jan Wilmans
alle logsources zijn asynchronous...
On Tuesday, 15 September 2015, Gert-Jan de Vos [email protected] wrote:
Er zijn toch ook echt asynchrone LogSources, anders zou tail of pipe from process niet kunnen werken. Wellicht is dan de ui unresponsive omdat de de log data constant gelockt is voor de updates. Als de ui thread niet kan draaien kunnen we ook geen progress tonen.. Ik moet het probleem eerst maar eens zien om te begrijpen wat het probleem is. Hoe zie je dit het gemakkelijkst voor mensen die niet het wereldrecord logging proberen te verbeteren?
G-J
On 15 Sep 2015, at 20:41, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
In dat opzicht vind ik het ook niet erg als je even moet wachten, maar wel als niet weet hoelang dat gaat duren en de applicatie 'not responding' zegt.
Groeten,
Jan
2015-09-15 20:38 GMT+02:00 Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub <
https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225
.
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113> .
Met vriendelijke groeten,
Jan Wilmans
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140494458 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140501778 .
Met vriendelijke groeten,
Jan Wilmans
Met dit alternatief voor CFileDialog heb je een file open box met een “Keep file open” vinkje :) Succes!
Gert-Jan
class CMyFileDialog : public CFileDialogImpl<CMyFileDialog> { public: CMyFileDialog(BOOL bOpenFileDialog, // TRUE for FileOpen, FALSE for FileSaveAs LPCTSTR lpszDefExt = nullptr, LPCTSTR lpszFileName = nullptr, DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, LPCTSTR lpszFilter = nullptr, HWND hWndParent = nullptr) : CFileDialogImpl<CMyFileDialog>(bOpenFileDialog, lpszDefExt, lpszFileName, dwFlags, lpszFilter, hWndParent), m_keep(false) { }
bool Keep() const
{
return m_keep;
}
BEGIN_MSG_MAP(CMyFileDialog)
MSG_WM_INITDIALOG(OnInitDialog)
MSG_WM_DESTROY(OnDestroy)
CHAIN_MSG_MAP(CFileDialogImpl<CMyFileDialog>)
END_MSG_MAP()
private: BOOL OnInitDialog(CWindow /wndFocus/, LPARAM /lInitParam/) { SetControlText(chx1, L"Keep file open"); return TRUE; }
void OnDestroy()
{
m_keep = GetReadOnlyPref() != FALSE;
cdbg << "Keep open: " << m_keep << "\n";
}
bool m_keep;
};
On 16 Sep 2015, at 22:35, Jan Wilmans [email protected] wrote:
alle logsources zijn asynchronous...
On Tuesday, 15 September 2015, Gert-Jan de Vos [email protected] wrote:
Er zijn toch ook echt asynchrone LogSources, anders zou tail of pipe from process niet kunnen werken. Wellicht is dan de ui unresponsive omdat de de log data constant gelockt is voor de updates. Als de ui thread niet kan draaien kunnen we ook geen progress tonen.. Ik moet het probleem eerst maar eens zien om te begrijpen wat het probleem is. Hoe zie je dit het gemakkelijkst voor mensen die niet het wereldrecord logging proberen te verbeteren?
G-J
On 15 Sep 2015, at 20:41, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
In dat opzicht vind ik het ook niet erg als je even moet wachten, maar wel als niet weet hoelang dat gaat duren en de applicatie 'not responding' zegt.
Groeten,
Jan
2015-09-15 20:38 GMT+02:00 Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub <
https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225
.
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113> .
Met vriendelijke groeten,
Jan Wilmans
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140494458 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140501778 .
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140882991.
Precies wat ik nodig had, ik zal het implementeren.
Groeten,
Jan
2015-09-16 23:12 GMT+02:00 Gert-Jan de Vos [email protected]:
Met dit alternatief voor CFileDialog heb je een file open box met een “Keep file open” vinkje :) Succes!
Gert-Jan
class CMyFileDialog : public CFileDialogImpl<CMyFileDialog> { public: CMyFileDialog(BOOL bOpenFileDialog, // TRUE for FileOpen, FALSE for FileSaveAs LPCTSTR lpszDefExt = nullptr, LPCTSTR lpszFileName = nullptr, DWORD dwFlags = OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, LPCTSTR lpszFilter = nullptr, HWND hWndParent = nullptr) : CFileDialogImpl<CMyFileDialog>(bOpenFileDialog, lpszDefExt, lpszFileName, dwFlags, lpszFilter, hWndParent), m_keep(false) { }
bool Keep() const { return m_keep; }
BEGIN_MSG_MAP(CMyFileDialog) MSG_WM_INITDIALOG(OnInitDialog) MSG_WM_DESTROY(OnDestroy) CHAIN_MSG_MAP(CFileDialogImpl<CMyFileDialog>) END_MSG_MAP()
private: BOOL OnInitDialog(CWindow /wndFocus/, LPARAM /lInitParam/) { SetControlText(chx1, L"Keep file open"); return TRUE; }
void OnDestroy() { m_keep = GetReadOnlyPref() != FALSE; cdbg << "Keep open: " << m_keep << "\n"; }
bool m_keep; };
On 16 Sep 2015, at 22:35, Jan Wilmans [email protected] wrote:
alle logsources zijn asynchronous...
On Tuesday, 15 September 2015, Gert-Jan de Vos <[email protected]
wrote:
Er zijn toch ook echt asynchrone LogSources, anders zou tail of pipe from process niet kunnen werken. Wellicht is dan de ui unresponsive omdat de de log data constant gelockt is voor de updates. Als de ui thread niet kan draaien kunnen we ook geen progress tonen.. Ik moet het probleem eerst maar eens zien om te begrijpen wat het probleem is. Hoe zie je dit het gemakkelijkst voor mensen die niet het wereldrecord logging proberen te verbeteren?
G-J
On 15 Sep 2015, at 20:41, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
In dat opzicht vind ik het ook niet erg als je even moet wachten, maar wel als niet weet hoelang dat gaat duren en de applicatie 'not responding' zegt.
Groeten,
Jan
2015-09-15 20:38 GMT+02:00 Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Ja, de asynchrone loader kan prima met een '[ ] keep tailing' vinkje, vind ik een goed voorstel. Neemt niet weg dat progress dialoog ook nodig is voor bijvoorbeeld als je +100MB in-memory logging hebt en je veranderd een filter. De usecase van de 'grote logfile' is niet een default (zelfs niet bij FEI :), dat scenario is bv. het resultaat van een duurtest van dagen.
Groeten,
Jan
2015-09-15 20:28 GMT+02:00 Gert-Jan de Vos < [email protected] javascript:_e(%7B%7D,'cvml','[email protected]');>:
Waarom zou File->Open nog synchroon zijn als je al een asynchrone loader hebt? Dat open houden van een file zou wel een non-default optie moeten zijn. Een vinkje op de Load dialog of gewoon een ander menu item: Connect File ofzo.
Is er in geval van zo'n asynchrone loader nog behoefte aan zo’n progress box?
Zoals je weet heb ik nooit zo absurd grote log files. Voor mij is een log van 1 MB al extreem. Ik heb dan ook geen bricks..
G-J
On 15 Sep 2015, at 20:20, Jan Wilmans <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:
File->open is een andere actie, dan drag&drop, misschien moeten we dat veranderen, File->open leest nu de file in. Terwijl drag&drop een logsource maakt en blijft tailen. (dus als de logfile groeit, dan zie je dat)
— Reply to this email directly or view it on GitHub <
https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140489225
.
— Reply to this email directly or view it on GitHub <
https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140491113>
.
Met vriendelijke groeten,
Jan Wilmans
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub <
https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140494458
.
— Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140501778> .
Met vriendelijke groeten,
Jan Wilmans — Reply to this email directly or view it on GitHub < https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140882991 .
— Reply to this email directly or view it on GitHub https://github.com/djeedjay/DebugViewPP/issues/162#issuecomment-140896637 .
Met vriendelijke groeten,
Jan Wilmans