Crt Class / :setDisplayFocus / Debugger

[AUGE_OHR]

hi,

Ich habe in meiner Xbase++ Hybrid Anwendung eine eigene Crt Class
die jeweils als Thread läuft. Zum "steuern" der Threads verwende ich
Tabpage oder XbpPushbutton damit nur jeweils ein Thread aktive ist
und kann per SAY/GET bearbeitet werden während die anderen Threads
im Signal:wait() Modus sind. Ich muss aber für jeden inaktiven Thread
die Workspacelist, RECNO() etc. sichern da die Hybridanwendung ja
den "alten" prozeduralen Cl*pper Code verwendet.

Nachdem das ganze nun funktioniert will ich mehr ... Nun soll ein Crt
durch anklicken aktiviert werden als wenn ich auf den Button clicken
würde. soweit sogut aber nun hab ich beim debuggen Probleme

Code: Alles auswählen

   ::oCrt:killDisplayFocus := {| x,y,oObj | ::aArea := SaveWorkSpace() }
   ::oCrt:setDisplayFocus  := {| x,y,oObj | MyCoffee( ::IDno ,aTabObj) }

während das :killDisplayFocus keine Probleme macht, komme ich beim
:setDisplayFocus immer wieder in die Debugger Schleife in MyCoffee()
wenn ich aus dem Debugger in die Anwendung clicke die hinter dem
Debugger liegt ...

Als workaround hab ich die Auflösung des Monitors auf 1920 gestellt damit
ich die Anwendung und den Debugger nebeneinander sehen kann.

mache ich mit :setDisplayFocus() irgend einen Irrtum den ich nicht
bedacht habe ?

gruss by OHR
Jimmy

[brandelh]

h

Code: Alles auswählen

   ::oCrt:killDisplayFocus := {| x,y,oObj | ::aArea := SaveWorkSpace() }
   ::oCrt:setDisplayFocus  := {| x,y,oObj | MyCoffee( ::IDno ,aTabObj) }

während das :killDisplayFocus keine Probleme macht, komme ich beim
:setDisplayFocus immer wieder in die Debugger Schleife in MyCoffee()
wenn ich aus dem Debugger in die Anwendung clicke die hinter dem
Debugger liegt ...
...
mache ich mit :setDisplayFocus() irgend einen Irrtum den ich nicht
bedacht habe ?

in dem Moment wenn du vom Debugger auf das CRT klickst, wird dort der Event ausgelöst und erneut MyCoffee aufgerufen. Gerade in diesen Situationen (events) ist das Debuggen z.Z. zumindest nicht einfach ...
Ich nutze hier die gute alte ALTERNATE Datei (auch bei NUR GUI Anwendungen !):

Code: Alles auswählen

set console off   // wichtig, falls nur GUI !
set alternate to xxxx  (additive ?)
set alternate on

? "wo bin ich, was ist der wert von ",cTest

set alternate to

[AUGE_OHR]

hi,

in dem Moment wenn du vom Debugger auf das CRT klickst, wird dort der
Event ausgelöst und erneut MyCoffee aufgerufen. Gerade in diesen
Situationen (events) ist das Debuggen z.Z. zumindest nicht einfach ...

jaja genau das ist das Problem ...

Ich nutze hier die gute alte ALTERNATE Datei (auch bei NUR GUI Anwendungen !):

Code: Alles auswählen

set console off   // wichtig, falls nur GUI !
set alternate to xxxx  (additive ?)
set alternate on
? "wo bin ich, was ist der wert von ",cTest
set alternate to

hm ... ja ... damit komme ich zwar an die Variabeln aber ich kann nicht
"sehen" was das Programm macht

jemand vielleicht noch eine Idee ?
gruss by OHR
Jimmy

[brandelh]

hm ... ja ... damit komme ich zwar an die Variabeln aber ich kann nicht
"sehen" was das Programm macht

jemand vielleicht noch eine Idee ?

Hallo Jimmy,

doch genau das kann man dann sehen, wenn man die ? mit sinnvollen Texten und Variablen bestückt
und die Protokolldatei danach ansieht.
Dort steht genau drin wo das Programm in welcher Reihenfolge war.
Im Extremfall drucke ich mir die Ausgabe aus und gehe Schritt für Schritt
durch den Quellcode. Meines Wissens (habe ich aber noch nicht gemacht) geht das auch über mehrere Threads.

Wer eine bessere Idee hat möge sich melden.
Besser als unser Debugger ist es alle mal.

[Günter Beyes]

Hallo,

ich verwende in solchen Fällen ein Tool von SysInternals (jetzt Microsoft) namens DebugView. Es dient der Anzeige von Debugmeldungen, die von der untersuchten Anwendung mit Hilfe der der API-Funktion OutputDebugString() abgesetzt werden. DebugView kann auch als Remote-Debugger auf einem anderen Rechner im Netzwerk ausgeführt werden, z.B. wenn es auf dem Bildschirm eng wird und speziell natürlich wenn Fokuswechsel-Eventhandler debugged werden sollen.

Um zu verfolgen, was die untersuchte Anwendung treibt, füge ich an den interessanten Stellen die Zeile
"DebOut( <cMeldung> )" in den Source ein, ggf. umgeben von #ifdef DEBUG ... #endif

z.B. in einer aufgerufenen Funktion gleich als erste Zeile

Code: Alles auswählen

DebOut(  "Start " + procname() )

und vor RETURN

Code: Alles auswählen

DebOut( "Ende " + procname()  )

DebugView gibt es hier: http://www.microsoft.com/technet/sysint ... gview.mspx

Wichtig: Wenn die Anwendung unter XppDbg läuft, zeigt DebugView nichts an. Offenbar hat XppDbg als Empfänger solcher Meldungen Vorrang -- schluckt sie aber, ohne sie anzuzeigen.

Viele Grüße,
Günter

Code: Alles auswählen

FUNCTION DebOut( cString )
STATIC tpl
IF tpl = NIL
   tpl  := DllPrepareCall( "kernel32.dll", DLL_STDCALL, "OutputDebugStringA" )
ENDIF
RETURN DllExecuteCall( tpl, "T"+ltrim(str(ThreadID())) + " " + cString )

[Rolf Ramacher]

Hallo zusammen,

also wenn ich irgendwelche Probleme habe um diese dann zu lösen lasse ich mir mit msgbox die entsprechenden Variablen oder array usw.
anzeigen. Ob sich das jetzt mit diesem Punkt anwenden kann ??

[Günter Beyes]

Hallo Rolf,

sobald die MsgBox erscheint, wechselt der Fokus. Das dürfte im vorliegenden Fall ebenso problematisch sein.

Viele Grüße
Günter

[hschmidt]

Hallo Günter,

DebugView gibt es hier: http://www.microsoft.com/technet/sysint ... gview.mspx

das war ein wertvoller Hinweis für mich.
Wir entwickeln in 2 Sprachen (Xbase++ und VO) und unsere Applikationen 'unterhalten' sich per OLE-Automation.
Mit Debugview habe ich jetzt die Möglichkeit, Debugmeldungen beider Programme in einem Fenster/Datei auszugeben und auszuwerten.

Vielen Dank!

Hans