AppEvent()

[Manfred]

Und weiter geht es. Etwas, was mich schon länger nervt:

Code: Alles auswählen

#include "Appevent.ch" 
 
   PROCEDURE Main 
      LOCAL nEvent, mp1, mp2, oXbp 
 
      // Pushbutton erzeugen 
      oXbp:= XbpPushButton():new( SetAppWindow():drawingArea ) 
      oXbp:caption := "Abbruch" 
      oXbp:create( , , {10,20}, {100,40} ) 
      oXbp:activate := {|| PostAppEvent( xbeP_Close) } 
 
      // Event loop 
      nEvent := 0 
      DO WHILE nEvent <> xbeP_Close 
         nEvent := AppEvent( @mp1, @mp2, @oXbp ) 
         oXbp:HandleEvent( nEvent, mp1, mp2 ) 

      ENDDO 

   RETURN                    

Wozu wird das oXbp in der Do while Schleife benutzt? Es steht dort immer mit der Bezeichnung. Hier ist es nur vorher mit einem Button belegt worden. Ist die Auswahl wild getroffen, oder darf/kann es nur ein bestimmter XbasePart sein?

Mein Beispiel:

Code: Alles auswählen

FUNCTION buchungktovt_gui()
         LOCAL mp1      := 0
         LOCAL mp2      := 0
         LOCAL nEvent   := 0
         LOCAL oBuchKto := buchungskonto():new():initvaria():dbOpen()
         LOCAL oXbp

         MEMVAR oBild

         oBuchKto:maske_gui()
         oBild:MenueHorizontal_Gui(oBuchKto)
         SetAppFocus(oBuchKto:oEingabeFenster)
         DO WHILE nEvent <> xbeP_Close
            nEvent := AppEvent(@mp1, @mp2, @oXbp)
            oXbp:handleEvent(nEvent, mp1, mp2)
         ENDDO .T.
         oBuchKto:closeDb()
         oBuchKto:oEingabeFenster:destroy()
         RETURN(.T.)

Muß ich hier auch oXbp nehmen, oder könnte ich auch oBuchKto nehmen, oder oBild, in dem die Buttons erzeugt werden. Oder wovon ist das überhaupt alles abhängig?
Beim Compilieren meines Beispieles wird immer oXbp angemeckert, weil es vor der Benutzung nicht gesetzt wurde. Aber was soll ich da setzen? Welchen Wert?

[brandelh]

Hallo Manfred,

im ersten Beispiel sieht man wie eine lokale Variable (oXbp) doppelt benutzt wird. Zuerst um ein Objekt (Pushbutton) zu genierieren danach wird es von Appevent(...@oXbp) durch den XbPart überschrieben, der den Event ausgelöst hat. Die Variable kann hier völlig frei gewählt werden, nur muss diese dann später auch den Event verarbeiten (handleevent).

Die Warnung (kein Fehler) wird vom Compiler erzeugt, weil du einen der Warnschalter aktiviert hast. Aus Sicherheitsgründen sollte man das auch so lassen und einfach oVar := NIL benutzen um den Compiler zufrieden zu stellen.

In beiden Fällen funktioniert alles, ABER nach dem AppEvent() kann man auf den Button von vorher nicht mehr direkt zugreifen, da ja nun möglicherweise ein anderes Objekt in der Variabelen oXbp gespeichert ist, das ist der einzige Nachteil !

[Manfred]

Hi Hubert,

danke erstmal. Das hilft mir für den Moment weiter.

[brandelh]

Muß ich hier auch oXbp nehmen, oder könnte ich auch oBuchKto nehmen, oder oBild, in dem die Buttons erzeugt werden. Oder wovon ist das überhaupt alles abhängig?

Grundsätzlich spielt der Name des Variablen keine Rolle.
Wenn du aber die benutzt, die das Objekt deiner DBF speichert, ist danach
der Zugriff auf dein DBF Objekt nicht mehr möglich (was dann passiert weiß ich nicht, normale XbPart Objekte sind noch beim Fenster in der Childlist enthalten ...). Somit wäre das wohl nicht sinnvoll

Code: Alles auswählen

local [color=red]oXbp[/color] := NIL  // verhindert Warnmeldung

DO WHILE nEvent <> xbeP_Close 
         nEvent := AppEvent( @mp1, @mp2, [color=red]@oXbp[/color] ) 
         [color=red]oXbp[/color]:HandleEvent( nEvent, mp1, mp2 ) 
ENDDO 

Die Variablen müssen in diesen Zeilen übereinstimmen, denn AppEvent liefert nicht nur den nEvent, sondern setzt auch die Parameter (hier mp1, mp2 und oXbp). Der XbPart, der den Event auslöst ist nun in oXbp gespeichert und muss diesen auch verarbeiten ...

[Manfred]

Das mit der Namenvergabe war schon klar. Ich war nur etwas verwirrt, weil vorher PushButton reingelegt wurden. Wie mich diese ganze "Überlagerung" der XbaseParts verwirrt. Ist es nicht besser für alles ein eigenes Objekt anzulegen, als alles über Childlist() später zu extrahieren? Aber ich glaube dieses Thema hatten wir hier im Forum schon!?

[brandelh]

Wie mich diese ganze "Überlagerung" der XbaseParts verwirrt. Ist es nicht besser für alles ein eigenes Objekt anzulegen, als alles über Childlist() später zu extrahieren?

Hallo Manfred,

zuerst etwas Haarespaltereien

oXbp ist nicht das Objekt, sondern die lokale Variable in der das Objekt gespeichert ist (bis diese wieder für was anderes verwendet wird.) ! Das muss man genau verstehen und genau trennen, dann fällt das Verstehen leichter. Ein XbPart Objekt bleibt im Speicher auch ohne diese Variable ... ein selbsterzeugtes wahrscheinlich nicht, da es keine Systemresourcen belegt (weiß ich jetzt aber nicht).

dann zum grundsätzlichen.

Ich verwende CLASS Code.

Dort wird immer für jedes XbPart eine eigene Instanzvariable angelegt !

Das ist sehr sinnvoll und so kann man es natürlich auch bei Function-Code machen, aber nach dem Ende der Funktion sind die local Variablen wieder leer und der Zugriff wieder nicht mehr möglich.

[Martin Altmann]

Hallo Manfred,
besser (im Sinne der Lesbarkeit) ist es auf jeden Fall!
Ich rate auch unbedingt davon ab, die in der o.g. Eventschleife genutzten Variabeln genauso zu nennen, wie andere im Programm verwendete!

Viele Grüße,
Martin

[Manfred]

Aha,

also jetzt nochmal zum Mitschreiben:

@Hubert,
Die Beispiele, die alles in ein Objekt packen sind kein Class Code. (OK, im nachhinein sehe ich es auch)

Das oXbp nur die Var ist, ist auch klar. Aber im Kopf steht oXXXX für ein Objekt bei mir und das dient auch der besseren Lesbarkeit.

@Martin,
da fällt mir wieder ein Stein vom Herzen, weil ich auch immer liebend gerne alles einzeln benenne. Ich war aber jetzt ein wenig verwirrt.

[brandelh]

Ich rate auch unbedingt davon ab, die in der o.g. Eventschleife genutzten Variabeln genauso zu nennen, wie andere im Programm verwendete!

Dem Kompiler ist es egal, wie die Variablen heißen, aber der Mensch der das Programm später verstehen muss tut sich leichter wenn man es bleiben läßt.

Gefährlich wird es auf jeden Fall bei STATIC Variablen.

Wenn man dann irgendwo im Programm die Variable sieht und denkt ... ach wird wohl eine private sein oder oben irgendwo ein local stehen und dann ist es eine static, da kommen die besten Fehler zusammen.

[Martin Altmann]

Hallo Hubert,
genau aus diesen Gründen rate ich auch davon ab!
Dem Compiler ist das latürnich egal - aber das Debuggen könnte dadurch zur Herausforderung werden....

Viele Grüße,
Martin

[brandelh]

Hi,

ich wollte deine Worte nur verstärken, diesen keinesfalls widersprechen

[Martin Altmann]

Hubert,
das hatte ich auch nicht anders aufgefasst, keine Sorge!
Gleiches wollte ich mit meiner erneuten Antwort auch

Viele Grüße,
Martin

[Rolf Ramacher]

Hallo Manfred,

ich kann Martin & Hubert schon zustimmen. Die oXbp, oDlg usw. also alle xbpParts verwende ich IMMER Local, da ich innerhalb eines Programmteils
mehrere Fenster haben. Hierbei gleich ein tipp von mir.

Wenn ich aus einem Dialog einen weiteren Dialog aufrufen muß, so gebe ich den vorherigen an die Function weiter. Den Dialog nenne ich dann in
der "unterfunktion" oParent. Bevor ich dann hier den nächsten Dialog
generiere mache ich oParent:disable().

und wenn ich wieder zurückgehe wird. oDlg:destroy() und
oParent:enable(). Außerdem erhält der oParent direkt den Focus
SetappFocus(oParent)