hi,
Danke für eure Antworten.
Ich hatte extra o:activate gewählt weil es ein (bekanntest) Beispiel für einen Codeblock Slot ist.
auch hat o:activate ja keinen weiteren Parameter was die Sache vereinfacht.
Das Beispiel mit dem "Kaffee" Thread ist auch nicht das was ich mit "extern" meine denn innerhalb von Xbase++ Threads kann ich ja Parameter übergeben.
vielmehr meine ich Sachen wie
Code: Alles auswählen
o:measureItem := {| nItem, aDims, self | ... }
oder
o:drawItem := {| oPS, aInfo, self | ... }
was ja im GUI Thread läuft ... und die beiden haben auch noch Parameter ...
Das Problem an dem ich gerade war betrifft
Code: Alles auswählen
XbpToolBar():buttonClick := {| oButton,uNil,self | ... }
wo ich nicht wusste wie ich das Object oButton in ein PostappEvent() packen kann wenn ich den Codeblock aus einem String zusammenstellen soll.
Der o:buttonClick Codeblock Slot wird ja im "meinem" Source belegt aber ich kann den Codeblock ja in jedem (GUI) Thread EVALuieren.
solange es, wie in Huberts Beispiel, nur eine Function/Procedure "ohne" Rückgabe aufruft ist es wohl egal aber ich überlege ob es andere Situationen gibt wo das Prinzip nicht funktioniert ?
deshalb die Frage ob was dagegen spricht einen Codeblock Slot "gleich" zu EVALuieren statt ihn mit einem PostAppEvent() zu "aktivieren" ?