PostEvent (Custom-Event) mit Zufallswerten legal?

[Regenduft]

Hallo miteinander, laaange nicht mehr hier gewesen,

mir ist aufgefallen, dass die PureBasic-Doku einige Einschränkungen für die Wertebereiche der Parameter von PostEvent() nennt, die tatsächlich aber überhaupt nicht zu existieren scheinen (bei Custom-Events!).

Konkret:
"Objekt" dürfe nur eine "positive Ganzzahl" sein und
"Type" dürfe nur ein Wert größergleich "#PB_EventType_FirstCustomValue" sein (auch bei Custom-Events).

Ist hier nur die Doku etwas unklar geschrieben, ist das wegen Plattformunabhängigkeit so geschrieben oder stehe ich einfach auf dem Schlauch?

Hier noch ein kleiner Testcode (wobei das Ergebnis wohl nur mäßige Aussagekraft besitzt):

Code: Alles auswählen

EnableExplicit

Global w, o, t, d

Procedure RandomPost()
  RandomData( @w, SizeOf(Integer) )
  RandomData( @o, SizeOf(Integer) )
  RandomData( @t, SizeOf(Integer) )
  RandomData( @d, SizeOf(Integer) )
  PostEvent(#PB_Event_FirstCustomValue, w, o, t, d)
EndProcedure


If OpenWindow(0, 200, 200, 100, 100, "PostEvent")
  
  AddWindowTimer(0, 0, 333)
  
  Repeat
    
    Select WaitWindowEvent()
      
    Case #PB_Event_FirstCustomValue
      Debug ElapsedMilliseconds()
      Debug "w " + Bool( EventWindow() = w )
      Debug "o " + Bool( EventGadget() = o )
      Debug "t " + Bool( EventType() = t )
      Debug "d " + Bool( EventData() = d )
      Debug ""
      
    Case #PB_Event_Timer
      RandomPost()
      
    Case #PB_Event_CloseWindow
      Break
      
    EndSelect
    
  ForEver
  
EndIf

[Bisonte]

"Objekt" dürfe nur eine "positive Ganzzahl" sein

Korrekt ! Es gibt keine negative Ganzzahl innerhalb von PB Objekten als "ID"
Oder hast du schon mal ein Window mit : OpenWindow(-11, 0, 0..... erstellt ?

Type" dürfe nur ein Wert größergleich "#PB_EventType_FirstCustomValue" sein (auch bei Custom-Events).

Ich tippe darauf, dass man von vornherein "Bugmeldungen" verhindern wollte. Es ist eigentlich eher ein Selbstschutz,
damit die EventTypes (und auch Events) nicht mit schon vorhandenen "kollidieren".

[ccode_new]

Das hier ist aber erlaubt. (Ach ja: Das schöne #PB_Any)

Code: Alles auswählen

OpenWindow(-1,0,0,800,600,"Test",#PB_Window_SystemMenu)

Repeat
  
Until WindowEvent() = #PB_Event_CloseWindow

[Regenduft]

Danke für die Antworten!

"Objekt" dürfe nur eine "positive Ganzzahl" sein

Korrekt ! Es gibt keine negative Ganzzahl innerhalb von PB Objekten als "ID"
Oder hast du schon mal ein Window mit : OpenWindow(-11, 0, 0..... erstellt ?

Aber gerade der Parameter "Window" darf laut PB-Doku negativ sein... "Objekt" aber nicht... und beim Testcode aus meinem ersten Post gibt es keine Probleme... Ich bin also immernoch skeptisch...


Um mal zu erklären wozu ich überhaupt frage: Ich kommuniziere aus einem Audio-I/O-Thread mit dem Hauptprogramm (das nur mit der GUI beschäftigt ist).
Ich nutze PostEvent() unter anderem auch für's Debugging. Da der Thread zeitkritisch ist wäre "viel rumgepfriemel im Thread" (wie z.B. Speicherallokation) nur möglich, wenn ich mit sehr hoher Audio-Latenz (also großen Puffern) arbeite. Generell wäre es blöd, wenn die Rückmeldung von Unterläufen oder Überläufen zu mehr Unterläufen und Überläufen führen würde.

Mit PostEvent() kann ich da ratz fatz 4 Integerwerte rausfeuern... zumindest in der Theorie... und praktisch scheinbar auch... wäre aber schlecht, wenn ich da irgendwie die PB-Interna verzwirbel und irgendwelche "böden Sachen trigger".


Nochmal in kurz: Ich poste immer Custom-Events (#PB_Event_FirstCustomValue) und max. vier Integerwerte (nagativ und positiv).


Hoffe das war jetzt nicht zu wirr beschrieben...

[#NULL]

Dafür gibt es ja EventData. Wenn du dafür nicht jedes mal eine neue Struktur alloziieren willst, dann bau dir vielleicht eine Art pool, aus dem du Elemente wiederverwenden kannst.

[mk-soft]

Die PostEvents werden so wie du sie übergibst an deinen EventLoop übergeben.

Wenn die BindEvent oder BindGadgetEvent verwendest kann es zu eigenartigen verhalten von deinem Programm geben.

Wenn das Event #PB_Event_CloseWindow sendest, schließt nicht das Fenster, sondern du erhältst das nur Event.
Somit kommst du mit Deinem Event-Managament durcheinander. Also doch nicht irgendwelche undefinierten Events schicken

[mk-soft]

Solange man ein eindeutigen Event erstellt, kann man die Parameter so nutzen wie man möchte.

Beispiel Update

Code: Alles auswählen

Enumeration CustomEvent #PB_Event_FirstCustomValue
  #MyEvent_Data
EndEnumeration

Procedure DoEventMyData()
  Protected result.s, *data.String, cnt
  result = "MyEventData "
  result + " / v1 = " + EventWindow() 
  result + " / v2 = " + EventGadget() 
  result + " / v3 = " + EventType() 
  *data = EventData()
  If *data
    result + " / v4 = " + *data\s
    FreeStructure(*data)
  EndIf
  AddGadgetItem(0, -1, result)
  cnt = CountGadgetItems(0) - 1
  SetGadgetState(0, cnt)
  SetGadgetState(0, -1)
EndProcedure

Procedure DoEventGadget()
  Protected gadget = EventGadget()
  Debug "Gadget " + gadget + " / EventType " + EventType
EndProcedure

Structure udtWork
  ThreadID.i
  Exit.i
EndStructure


Procedure thWork(*data.udtWork)
  Protected *msg.String, cnt
  With *data
    While Not \Exit
      Delay(1000)
      *msg = AllocateStructure(String)
      cnt + 1
      *msg\s = "Message from Thread Number " + cnt
      PostEvent(#MyEvent_Data, Random(100), Random(200, 100), Random(300,200), *msg)
    Wend
    \Exit = 0
  EndWith
EndProcedure

Global th1.udtWork

If OpenWindow(0, 0, 0, 800, 600, "My Events", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  ListViewGadget(0, 5, 5, 790, 590)
  
  BindEvent(#MyEvent_Data, @DoEventMyData())
  BindGadgetEvent(0, @DoEventGadget())
  
  th1\ThreadID = CreateThread(@thWork(), th1)

  Repeat
    Event = WaitWindowEvent()
    ; Window = EventWindow() ; <- ungültigte Abfrage
    ; Gadget = EventGadget() ; <- ungültige Abfrage
    Select Event
      Case #PB_Event_CloseWindow
        Window = EventWindow() ; <- Abfrage
        Debug "Window Event"
        th1\Exit = 1
        Delay(100)
        Break
      Case #PB_Event_Gadget
        Gadget = EventGadget() ; <- Abfrage
        Debug "Gadget Event "
    EndSelect
  ForEver
EndIf

P.S.
Somit darf aber im Event-Management nicht mehr EventWindow() oder EventGadget vor Event() abgefragt werden!

[Regenduft]

@ #NULL:
Der Pool ist eine gute Anregung! ... Beim "zeitkritischen Debugging" habe ich mich da echt zum Teil böse verschätzt wie schnell man Unter- und Überlaufe produziert.

@ mk-soft:

Somit darf aber im Event-Management nicht mehr EventWindow() oder EventGadget vor Event() abgefragt werden!

Das verstehe ich leider nicht ganz. Ich denke Du beziehst Dich auf die Zeilen in Deinem Code, welche Du mit "ungültigte Abfrage" bzw. "Abfrage" markiert hast. Ich erkenne nicht was sich (funktional) ändern würde, wenn man die "Abfrage"-Zeilen auskommentieren würde und bei den "ungültige Abfrage"-Zeilen die Auskommentierung aufheben würde - vorrausgesetzt, dass man für eigene Events nur "ordentliche Custom-Events" verwendet (Event >= #PB_Event_FirstCustomValue) und keine PB-Events vortäuscht (Event < #PB_Event_FirstCustomValue).

[mk-soft]

Da im Thread der Parameter Window im PostEvent für die eigene Daten verwendet wird ist im Main-Loop bei Abfrage von EventWindow der Wert auch vorhanden
und bezieht sich nicht mehr auf ein Window
Eigendlich sollte man diesen Wert von EventWindow nur abfragen wenn auch eine Event für Window kommt, wie #PB_Event_CloseWindow, #PB_Event_SizeWindow, etc.

Das gleiche gilt für den Parameter Objekt im PostEvent für die Abfrage vom EventGadget im Main-Loop.

Code: Alles auswählen

  Repeat
    Event = WaitWindowEvent()
    Window = EventWindow() ; <- ungültigte Abfrage
    If Window <> 0
      Debug "Main EventWindow " + Window
    EndIf
    ; Gadget = EventGadget() ; <- ungültige Abfrage
    Select Event
      Case #PB_Event_CloseWindow
        Window = EventWindow() ; <- Abfrage
        Debug "Window Event"
        th1\Exit = 1
        Delay(100)
        Break
      Case #PB_Event_Gadget
        Gadget = EventGadget() ; <- Abfrage
        Debug "Gadget Event "
    EndSelect
  ForEver

[mk-soft]

Ein DataPool mit LinkedList zu erstellen ist eigendlich nicht erforderlich und benötigt zusätzlich eine Zugriffskontrolle über Mutex auf dem Zugriff der LinkedList.
Mit AllocateStructure und FreeStructure kann man dieses viel einfacher realisieren und der Zugriff auf die Daten ist auch sehr einfach.
Ob nun der Speicher über AddElement oder über AllocateStructure angefordert und entsprechend wieder freigeben wird ist somit nicht relevant.
Dieses Verfahren verwende ich auch in mein Modul ThreadToGUI und läuft absolute fehlerfrei.