Aktualisierung eines ListIconGadgets trotz offenem Menü?

[alDo]

Bisher hatte ich diese regelmäßige Prüfung in einem Tímeout. So wie es jetzt für mich aussieht brauche ich dieses in diesem Falle nicht mehr. Oder?

[ts-soft]

Das standard timeout für lesen am SerialPort ist 100 ms, sehe also das Problem nicht.
Windows ist nunmal kein Echtzeit-Betriebssystem. Ansonsten programmiere eine
Console. Thread wäre auch noch möglich, hat aber IMHO in diesem Falle mehr Nach-
wie Vorteile.

// edit
Im EventLoop brauchse kein Timeout mehr, wenn Du ein TimerCallback verwendest.
Und dieser nicht wirklich sinnvolle Case 0 Zweig kann auch weg (solche Vergewaltigungen
sollten verboten werden ).

[Kaeru Gaman]

@ts

wenn man mit einem TimeOut bei WaitWindowEvent arbeitet, dann sollte man auch in einem Case auf diesen Timeout prüfen!
diese Vorgehensweise ist völlig richtig, und war bis zur einführung von AddWindowTimer auch die einzig sinnvolle PB-native Lösung.

Nur weil du nicht selber drauf gekomen bist, und es selber nie benutzt hast weil du seit jahren einen (nicht nativen) Timer-Callback verwendest, solltest du eine sinnvolle native Vorgehensweise nicht schmähen.
Anfänger sprechen dir aufgrund deiner Erfahrung Autorität zu, und werten das als fachliche Aussage und nicht als die Fußballspiel-Frotzelei die es effektiv darstellt.

[ts-soft]

diese Vorgehensweise ist völlig richtig, und war bis zur einführung von AddWindowTimer auch die einzig sinnvolle PB-native Lösung.

Wenn man auf Crossplattform angewiesen ist, ist es vielleicht eine Notlösung, mehr nicht. Richtiger wird
es dadurch nicht. Ansonsten kann man unter Windows auf #WM_TIMER reagieren, weil nichts anderes
ist dieses Timeout.

Bei Reaktion auf 0 reagiert man ja nicht aufs Timeout, weil dieses erzeugt ein #WM_TIMER event

[Kaeru Gaman]

Bei Reaktion auf 0 reagiert man ja nicht aufs Timeout, weil dieses erzeugt ein #WM_TIMER event

lol?
das stimmt nicht.

die Einzige Möglichkeit, wie bei einem WaitWindowEvent eine #Null hinten rauskommen kann, ist, wenn diese nach Ablauf des Timeouts der Rückgabewert von WaitWindowEvent ist. (Logik!)
wenn der TimeOut-Rückgabewert eine 275 (#WM_TIMER) wäre, würde niemals nicht unter Keinen Umständen eine Null zurückgegeben werden.

also: die korrekte Verarbeitung des TimeOuts ist das Prüfen auf den Rückgabewert Event = #Null

in der Help heißt es:

Ein optionaler Timeout-Wert (in Millisekunden) kann angegeben werden. Dies veranlasst die Funktion nach einer bestimmten Zeit zur Rückkehr (aus der Wartestellung), wenn keine Ereignisse aufgetreten sind.

auf diese bedingte Rückkehr zu prüfen ist also eine richtige Vorgehensweise, und das tut man also, indem man auf #Null prüft, weil das der Rückgabewert ist den man bekommt wenn diese Bedingung eintritt.

das ist also von einer "Notlösung" so weit ent fernt wie [...] <- hier beliebigen Comedy-verdächtigen Vergleich einsetzen.

[ts-soft]

Okay, #wm_timer kommt tatsächlich nur sporadisch, aber richtiges vorgehen wird es
nicht dadurch das es in diesem falle die beste der schlechten möglichkeiten ist,
es ist und bleibt eine Krücke, weil im eventloop sollte nur auf events reagiert werden,
nicht auf nichtevent.

[Kaeru Gaman]

das ist dann aber ein Problem des TimeOuts an sich, eigentlich an dem gesamten Konzept von PureBasics prozeduraler Ereignisverarbeitung.
auch das "einfrieren" der Ereignisschleife bei Menu oder Verschieben könnte man direkt dem Problemkomplex zuordnen.

auch wenn du die Innere Schleife bei einem WindowedScreen erstellst, verläßt du sie bei keinem Event.
http://www.purebasic.com/german/documen ... creen.html

das ist also bei PureBasic eine durchaus "übliche" Vorgehensweise, dass eine "Ereignisschleife" unter gewissen Bedingungen durchläuft, wenn kein Ereignis anliegt.
insofern würde ich die Programmierweise nicht als "Krücke" bezeichnen, eher die Event-Implementierung von PureBasic selber als "ungewöhnlich".
bezogen auf diese besonderen Eigenheiten von PureBasic ist diese Verfahrensweise als "richtig" einzustufen.

[ts-soft]

das ist also bei PureBasic eine durchaus "übliche" Vorgehensweise, dass eine "Ereignisschleife" unter gewissen Bedingungen durchläuft, wenn kein Ereignis anliegt.

Dann würde ich sagen, es war eine "übliche" Vorgehensweise, weil es gibt ja jetzt Timer.
Leider wurde mein Vorschlag beim Alpha-Testing, einen optionalen Callback Parameter
hinzuzufügen ignoriert.

Ich denke mal, für Screens sollte sich der Timer auch eignen, zumal dadurch eine etwas
regelmässigere Abarbeitung stattfindet. Aber ist nicht mein Interessengebiet, aber testen
solltet Ihr das mal

[Kaeru Gaman]

PS zu vorhin:

von der Idee des Prozeduralen Aufbaus ausgehend, muss es ja möglich sein,
irgendwann im Programmablauf zu fragen "Holla, liegt denn ein Event an?"
dafür ist

Code: Alles auswählen

Event = WindowEvent()

da, und das gibt ggf. #Null zurück, damit man in klassischer PB-Manier prüfen kann

Code: Alles auswählen

If Event

man könnte jetzt natürlich WindowEvent und WaitWindowEvent(TimeOut) dahingehend ändern, dass die niemals #Null sondern ggf. -1 zurückgeben,
und die Konstanten #PB_Event_TimeOut = -1 und #PB_Event_QueueEmpty = -1 einführen, aber das wäre nur kosmetisch, außerdem wäre die If Event Konstruktion nicht mehr möglich.

Deine Sichweise, dass eine Ereignisverarbeitung nur dann durchlaufen werden sollte wenn überhaupt ein Ereignis anliegt, ist ja nicht verkehrt,
allerdings wohl mit den prozeduralen Ansprüchen von PureBasic nicht als Bedingung in der Sprache selber durchsetzbar.
die Kommandos selber dürften das dann nicht ermöglichen, und damit fällt das ganze Freiheitskonzept.

Dann würde ich sagen, es war eine "übliche" Vorgehensweise, weil es gibt ja jetzt Timer.
Leider wurde mein Vorschlag beim Alpha-Testing, einen optionalen Callback Parameter
hinzuzufügen ignoriert.

Ich denke mal, für Screens sollte sich der Timer auch eignen, zumal dadurch eine etwas
regelmässigere Abarbeitung stattfindet. Aber ist nicht mein Interessengebiet, aber testen
solltet Ihr das mal

jeder der nicht nur sporadisch Spiele schreibt sondern sich weitergehend mit dem Thema auseinandersetzt, muss sich grundlegende Gedanken über das Timing machen.
ist schon immer so gewesen, und schon vor Jahren haben die erfahreneren Progger Timer oder Threads benutzt,
und die die gerade aus dem Anfängerbereich entwachsen waren, mit SetFrameRate und einem Delay(0) damit man nicht ganze 100% verbrät.
durch das neue Flag #PB_Screen_SmartSynchronization wurde dieses alte Auslastungsproblem auch gelöst.

Aber PureBasic ist und bleibt auch eine Sprache für den Einsteiger.
Gerade die Tatsache, dass es möglich ist, mit einer Handvoll Befehlen ein Sprite auf den Bildschirm zu kriegen, ist das womit PureBasic seine Hobby-Programmierer im Spielebereich zieht.
Wenn man einsteigt und Ideen hat will man sich nicht drei Monate lang durch eine Anleitung fressen müssen, man will seine Bildchen sich bewegen sehen!
gerade seine Unkompliziertheit ist das, was PureBasic für den Einsteiger attraktiv macht,
und deshalb DARF es in diesem Bereich keine schärferen Restriktionen in der Sprache selber geben.
Dass man dann nach und nach lernt, seine Ereignisse vernünftig zu verarbeiten und zu timen und nicht seine CPU zu braten ist ein Entwicklungsprozess.

Für den unge-time-ten WindowedScreen ist immer noch die innere Event-Schleife die angesagte Vorgehensweise.(*)
das ist schon kompliziert genug für nen Anfänger.

Und wer weitergehend sich ein vernünftiges Framework aufbauen will, der sieht sich mit noch ganz anderen Problemen konfrontiert als dem Timing und seinen Events.


(*) für dich als Nicht-Spiele-Programmierer:
das große Problem bei Spielen ist, dass die Darstellung synchron zum Refresh des Monitors sein muss, nicht synchron zu irgendeinem Timer-Callback.
Damit kommt ein kompletter Problemkomplex hinzu von dem ein Anwendungsprogrammierer völlig verschont bleibt.
deswegen sind die Screen- und Flip-Befehle auf diese Synchronität ausgelegt, und wurden über die Zeit weiterentwickelt die CPU zu entlasten.
das Spielgeschehen selber kann man von Timern steuern lassen, die müssen dann aber asynchron zur Darstellung verarbeitet werden,
und genau das ist der Punkt, warum man einen Anfänger im Spielebereich mit Timern in Ruhe lässt, der hat genug mit der Darstellungssynchronität zu tun.

[Kaeru Gaman]

oben Fußnote neu