PureBoard

Verfasst: **23.01.2011 21:47**

Lief alles wie erwartet hier. Wenn du damit nicht zurechtkommst, nutze doch einfach Zustandsvariablen: Active=#True etc.

Verfasst: **24.01.2011 07:18**

Hallo c4s,

wie meinst du "lief alles wie erwartet"?

Ich kann ja (muß) akzeptieren, das nach einem wie auch immer gearteten Ereignis, der Zustand des
verlassenen Fensters nach Wiederkehr zurück auf den Zustand gesetzt wird, in dem es verlassen
wurde, sei es durch einen Requester oder sonst einen Aufruf. OK. Soweit ist alles gut.

Aber wo es dann zu zwicken beginnt:

Guck dir doch einfach mal das Schnippel an, nimm es, starte es wie es ist: Endlosschleife, weil der
Focus bleibt. Ist ja noch alles gut an der Stelle, siehe der Satz davor.

Dann geh hin, und nimm den Kommentar weg vor dem Satz "SetActiveGadget(2)". Da bekommt ein anderes
Gadget den Focus, NACH DER WIEDERKEHR VOM REQUESTER!

Und da fängt für mich der Spass an. Ich gebe einem anderen Gadget den Status "active" und als Rückmeldung
wird dann immer noch der Focus auf das gerade vorher aktive gesetzt? Erst im zweiten Anlauf, sprich der
Requester wird ein zweites Mal verlassen, dann, aber erst dann wird das SetActiveGadget(2) akzeptiert.

Geht man noch einen Schritt weiter, also nimmt den Kommentar von dem If actgd=0 (oder unten halt =1)
und natürlich dem EndIf weg, dann funktioniert es.

Mit anderen Worten, wie kann es denn bitte richtig sein, das ein Gadget welches aktiviert wurde nicht das
ist, das auch in dem Moment den Focus hat? Das wäre ja so, als würde eine Ampel "Rot" zeigen und trotzdem
ist "Grün" an und auf der gegenüberliegenden Seite leuchtet in dem grünen Starenkasten die ganz helle Lampe
für einen Moment auf und mit dem Fotoapparat darunter wird ein tolles Bild geschossen, für 80 Euro und man
bekommt noch zwei Pluspunkte in Flensburg ...

Gruß Jens

Verfasst: **24.01.2011 13:52**

sharkpeter hat geschrieben: Dann geh hin, und nimm den Kommentar weg vor dem Satz "SetActiveGadget(2)". Da bekommt ein anderes
Gadget den Focus, NACH DER WIEDERKEHR VOM REQUESTER!

Und da fängt für mich der Spass an. Ich gebe einem anderen Gadget den Status "active" und als Rückmeldung
wird dann immer noch der Focus auf das gerade vorher aktive gesetzt? Erst im zweiten Anlauf, sprich der
Requester wird ein zweites Mal verlassen, dann, aber erst dann wird das SetActiveGadget(2) akzeptiert.

ist doch alles richtig. sagen wir mal ich drücke in das gadget 0.
dann wird der requester aufgerufen -> gadget 0 verliert den focus
requester wird beendet -> gadget 0 bekommt den focus
SetActiveGadget(2) -> gadget 0 verliert den focus, gadget 2 bekommt den focus

nach dieses zeilen, gibt es also noch VIER events die erstmal abarbeitet werden müssen. denn wenn das gadget 2 den focus bekommt, heißt es noch lange nicht, dass das vorherige event 'gadget 0 bekommt den focus' einfach gelöscht wird.

hier noch ein code dazu, der den requester und SetActiveGadget(2) nur einmal aufruft (SetActiveGadget kommt halt einfach nur später an):

Code: Alles auswählen

; Testprogramm

OpenWindow  (1,  0,  0,300,200,"Test")
StringGadget(0, 10, 10,280, 20,"")
StringGadget(1, 10, 40,280, 20,"")
StringGadget(2,400,400,280, 20,"Ich bin außerhalb, damit man mich nicht sieht ...")

onceonly = 0
Repeat
  eventid.l=WaitWindowEvent()
  eventtp.l=EventType()
  actgd.l  =GetActiveGadget()
  Select eventid
    Case #PB_Event_CloseWindow
      Quit=#True
    Case #PB_Event_Gadget
      Select EventGadget()
        Case 0
          Debug "neuer Durchlauf String 0"
          Select eventtp
            Case #PB_EventType_Focus
                Debug "String 0 hat den Focus erhalten"
              If (onceonly = 0)
                OpenFileRequester("test string 0","c:\","*.*|*.*",0)
                SetActiveGadget(2)
                onceonly = 1
              EndIf
            Case #PB_EventType_LostFocus
              Debug "String 0 hat den Focus verloren"
          EndSelect
        Case 2
          If (eventtp = #PB_EventType_Focus)
            Debug "String 2 hat den Focus erhalten"
          EndIf
      EndSelect
  EndSelect
Until Quit

End

lg kevin

Verfasst: **24.01.2011 21:03**

Mir scheint aber, das der Debugger das an falscher Stelle anzeigt. Der Focus ist erhalten, wenn der Cursor z.B. in diesem abgefragten Stringgadget ist. Dann kommt das Filerequester und da sollte
der Debugger die Meldung LostFocus ausgeben, da der Focus nun nicht mehr im Stringrequester angezeigt wird. Diese Debugausgabe kommt aber erst nachdem der Filerequester geschlossen wird. ..LostFocus.
Da so nun ein Durchgang der Repeatschleife gelaufen ist, kommt erneut Focus erhalten und das ganze wiederholt sich unendlich, wenn man das nicht abbricht. Wie man das mit den SetActiveGadget macht, hat Jens eigentlich in seinen auskommentierten Code schon geschrieben, den man hätte nur ändern brauchen.

Bei deiner Lösung wird das Filerequester nur einmal geöffnet und mit der Variable onceonly=1 für weitere Stinggadgets verhindert. Ich öffne noch mal Jens seinen Code ohne den Kommentaren. Dazu habe ich auch noch mal ein SetGadgetText... eingebaut, damit man sehen kann, das so auch in jedem Stringgadget der Pfad eingetragen werden kann:

Code: Alles auswählen

; Testprogramm

OpenWindow  (1,  0,  0,300,200,"Test")
StringGadget(0, 10, 10,280, 20,"")
StringGadget(1, 10, 40,280, 20,"")
StringGadget(2,400,400,280, 20,"Ich bin außerhalb, damit man mich nicht sieht ...")

Repeat
  eventid.l=WaitWindowEvent()
  eventtp.l=EventType()
  actgd.l  =GetActiveGadget()
  Select eventid
    Case #PB_Event_CloseWindow
      Quit=#True
    Case #PB_Event_Gadget
      Select EventGadget()
        Case 0
          Debug "neuer Durchlauf String 0"
          Select eventtp
            Case #PB_EventType_Focus
              If actgd=0
                Debug "String 0 hat den Focus erhalten"
                SetGadgetText(0,OpenFileRequester("test string 0","c:\","*.*|*.*",0))
                SetActiveGadget(2)
              EndIf
            Case #PB_EventType_LostFocus
              Debug "String 0 hat den Focus verloren"
          EndSelect
        Case 1
          Debug "neuer Durchlauf String 1"
          Select eventtp
            Case #PB_EventType_Focus
              If actgd=1
                Debug "String 1 hat den Focus erhalten"
                SetGadgetText(1,OpenFileRequester("test string 1","c:\","*.*|*.*",0))
                SetActiveGadget(2)
              EndIf
            Case #PB_EventType_LostFocus
              Debug "String 1 hat den Focus verloren"
          EndSelect
      EndSelect
  EndSelect
Until Quit

End

Da Jens ihier schon mal gezeigt hat, wie man es lösen kann, das der Focus verloren geht, wenn man
ihn mit dem SetActiveGadget(2) auf das dritte Stringgadget setzt, welches eben nicht nach dem Focus
abgefragt wird, ist klar. Nur sind diese Focus-Geschichten zwei verschiedene Sachen. Der eine, wenn das Filerequester auftaucht und der Debugger nicht jetzt schon die Meldung ausgibt: Focus verloren und der offensichtlichere, wenn das dritte Stringgadget aktiv gesetzt wird, worauf der Debugger logischer Weise
die Ausgabe macht.

Das irritiert bei der Fehlersuche, wenn der Debugger die Ausgabe nicht schon da ausgibt, wo es geschieht.

Gruß Falko

Verfasst: **24.01.2011 23:59**

Falko hat geschrieben:Bei deiner Lösung wird das Filerequester nur einmal geöffnet und mit der Variable onceonly=1 für weitere Stinggadgets verhindert.

das sollte gar keine lösung sein. ich hab ja gesehen das jens die lösung schon hatte.
ich hatte auf dies bezug genommen:

sharkpeter hat geschrieben:Dann geh hin, und nimm den Kommentar weg vor dem Satz "SetActiveGadget(2)". Da bekommt ein anderes
Gadget den Focus, NACH DER WIEDERKEHR VOM REQUESTER!

Und da fängt für mich der Spass an. Ich gebe einem anderen Gadget den Status "active" und als Rückmeldung
wird dann immer noch der Focus auf das gerade vorher aktive gesetzt? Erst im zweiten Anlauf, sprich der
Requester wird ein zweites Mal verlassen, dann, aber erst dann wird das SetActiveGadget(2) akzeptiert.

ich wollt nur erklären, wieso das so ist.

und das mit der debugausgabe ist doch vollkommen richtig. der requester stoppt die ausführung!! das heißt, wenn der requester offen ist, wird die schleife gar nicht durchlaufen. wie soll dann die debug-meldung kommen?
wenn man die debug-meldung zur richtigen zeit haben will, dann kommt man um callbacks nicht herum, also SetWindowCallback(). mit ner einfachen WaitWindowEvent-Schleife geht das nicht.

lg kevin

Verfasst: **25.01.2011 00:13**

Sorry,
du hast es prima erklärt und es sollte keine Kritik sein.

Wenn man die Reihenfolge Schritt für Schritt durch geht,
ist es auch klar.
Ich hatte Vergessen, das die Debugabfrage eigentlich nach dem Requester
kommt.

Gruß Falko

Verfasst: **28.01.2011 20:11**

@ CSHW89,

na sicher doch, irgendwie habe ich wohl auf dem Schlauch gestanden. Die Messages aus der Queue
werden ja nicht abgearbeitet und stehen dann wieder an. Na ja, die alte Lösung hat mir besser
gefallen. Aber sei es drum.

Jedenfalls möchte ich mich bei dir bedanken, für die ausführliche und sachliche Augenöffung

So stellt man sich das in einem Forum vor, auch wenn mal eine Sache wegen Betriebsblindheit
zuerst nicht ganz einsichtig erscheint.

Gruß Jens

PureBoard

Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?

Re: Konstanten in PB?