EM_EventManager (crossplattform)

[Lambda]

Sehr schön , werde diese Lösung für die MCF Controls nutzen, da man auf anderen Plattformen sonst eine Update Funktion aufrufen müsste. Selbst die Windows Lösung ist aufwendig, da die Canvas-Events durch ein Callback nicht mehr empfangen werden.

Edit: Habe es mir jetzt genauer angesehen. Ist denn eine Map wirklich am sinnvollsten? (dieses String-Backen) Auch wäre es sehr praktisch beim setzen des Handler mehrere Event-Typen gleichzeitig zu setzen wie #PB_EventType_LeftClick|#PB_EventType_RightClick etc.

[ts-soft]

Edit: Habe es mir jetzt genauer angesehen. Ist denn eine Map wirklich am sinnvollsten? (dieses String-Backen)

Sollte schneller sein, als durch eine Linklist zu iterieren

Auch wäre es sehr praktisch beim setzen des Handler mehrere Event-Typen gleichzeitig zu setzen wie #PB_EventType_LeftClick|#PB_EventType_RightClick etc.

Laß den Type weg (-1) und Werte dann in der
HändlerProc selber aus. Die EventProc wird dann für alle nicht vergebenen EventTypen aufgerufen (die einzel vergebenen
haben Vorrang!).

Gruß
Thomas

[Lambda]

Ich hatte da eher Arrays im Sinn. Glaube Str() und FindMapElement statt direktem Zugriff verlangsamen es etwas.

Zu letzterem: Wenn im Beispiel der letzte Parameter also nicht angegeben wird, müsste doch der "Okay"-Button bei beliebigem Event "Okay clicked" ausgeben - was es nur bei Klick tut. Der Button ist ja etwas eigen, aber zumindest bei Fokus sollte es doch kommen oder nicht?

[ts-soft]

Zu letzterem: Wenn im Beispiel der letzte Parameter also nicht angegeben wird, müsste doch der "Okay"-Button bei beliebigem Event "Okay clicked" ausgeben - was es nur bei Klick tut. Der Button ist ja etwas eigen, aber zumindest bei Fokus sollte es doch kommen oder nicht?

Der Button in PB unterstützt nur LeftClick!

Ich glaube nicht, das ein Array schneller wird, jedenfalls nicht so viel, das es irgendeinen Einfluss hätte.

[Lambda]

Hm, dachte zumindest die Fokus-Ereignisse , naja.

Mache mir nur um die massiven Events wie MouseMove oder SizeWindow Sorgen.

[ts-soft]

Wenn Du es beschleunigen möchtest, Speicher die Daten per GadgetData ab. Aber dann nimmst Du dem
Anwender eine Möglichkeit, diese selber zu nutzen. Per API mit Prop oder ähnlichem wäre wieder nicht
Crossplattform. Also wird meine Variante schon die schnellste Möglichkeit sein, solange größtmögliche
Kompatibilität und Crossform funktionalität gewährt sein soll.

Gruß
Thomas

[NicTheQuick]

Wenn Du es beschleunigen möchtest, Speicher die Daten per GadgetData ab. Aber dann nimmst Du dem
Anwender eine Möglichkeit, diese selber zu nutzen.

Aber dafür gibt es doch Makros zum Überschreiben vorhandener Funktionen.

Code: Alles auswählen

Procedure _SetGadgetData_Wrapper(gadgetId.i, value.i, index.i = 0)
	Protected *mem.Integer = GetGadgetData(gadgetId)
	If (Not *mem)
		*mem = AllocateMemory(2 * SizeOf(Integer))
		SetGadgetData(gadgetId, *mem)
	EndIf
	*mem + index * SizeOf(Integer)
	*mem\i = value
EndProcedure

Procedure.i _GetGadgetData_Wrapper(gadgetId.i, index.i = 0)
	Protected *mem.Integer = GetGadgetData(gadgetId)
	If (Not *mem)
		*mem = AllocateMemory(2 * SizeOf(Integer))
		SetGadgetData(gadgetId, *mem)
	EndIf
	*mem + index * SizeOf(Integer)
	ProcedureReturn *mem\i
EndProcedure

Macro SetGadgetData(Gadget, Value)
	_SetGadgetData_Wrapper(Gadget, Value)
EndMacro

Macro GetGadgetData(Gadget)
	_GetGadgetData_Wrapper(Gadget)
EndMacro

;für den EventManager dann

Procedure __EM_SetGadgetData(gadgetId.i, value.i)
	_SetGadgetData_Wrapper(gadgetId, value, 1)
EndProcedure

Procedure.i __EM_GetGadgetData(gadgetId.i)
	_SetGadgetData_Wrapper(gadgetId, 1)
EndProcedure

Dann hat man seine ganz eigenen Daten für den EventManager und für den normalen Nutzer. Ich habe es allerdings noch nicht getestet. Die Voraussetzung sollte z.B. auch sein, dass GetGadgetData() beim ersten Aufruf auf ein Gadget immer 0 zurück gibt. Sonst kommt es bei dieser Variante schnell zu Fehlern.

[ts-soft]

Schöner Code, aber selbst wenn das Funktionieren sollte, wir reden hier von nano-Sekunden, die im
Eventloop IMHO eigentlich keinen Einfluss haben sollten , ansonsten verzögert ein Procedure-
Aufruf, das ganze ja schon zu viel
Ausserdem reicht ein Wert ja auch gar nicht, der Eventtype und die ProcedureAdresse sind erforderlich,
aber das ist ja auch implementierbar.

Also wer das Einbauen möchte, soll das Tun, aber bitte möglichst andere Funktionsnamen nutzen,
als in meinem Manger

[Lambda]

Ich vermute das wichtigste Ereignis fällt allerdings aus. Wenn das Gadget modifiziert wird (ResizeGadget()), was bei WinAPI #WM_SIZE und #WM_EXISTSIZEMOVE darstellt. Auch letzteres ist sehr wichtig, denn bei flinker Veränderung kommt die Aktualisierung nie exakt mit. Könnte dieser Event-Typ zu PB noch hinzugefügt werden?

[ts-soft]

#PB_Event_SizeWindow wird ja unterstützt, als #EM_Special, es werden alle native PB events unterstützt sowie
benutzerdefinierte, die per PostEvent ausgelöst werden, aber keine API-Events. Da musst Du im Callback dann selber
ein unterstütztes Event feuern.

Also alles, was im EventLoop von PB ankommt, wird auch unterstützt!