Seite 2 von 2

Re: Focuswechsel übereinanderliegende Dialoge

Verfasst: Di, 17. Mai 2016 13:25
von Manfred
Tja, das war es wohl. Jetzt sieht es so aus, als wenn es genauso klappt, wie es klappen soll. Das einzige was mich jetzt verwundert ist, dass im Debugger unter Threadanzeige nur immer der Thread angezeigt wird, in dem ich gerade eine Breakpoint gesetzt habe. Weiterhin ist noch irgendwo der Wurm drin, ich hatte gerade einen Eintrag, der sowas wie not executable hieß, oder so. Da scheint wohl ein Thread nicht richtig geschossen worden zu sein. Mal schauen, ob ich das reproduzieren kann.

Das zum Thema Threads. Und ich dachte ich hätte das jetzt so langsam verstanden. Aber wie hieß es früher immer so schön? "Da hast du wohl in der Schule nicht aufgepasst, als der Lehrer das erklärt hat." :doubt:

Re: Focuswechsel übereinanderliegende Dialoge

Verfasst: Di, 17. Mai 2016 13:31
von Manfred
alles klar, auch das Problem mit der Anzeige scheint gelöst. Es wird nicht der Name des Threads angezeigt, sondern nur die EVENTLOOP.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 13:56
von Manfred
puh, das war mal wieder lehrreich. Bedeutet aber auch, alles umbauen, was ich bisher fabriziert habe. Naja, wenn's schön macht.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 14:03
von Tom
Du hast mit Threads natürlich (etwas) andere Bedingungen:

- Workareas aus dem aufrufenden Modul sind nicht sichtbar
- Variablen aus dem aufrufenden Modul sind nicht sichtbar (Ausnahme: PUBLICs und Parameter)
- Einige Einstellungen (Set(_SET_x)) sind nicht gültig/sichtbar, die meisten jedoch schon - umgekehrt wirken sich threadlokale Einstellungen nur dort aus

Dafür ist alles gekapselt, man muss sich also nicht darum scheren, ob Aliase oder Select-Bereiche bereits verwendet werden. Bei Verwendung des ADS muss man auf das Session-Management achten (oSession:SetDefault()), auf viel mehr aber auch nicht. Ein Vorteil besteht darin, dass man das Hauptfenster schließen und die Applikation beenden kann, ohne sich um geöffnete Fenster scheren zu müssen - allerdings ist das auch ein wenig gefährlich.

Re: Focuswechsel übereinanderliegende Dialoge

Verfasst: Di, 17. Mai 2016 14:17
von brandelh
Manfred hat geschrieben:jetzt stehe ich hier wieder vor der Wand.

Code: Alles auswählen

ACTION {|o|o := Thread():new(), o:start({|| tagesdienste(oMenu1,o)})}
bei o:start wird alles akzeptiert, aber der Parameter wird angemeckert?
Ob es sinnvoll ist o weiterzugeben weiß ich nicht, aber wenn du es willst, geht das ganz einfach ;-)

Code: Alles auswählen

ACTION {|o|o := Thread():new(), o:start({|o| tagesdienste(oMenu1,o)})}
so wie du oben am Anfang o übergibst, musst du das auch im tieferen Codeblock tun.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 14:19
von Manfred
@Hubert, Danke die Idee ist mir danach auch gekommen. Aber es scheint ja auch so zu klappen.
@Tom, das ist ja genau das, was ich haben wollte. Ich war der Meinung durch express++ wären das schon Threads. Die Funktionen sind genau so programmiert, das alles nur für sich gelten soll.
Naja, besser spät als nie....

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 15:39
von Wolfgang Ciriack
Ein Vorteil besteht darin, dass man das Hauptfenster schließen und die Applikation beenden kann, ohne sich um geöffnete Fenster scheren zu müssen - allerdings ist das auch ein wenig gefährlich.
Wie verhindert man denn dabei die entstehenden xppfatal.log-Dateien ?
Ich bekomme diese seit der Umstellung auf Threads jeden Tag :(

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 15:50
von Tom
Hallo, Wolfgang.

Sind es immer die gleichen? Hast Du mal ein Beispiel?

Ich nehme an, dass es mit dem Tooltipping-System von Roger bzw. Jack zu tun hat. Das threadbezogene Tooltipping (JD) ist fehlerhaft und eine große Fehlerquelle.

Jedenfalls bekomme ich keine Fatals, die irgendwie mit Multithreading und geöffneten Applikationsfenstern zu tun haben.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 16:16
von Wolfgang Ciriack
Die Toolstips habe ich erst einmal abgeschaltet, da die vorher immer in den Errorlogs vorhanden waren.
Hier Beispiele:

Code: Alles auswählen

FATAL ERROR LOG 
No continue after this Error!
SYS Thread-ID: 3680 
Module: EXE
Error Codes: EH: 10 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (696):
Call Stack of GUI Thread (884):
Call Stack of Thread 3 (1664):
Call Stack of Thread 6 (2064):
Call Stack of Thread 7 (2884):
Call Stack of Thread 8 (3680):
@DC_GETLIST@I@READGUI(3841)
DC_READGUI(111)
RAUSMAIN(334)
Call Stack of Thread 9 (2988):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
WAAGSTART(767)
File: C:\fvwclient\FVW2.exe
TimeStamp: 20160517 13:02
End of FATAL ERROR LOG.

Code: Alles auswählen

FATAL ERROR LOG 
System-Error
SYS Thread-ID: 816 
Module: EVM
Error Codes: EH: 4 Sub: 6(6) OS: 6 XPP: 40
Call Stack of Thread 1 (720):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
FVWRIBB_FVWMAINDIALOG(566)
MAIN(542)
Call Stack of GUI Thread (908):
Call Stack of Thread 3 (1700):
Call Stack of Thread 4 (1744):
Call Stack of Thread 5 (3796):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
AUFMAIN(899)
Call Stack of Thread 6 (2448):
Call Stack of Thread 7 (3504):
@DC_SETTIMEREVENT@I@TIMERLOOP(2596)
(B)@DC_SETTIMEREVENT@I@INIT(2551)
Call Stack of Thread 8 (1968):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
WAAGSTART(767)
Call Stack of Thread 9 (1844):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
KLEINMENGENANNAHME(447)
Call Stack of Thread 10 (2320):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
CONMAIN(265)
Call Stack of Thread 11 (2192):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
LIEMAIN(240)
Call Stack of Thread 12 (2152):
Call Stack of Thread 13 (3712):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
KUNMAIN(280)
File: C:\Daten\lokal2\fvwclient\FVW2.EXE
TimeStamp: 20160517 09:24
End of FATAL ERROR LOG.

Code: Alles auswählen

FATAL ERROR LOG 
No continue after this Error!
SYS Thread-ID: 1292 
Module: EXE
Error Codes: EH: 10 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (760):
Call Stack of GUI Thread (956):
Call Stack of Thread 3 (1628):
Call Stack of Thread 4 (1672):
Call Stack of Thread 7 (1292):
@DC_GETLIST@I@READGUI(3841)
DC_READGUI(111)
WVBLEISTUNGEN(312)
File: C:\Firma\fvwclient\FVW2.EXE
TimeStamp: 20160517 09:13
End of FATAL ERROR LOG.

Code: Alles auswählen

FATAL ERROR LOG 
No continue after this Error!
SYS Thread-ID: 3240 
Module: EXE
Error Codes: EH: 10 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (696):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
FVWRIBB_FVWMAINDIALOG(566)
MAIN(542)
Call Stack of GUI Thread (884):
Call Stack of Thread 3 (1716):
Call Stack of Thread 4 (1760):
Call Stack of Thread 5 (1828):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
AUFMAIN(899)
Call Stack of Thread 6 (1984):
Call Stack of Thread 7 (2404):
@DC_SETTIMEREVENT@I@TIMERLOOP(2596)
(B)@DC_SETTIMEREVENT@I@INIT(2551)
Call Stack of Thread 8 (2236):
@DC_GETLIST@I@EVENTLOOP(4131)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
WAAGSTART(767)
Call Stack of Thread 9 (3240):
RTFTXTBEARB(83)
(B)TxtMain(234)
(B)DC_MergeBlocks(184)
@XBPBROWSE@I@HANDLEEVENT(1542)
@DC_XBPBROWSE@I@HANDLEEVENT(1133)
@DC_GETLIST@I@EVENTLOOP(4651)
@DC_GETLIST@I@READGUI(3832)
DC_READGUI(111)
TXTMAIN(332)
File: C:\fvwclient\FVW2.EXE
TimeStamp: 20160517 07:22
End of FATAL ERROR LOG.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 17:48
von Tom
Welche eXpress++-Version, Wolfgang?

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 18:24
von Wolfgang Ciriack
Noch Build 260.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Di, 17. Mai 2016 18:41
von Tom
Zeile 4131 in DCGETLIST@EVENTLOOP kommt mir sehr bekannt vor. Geh mal auf die 263 oder folgende, da ist das sicher weg.

Re: Focuswechsel übereinanderliegende Dialoge

Verfasst: Di, 17. Mai 2016 18:43
von AUGE_OHR
Manfred hat geschrieben:

Code: Alles auswählen

ACTION {|o|o := Thread():new(), o:start({|| tagesdienste(oMenu1,o)})}
bei o:start wird alles akzeptiert, aber der Parameter wird angemeckert?
hm ... :-k
ich sehe nicht das du die Parameter für den Codeblock "extra" übergibst ... nur in der Function.
:start( [<cFuncName>|<bCodeBlock>], ;
[<xParamList,...>] ) --> lSuccess

<cFuncName>
...
<bCodeBlock>
...
<xParamList> ist eine kommaseparierte Liste beliebiger Ausdrücke, die der angegebenen Funktion oder dem Codeblock übergeben werden.
...

Code: Alles auswählen

      bBlock := { || YKUNDEN( oDraw, NIL , aPos, aSize, aPP, .T., cAction, nSeekRec, oGUImain[1] ), ;
                              oDraw, NIL , aPos, aSize, aPP, .T., cAction, nSeekRec, oGUImain[1] }

      oJobKundThread := Thread() :new()
      oJobKundThread:start( bBlock )

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Mi, 18. Mai 2016 7:10
von Wolfgang Ciriack
Danke Tom, dann muss ich mal intensiv die 264 testen.

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Mi, 18. Mai 2016 9:50
von Rudolf
Hallo,
in meinem Beispiel kann man auch ohne Threads jedes Fenster (ausser Modal) beliebig oft aufmachen. eXpress++ hat nur einen kleinen Fehler, dadurch ist das beschriebene Problem entstanden, laut Roger _dcgetbx.prg in Zeile 4534 (oder in der Nähe) wie folgt ändern

WAS:
IF oGetList:lastFocus:status() == XBP_STAT_CREATE

IS:
IF oGetList:lastFocus:status() == XBP_STAT_CREATE .AND. !oXbp:owner:isDerivedFrom('DC_XbpDialog1')

dann springt Eingabefocus vom Child Fenster nicht immer zurück ins Hauptfenster
Grüße
Rudolf

Re: Focuswechsel übereinanderliegende Dialoge [ERLEDIGT]

Verfasst: Do, 15. Feb 2018 11:48
von Manfred
ich würde hier nochmal ganz gerne nachfragen, in wie weit das mit dem Thread hier zu beachten ist?
viewtopic.php?f=32&t=4033&p=119097#p119097
mache ich es trotzdem richtig wie erklärt? Ich lagere ja auch die einzelnen Programmteile in Threads aus und das klingt im anderen Thread so, als wenn man das nicht machen sollte. :confused2: