Ein smarter Eventhandler für Gadgets/Menuitems und Toolbar

Hier könnt Ihr gute, von Euch geschriebene Codes posten. Sie müssen auf jeden Fall funktionieren und sollten möglichst effizient, elegant und beispielhaft oder einfach nur cool sein.
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Ein smarter Eventhandler für Gadgets/Menuitems und Toolbar

Beitrag von Kurzer »

Hallo zusammen,

ich habe kürzlich meinen "Programmierstil" bzgl. der PB Eventschleife geändert.
Dazu gibt es ja an anderer Stelle einen interessanten Thread, in dem jeder seine Art der Eventbehandlung zum Besten gegeben hat (habe den link leider nicht parat).

Nun denn, mir war das auf Dauer zu nervig den Verwaltungscode für die ganzen Events immer wieder neu zu tippen (bzw. immer wieder das Template einzufügen). Außerdem wird es irgendwann auch unübersichtlich, wenn man sehr viele Gadgets benutzt.

Ich habe mir jetzt ein Include geschrieben, das mir diese Verwaltungsarbeit abnimmt und die Funktionalität auslagert, so daß mein Maincode nicht mehr mit den Select/Case/EndSelect/If/EndIf-Wüsten übersäht ist.

Vermutlich bin ich der dreihundertneunundsechzigste, der sich ein Eventmanagment-System für PB geschrieben hat, aber das hält mich nicht davon ab es Euch trotzdem zur Verfügung zu stellen - hehe. <)

Zum besseren Verständnis hier ein paar Erklärungen:


;*************************************************************************
;* Informationen zur Benutzung
;*************************************************************************
; Mit diesem Eventhandler wird die Auswertung von Window-, Button- und Menüevents erleichtert.
;
; Nachdem die GUI des eigenen Programms erzeugt wurde, können den Gadgets, Fenstern und
; Menüeinträgen mit den folgenden Befehlen eigene Eventprozeduren zugeordnet werden.
;
; evh_SetWindowEvent(iWindowNr, iEventType, *EventProcedure)
; evh_SetMenuEvent (iWindowNr, iMenuitemNr, *EventProcedure)
; evh_SetGadgetEvent(iWindowNr, iGadgetNr, iEventType, *EventProcedure)
;
; iWindowNr, iGadgetNr bzw. iMenuitemNr stellen dabei die Nummern des jeweiligen Fensters, Gadgets oder
; Menüeintrags dar.
;
; iEventType beschreibt die PB Eventkonstante auf die reagiert werden soll (z.B. #PB_EventType_LeftClick)
; Folgende Eventtypen können bei den jeweiligen Befehlen benutzt werden:
;
; evh_SetWindowEvent(): Alle Events, die der Purebasic-Befehl WindowEvent() zurück gibt
; evh_SetMenuEvent() : Hier ist kein Eventtyp anzugeben, es wird nur die Menuitem-Nummer ausgewertet
; evh_SetGadgetEvent(): Alle Events, die der Purebasic-Befehl EventType() zurück gibt
;
; In *EventProcedure gibt man die Adresse der Prozedur an, die bei Auftreten des Events aufgerufen werden soll
; (sie ist anzugeben mittels @Prozedurname()).
;
; Jeder Eventprozedur wird als einziger Parameter ein Zeiger auf die folgende Event-Parameterstruktur übergeben:
;
; \iEvent
; \iEventType
; \iEventWindow
; \iEventGadget
; \iEventMenu
; \iEventTimer
; \iEventwParam ; enthält nur unter Windows sinnvolle Werte
; \iEventlParam ; enthält nur unter Windows sinnvolle Werte
;
; (Der Strukturtyp lautet "evh_EventArgsStruct" und ist im Eventhandler-Include definiert)
;
; Eine Eventprozedur ist somit immer nach folgendem Schema aufzubauen (Beispiel):
;
; Procedure Name(*stEventArgs.evh_EventArgsStruct)
; ...
; EndProcedure
;
; Die Felder der Struktur entsprechen den äquivalenten PB-Befehlen WaitWindowEvent(), EventType(),
; EventWindow(), usw. und enthalten genau das jeweilige Ergebnis dieser PB-Befehle.
; Die Felder iEventwParam und iEventlParam enthalten nur gültige Werte, wenn das Include auf einem Windwos PC
; kompiliert wird. Die zugehörigen PB Befehle EventwParam() und EventlParam() sind undokumentierte Befehle und
; funktionieren nur unter Windows. Auf anderen Betriebssystemen werden diese Felder mit 0 initialisiert.
;
; Die Felder \iEventGadget bzw. \iEventMenu enthalten nur sinnvolle Werte, wenn das Feld \iEvent entweder
; #PB_Event_Gadget oder #PB_Event_Menu enthält.
;
; WICHTIG:
; Bitte nicht vergessen den Parameter (*stEventArgs.evh_EventArgsStruct) immer in die eigenen Eventprozeduren
; einzubauen, da es sonst zwangsläufig zu einem Rücksprungfehler kommt! (=> Das Programm stürzt ab, weil die
; Daten vom Stack nicht abgeholt wurden)
;
; Um einen registrierten Event wieder aufzuheben, ruft man den Befehl evh_RemoveEvent() auf
;
; evh_RemoveEvent(iWindowNr, [iItemNr], [iEventType])
;
; Die beiden Parameter iItemNr und iEventType entsprechen den beiden Parametern des jeweiligen
; evh_SetXYZEvent-Befehls. Also z.B. der GadgetNummer und dem Eventtyp bei evh_SetGadgetEvent()
;
; Werden die beiden o.g. Parameter weggelassen und nur iWindowNr angegeben, dann werden automatisch
; ALLE Events unregistriert, die zu dem angegebenen Fenster iWindowNr gehören.
;
; Dies ist nützlich, wenn man beim Schließen eines Fensters alle zugehörigen, registrierten Events auf einen
; Schlag unregistrieren möchte.
;
; Der eigentliche Eventloop des Programms beschränkt sich dann nur noch auf ein zweizeiliges Konstrukt.
; Beispiel:
;
; While evh_ProcessEvents(25, MainWindow, @OwnEventproc(), 0)
; Wend
;
; Mit dem Befehl evh_ProcessEvents(iTimeOut, iObserveWindow, [*OwnEventHandler], [*stEvents]) nimmt der
; Eventhandler seine Arbeit auf. Der Befehl muß innerhalb eines Loops immer wiederkehrend aufgerufen
; werden, genau so wie der PB Befehl WaitWindowEvent().
;
; Die Parameter im Einzelnen:
;
; iTimeOut: Der Parameter iTimeOut gibt den Timeoutwert in Millisekunden an, die der Eventhandler auf
; eine Nachricht warten soll. Kommt in dieser Zeit keine Nachricht an, dann kehrt das Programm in den
; Loop zurück. Der Eventhandler benutzt den WaitWindowEvent() Befehl, insofern gilt analog das, was in
; der PB Hilfe zu diesem Befehl erklärt wird.
; (Anm.: Wird der Parameter *stEvents benutzt, dann ist der Wert iTimeOut nicht relevant)
;
; iObserveWindow: Mit iObserveWindow gibt man das Handle des Hauptfensters seiner Applikation an.
; Wird in diesem Fenster ein #PB_Event_CloseWindow ausgelöst (= Fenster wird geschlossen), dann gibt der
; Befehl evh_ProcessEvents() ein #False zurück. In allen anderen Fällen ein #True.
; Dadruch wird der obige While/Wend Eventloop ermöglicht, der mittels Rückgabewert #False beendet wird.
;
; *OwnEventHandler (optional): Da man vielleicht nicht alle Events über den Eventhandler bearbeiten lassen
; möchte, kann man als dritten Parameter die Adresse einer eigenen Eventprozedur angeben, die *nach*
; Abarbeitung der registrierten Events zusätzlich aufgerufen wird. Möchte man keine eigene Event Bearbeitungs-
; prozedur benutzen, dann setzt man als dritten Parameter 0 ein.
;
; Diese eigene Event-Bearbeitungsprozedur bekommt als Parameter ebenfalls einen Zeiger auf eine Event-
; Parameterstruktur vom Typ evh_EventArgsStruct übergeben:
;
; \iEvent
; \iEventType
; \iEventWindow
; \iEventGadget
; \iEventMenu
; \iEventTimer
; \iEventwParam ; enthält nur unter Windows sinnvolle Werte
; \iEventlParam ; enthält nur unter Windows sinnvolle Werte
;
; Auch der Inhalt dieser Felder entspricht den äquivalenten PB-Befehlen WaitWindowEvent(), EventType(),
; EventWindow(), usw.
;
; Der Rumpf der eigenen Event-Bearbeitungsprozedur ist somit genau so aufgebaut, wie eine Eventprozedur:
;
; Procedure Name(*stEventArgs.evh_EventArgsStruct)
; ...
; EndProcedure
;
; WICHTIG:
; Bitte nicht vergessen den Parameter (*stEventArgs.evh_EventArgsStruct) immer in die eigenen Event-Bearbeitungs-
; prozedur einzubauen, da es sonst zwangsläufig zu einem Rücksprungfehler kommt! (=> Das Programm stürzt ab,
; weil die Daten vom Stack nicht abgeholt wurden)
;
; *stEvents (optional): *stEvents stellt einen Zeiger auf eine Event-Parameterstruktur dar.
; Ist dieser Zeiger =! 0 (zeigt er also auf eine initialisierte Struktur), dann ermittelt die
; Prozedur evh_ProcessEvents() die PureBasic Fensterevents nicht selbst, sondern bearbeitet die Events,
; die mittels der *stEvents-Struktur übergeben wurden.
;
; Hiermit ist es möglich, seine eigene Eventbearbeitung bzw. sogar eigene Events zu programmieren,
; die dann über den Eventhandler automatisch ausgewertet werden (sofern diese Events zuvor registriert
; wurden.
;
; Die Struktur, auf die *stEvents zeigt ist ebenfalls vom Typ evh_EventArgsStruct und hat folgenden Aufbau:
;
; \iEvent
; \iEventType
; \iEventWindow
; \iEventGadget
; \iEventMenu
; \iEventTimer
; \iEventwParam ; enthält nur unter Windows sinnvolle Werte
; \iEventlParam ; enthält nur unter Windows sinnvolle Werte
;
; Werden die Parameter *stEvents und *OwnEventHandler nicht genutzt, dann können sie weggelassen werden.


Weiter unten gibt es einen downloadlink auf ein Zip-Archiv mit dem Sourcecode des Eventhandlers-Includes sowie zwei Demoprogrammen.
Ich hoffe den Code kann jemand von Euch gebrauchen, auch wenn er sicherlich noch erweiterungsfähig ist.
Erstellt wurde er jedenfalls gewissenhaft. Solltet Ihr dennoch Fehler darin finden, wäre ich über Rückmeldungen hier im thread dankbar.

Viel Spaß damit.

Gruß Kurzer

Edit1:
Include und Demo erweitert.

Änderungen:
- Man kann einem bereits registrierten Gadget/Menüitem nun durch nochmaligen Aufruf von evh_SetGadgetEvent(), evh_SetMenuEvent() bzw. evh_SetWindowEvent() zur Laufzeit eine neue Eventprozedur zuordnen.

Edit2:
Include und Demo erweitert.

Änderungen:
- Anmerkung von ts-soft umgesetzt. Die Prozedur evh_ProcessEvents() hat einen weiteren Parameter bekommen.
iObserveWindow = Handle des Hauptfensters.
Wird in diesem Fenster ein #PB_Event_CloseWindow ausgelöst (Fenster wird geschlossen), dann gibt evh_ProcessEvents() ein #False zurück, in allen anderen Fällen ein #True. Dadruch wird ein While/Wend Eventloop ermöglicht.

Edit3:
Include und Demo erweitert.

Änderungen:
- Ein neuer Befehl ermöglicht nun auch das Registrieren von ganzen Fenstern:
evh_SetWindowEvent(iWindowNr, iEventType, iEventProcedure)
Verhalten analog zu evh_SetGadgetEvent().

- evh_Init() benötigt nun kein Parameter mehr.
Man muß nicht mehr im Vorfeld wissen wieviel Gadgets zu verwalten sind.

- Die zugeordneten Eventprozeduren bekommen nun explizit die folgenden Parameter übergeben:
iEvent.i, iEventType.i, iEventWindow.i, iEventControlNr, iEventwParam.i, iEventlParam.i
Diese Parameter müssen in der Prozedurdefinition vorhanden sein.
Nähere Erklärungen sind oben im Infotext zu finden.

Edit4:
Include und Demo erweitert.

Änderungen:
- Die zugeordneten Eventprozeduren bekommen nun nicht mehr (wie unter Edit 3 beschrieben) einzelne Parameter übergeben, sondern einen Zeiger auf eine Parameterstruktur:

\iEvent
\iEventType
\iEventWindow
\iEventGadget
\iEventMenu
\iEventwParam
\iEventlParam

Die Eventprozeduren haben somit nur noch einen Parameter statt sechs. Gleiches gilt für die Parameter einer eigenen Event-Bearbeitungsprozedur.

Edit5:
Include und Demo erweitert.

Änderungen:
- Vorschlag von PureLust umgesetzt
Die Prozedur evh_ProcessEvents() hat einen weiteren Parameter bekommen: *stEvents
Der Aufruf sieht nun wie folgt aus: evh_ProcessEvents(iTimeOut, iObserveWindow, *OwnEventHandler, *stEvents)

*stEvents ist ein Pointer auf eine Parameterstruktur (Aufbau siehe Edit 6).
Ist dieser Pointer initialisiert, dann wird evh_ProcessEvents() die Events nicht selbst ermitteln, sondern den Event bearbeiten, der über die Struktur übergeben wurde.
Dadurch kann evh_ProcessEvents() in einen eigenen Evenhandler-Loop integriert werden.
(Nähere Details siehe Infotext oben)

Edit6:
Include und Demo erweitert.
Ups, ich hatte den Eventhandler seinerzeit noch zweimal erweitert, aber vergessen diesen Thread hier anzupassen.
Das wird hiermit nachgeholt. Sorry an alle die meinen Code benutzen und somit nicht in den Genuss der neuen Funktionalität gekommen sind.

Änderungen:
Alle evh_SetxyzEvent() Befehle enthalten nun zusätzlich den Parameter WindowNr.
Dieser ist für den neuen Befehl evh_RemoveEvent() nötig.

Den neuen Befehl evh_RemoveEvent(WindowNr, ItemNr, EventType) zugefügt.
Hiermit können während der Programmlaufzeit einzelne Eventzuordnungen wieder entfernt werden oder alle Eventzuordnungen eines Fensters auf einen Schlag entfernt werden.

Der Befehl evh_Init() muss nicht mehr aufgerufen werden. Der Handler initialisiert sich bei der ersten Eventzuordnung selbst.

Die evh_EventArgsstruct wurde um iEventTimer erweitert.

\iEvent
\iEventType
\iEventWindow
\iEventGadget
\iEventMenu
\iEventTimer
\iEventwParam
\iEventlParam

Hiermit wird einer Eventprozedur, die einem WindowTimer-Event zugeordnet wurde, die Nummer des Timers übermittelt. Näheres siehe Beispielquellcode im Downloadpaket.

Edit7:
Include erweitert.

Änderungen:
Die beiden Windows-spezifischen Funktionen EventwParam() und EventlParam() werden nur noch unter Windows mitkompiliert. Dadurch funktioniert das Include auch unter anderen Betriebssystemen (Danke an ts-soft für den Hinweis)
Die zugehörigen Strukturfelder \iEventwParam.i und \iEventlParam.i enthalten unter Nicht-Windows Installationen den Wert 0

Das Zip-Archiv mit Quellcode und zwei Demoprogrammen ist hier herunterzuladen.
Zuletzt geändert von Kurzer am 22.07.2012 16:59, insgesamt 17-mal geändert.
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7028
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von STARGÅTE »

Tolle Idee.

Aber ist das nicht eine große einschränkung wenn du für die Events nur noch Prozeduren ohne Parameter übergeben kannst ?
Also es gibt doch bei dir jetzt keine möglichkeit bei einem Event eine Procedure aufrufen zu lassen, die auch ein Parameter hat ?
Damit meine ich jetzt nicht die evh_CallOwnEventHandler() Procedure, denn da könnte mna ja auch nur Integers übergeben.

Zur evh_ProcessEvents()

Wäre dort eine Map nicht besser geeignet als mittels Schleife alle Events durchzu gehen und zu testen ob es mit den aktuellen Event übereinstimmt.
Damit meine ich, jedes Event bekommt eine Art Key$ bestehent aus iEventGadget, iEventType, usw.
Sodass dann "schneller" darauf zugegriffen werden kann.
Das würde zusätzlich das Array ersetzen, welches du ja immer genau vorher Dimensionieren musst.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von Kurzer »

Ich habe noch einmal an dem Include geschraubt.
Man kann einem bereits registrierten Gadget/Menüitem während der Laufzeit durch nochmaligen Aufruf von evh_SetGadgetEvent() bzw. evh_SetMenuEvent() eine neue Eventprozedur zuordnen. Das war vorher nicht vorgesehen.

@Stargate: Wegen der Parameter. Ja, man kann keine Parameter übergeben, das ist richtig. Als Parameter kämen ja auch maximal nur jene infrage, die auch der OwnEventHandler()-Prozedur übergeben werden.
Ich persönlich habe es nicht gebraucht, aber das ist ja der Vorteil, wenn man code als Include veröffentlicht. Man kann ihn selbst noch erweitern. :wink:

Die Sache mit der Map statt des Arrays: Ich habe mir das vorher überlegt, mit welcher Technik ich die Daten verwalten sollte.
Ich denke mir, daß die Nutzung einer Map() einerseits zuviel Overhead mitbringt (ohne jetzt genau zu wissen wieviel Kilobytes die entsprechende Lib nun benötigt). Ein Array ist ja quasi ein integraler Bestandteil von PB (ohne, daß die Funktinalität dazu in eine Lib ausgelagert werden musste).
Und zum anderen gibt es die Map() in den älteren PB Versionen noch nicht, damit wäre die Verwendung dort schon mal ausgeschlossen.

Geschwindigkeitseinbußen befürchte ich durch den loop nicht, da sich das vermutlich erst bei einer Gadgetanzahl jenseits der 10'000 Stück für den User bemerkbar macht. Vorher geht eher noch Windows in die Knie, wegen der vielen zu verwaltenden Controls. :lol:

Aber ein Großteil hing halt von meinen persönlichen Bedürfnissen ab. Ich selbst habe kein Problem damit die maximale Anzahl an registrierbaren Gadgets im evh_Init() anzupassen, wenn neue Gadgets dazukommen. Zumal es ja auch keinen IMA oder so gibt, wenn man diese Grenze überschreitet.

Das ganze sollte halt noch überschaubar und smart bleiben - trotz der kleinen Einschränkungen, die es mit sich bringt.
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
ts-soft
Beiträge: 22292
Registriert: 08.09.2004 00:57
Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel
Wohnort: Berlin

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von ts-soft »

Code: Alles auswählen

Repeat
Until evh_ProcessEvents(25, @OwnEventproc()) = #PB_Event_CloseWindow
Wie sieht das denn aus, wenn ich mehrere Fenster habe? Hab jetzt nicht getestet,
aber mit diesem Constukt kann man im allg. keine Anwendung schreiben, da ja
zumindest 1 Dialog mit Optionen vorhanden ist.
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Bild
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von Kurzer »

Immer wieder schön, wenn mehrere darüber nachdenken. :allright:
Die Argumentation bzgl. mehreren Fenstern ist nicht von der Hand zu weisen. <)

Damit man nicht mit einem Quit-Flag in der eigenen EventProzedur rumhantieren muß, hat die Prozedur evh_ProcessEvents() einen weiteren Parameter bekommen.

evh_ProcessEvents(iTimeOut, iObserveWindow, iOwnEventHandler)

Dadurch ändert sich auch der Aufbau des Eventloops im Main-Programm:

Code: Alles auswählen

While evh_ProcessEvents(25, MainWindow, @OwnEventproc())
Wend
Info zur Erweiterung:
iObserveWindow = Handle des Hauptfensters.
Wird in diesem Fenster ein #PB_Event_CloseWindow ausgelöst (Fenster wird geschlossen), dann gibt evh_ProcessEvents() ein #False zurück, in allen anderen Fällen ein #True. Dadruch wird ein While/Wend Eventloop ermöglicht.

Ich hatte auch überlegt, ob man das Exitverhalten etwas flexibler gestalten sollte und der user den Fensterevent selbst bestimmen kann, der zum Verlassen des Loops führen wird. Aber was außer #PB_Event_CloseWindow ist da sinnvoll? Von daher habe ich es bei #PB_Event_CloseWindow belassen.

Die Sourcen und der Text im ersten posting sind entsprechend angepaßt.
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von Kurzer »

Hallo Stargate,
STARGÅTE hat geschrieben:...Aber ist das nicht eine große einschränkung wenn du für die Events nur noch Prozeduren ohne Parameter übergeben kannst ?
Also es gibt doch bei dir jetzt keine möglichkeit bei einem Event eine Procedure aufrufen zu lassen, die auch ein Parameter hat ?
Damit meine ich jetzt nicht die evh_CallOwnEventHandler() Procedure, denn da könnte mna ja auch nur Integers übergeben.
Hmm, kannst Du mir hier mal ein Beispiel geben, was Du der Eventprozedur eines Buttons z.B. als Parameter übergeben würdest?
Ich will den Eventhandler gern erweitern, aber mir fällt dafür gerade kein sinnvolles Beispiel ein.

Man könnte höchsten die gleichen Parameter übergen, die auch an die evh_CallOwnEventHandler() Procedure übergeben werden.
Also: iEvent.i, iEventType.i, iEventWindow.i, iEventGadget, iEventMenu.i, iEventwParam.i, iEventlParam.i

Wenn Du es anders meinst, dann kann ich das gerade nicht nachvollziehen.

Es ist ja so, daß Du die Eventprozedur nur einmal am Anfang definierst.

Code: Alles auswählen

evh_SetGadgetEvent(Window_Main_Buttons(1), #PB_EventType_LeftClick, @Button1Click())
Was für Parameter würdest Du hier noch übergeben wollen? Eine Variable?

Man kann ja auch in der angesprungenen Prozedur wieder eine andere Prozedur aufrufen, wobei man dort alle Möglichkeiten mit den Parametern hat.
Also z.B.:

Code: Alles auswählen

Procedure Button1Click()
  SetzeUhrzeit(MeinTextfeld, Date())
EndProcedure
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von Kurzer »

- Ein neuer Befehl ermöglicht nun auch das Registrieren von ganzen Fenstern:
evh_SetWindowEvent(iWindowNr, iEventType, iEventProcedure)
Das Verhalten entspricht dem von evh_SetGadgetEvent().

- evh_Init() benötigt nun kein Parameter mehr.
Man muß nicht mehr im Vorfeld wissen wieviel Gadgets zu verwalten sind.

- Die zugeordneten Eventprozeduren bekommen nun explizit die folgenden Parameter übergeben:
iEvent.i, iEventType.i, iEventWindow.i, iEventControlNr, iEventwParam.i, iEventlParam.i
Diese Parameter müssen in der Prozedurdefinition vorhanden sein.
Nähere Erklärungen dazu sind oben im ersten Beitrag zu finden.

------------

Die Quellen im ersten Beitrag sind aktualisiert worden.
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
mk-soft
Beiträge: 3845
Registriert: 24.11.2004 13:12
Wohnort: Germany

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von mk-soft »

Solltest vieleicht an die Procedure nur einen Pointer (*EventArgs.udtEventArgs) übergeben. Hat man nicht immer den ganzen Parameterwust.
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Benutzeravatar
Kurzer
Beiträge: 1617
Registriert: 25.04.2006 17:29
Wohnort: Nähe Hamburg

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von Kurzer »

Schöner Vorschlag. Ist umgesetzt.

- Die zugeordneten Eventprozeduren bekommen nun nicht mehr einzelne Parameter übergeben, sondern einen Zeiger auf eine Parameterstruktur:

\iEvent
\iEventType
\iEventWindow
\iEventGadget
\iEventMenu
\iEventwParam
\iEventlParam

Die Eventprozeduren haben somit nur noch einen Parameter statt sechs. Gleiches gilt für die Parameter einer eigenen Event-Bearbeitungsprozedur.

------------

Die Quellen im ersten Beitrag sind aktualisiert worden.
"Never run a changing system!" | "Unterhalten sich zwei Alleinunterhalter... Paradox, oder?"
PB 6.02 x64, OS: Win 7 Pro x64 & Win 11 x64, Desktopscaling: 125%, CPU: I7 6500, RAM: 16 GB, GPU: Intel Graphics HD 520
Useralter in 2024: 56 Jahre.
Benutzeravatar
PureLust
Beiträge: 1145
Registriert: 21.07.2005 00:02
Computerausstattung: Hab aktuell im Grunde nur noch 'nen Lenovo Yoga 2 Pro im Einsatz.
Wohnort: am schönen Niederrhein

Re: Ein smarter Eventhandler für Gadgets/Menuitems und Toolb

Beitrag von PureLust »

Hi Kurzer,

momentan ermöglichst Du ja durch "*OwnEventHandler" einen anderen EventHandler nach Deinem EventHandler aufzurufen, jedoch nicht, einem anderen EventHandler die Events an Deinen zu übergeben.
Vielleicht wäre es noch sinnvoll eine solche Möglichkeit einzubauen, damit man Deinen EventHandler auch nach einem anderen ausführen kann.

2 kleine Beispiele dazu, wie ich das meine:

1. Ich verfeinere momentan mein Touch-Control, welches auch einen eigenen EventHandler benötigt um Eventschwächen von PB abzufangen oder auch Events bei Bedarf zu "verbiege".
Ich gebe also u.U. andere Events zurück als sie es ursprünglich waren oder erzeuge auch neue Events bei Bedarf.
In einem solchen Fall (wo also u.U. Events verändert bzw. erzeugt werden) bräuchte man eine Möglichkeit Deine EventProcessing-Routine im Nachhinein aufzurufen und die Events von außen zu übergeben.

2. Man verwendet z.B. einen WindowCallback um auf bestimmte Events zu reagieren die PB nativ nicht durch reicht.
Auch hier könnte es nützlich sein Deiner EventProcessing-Routine Events von außen übergeben zu können, um z.B. Events durch zureichen, die PB nativ erst gar nicht zur Verfügung stellt.

In meinem eigenen Event-Handler habe ich das so gelöst, dass ich den Teil mit WaitWindowEvent() (also den Teil der auf ein Event wartet und dann alle Events in eine Structur schreibt) von dem Teil getrennt habe, der die eigentliche Auswertung der Events durchführt. Die auswertende Prozedur wird dann eben nur noch von der ersten mit Übergabe der Event-Struktur aufgerufen.
Durch diese Trennung ist es dann also bei Bedarf auch möglich nur den auswertenden Teil separat aufzurufen.

Hoffe es ist einigermaßen verständlich was ich meine. :D

Gruß, PL.
[Dynamic-Dialogs] - komplexe dynamische GUIs einfach erstellen
[DeFlicker] - Fenster flimmerfrei resizen
[WinFX] - Window Effekte (inkl. 'durchklickbares' Window)
Antworten