Software > Coding

Hilfe! evnt_multi() ignoriert Mausklick

<< < (4/5) > >>

mfro:
Darüber hinaus: zu viel (unnötiges) wind_update() bremst das Multitasking.


--- Code: ---wind_update(BEG_UPDATE)
...
wind_update(END_UPDATE)

--- Ende Code ---

klammert Zeichenoperationen, wo Du (per VDI-Calls) selbst zeichnest (also die Rechteckliste abarbeitest). Der call sorgt (nur) dafür, dass die AES so lange die Rechteckliste "in Ruhe lassen".


--- Code: ---wind_update(BEG_MCTRL)
...
wind_update(END_MCTRL)

--- Ende Code ---

klammert *nur* "lokale" Mausaktionen (also z.B. wenn Du einen Rahmen aufziehst oder eine Fenster-Formularaktion machst). Das verhindert, dass jemand anders als Du von den Aktionen was mitbekommt.

Count:
Danke, das war der entscheidende Tipp. Ich habe die ganzen wind_update()-Aufrufe nochmal kontrolliert und einiges rausgeschmissen. Jetzt funktioniert alles, wie es soll. Wo genau das Problem lag, kann ich leider nicht sagen.

Thorsten Otto:

--- Zitat von: mfro am Di 23.02.2021, 09:15:05 ---Das ist dann zwar nicht die Ursache für dein Problem, aber trotzdem falsch. Das "continue" hat da nichts verloren, das "==" auch nicht.

--- Ende Zitat ---

Das kann man so nicht sagen. Wenn der timer nur für Cursor-Blinken benutzt wird, dann möchte man im allgemeinen nicht daß der blinkt, wenn danach noch andere Aktionen wie redraw ausgeführt werden. Auch möchte man vlt nicht daß er blinkt, solange eine Maustaste gedrückt ist. Jedenfalls habe ich  in einigen meiner Programme was ähnliches drin. Auf jeden Fall dürfte, nach der Änderung auf ==, das keinen EInfluss mehr auf die Button-Events haben. Lässt sich einfach testen, indem man mal MU_TIMER aus der Maske der zu erwartenden Events entfernt.

mfro:
Über das == kann man streiten, auch wenn mir schwerfällt, mir eine Situation vorzustellen, wo ich einen Event nur dann bearbeite, wenn die AES gerade keinen anderen Event (mehr oder weniger zufällig) "dazugepackt" haben.
Wenn es so eine Situation gäbe (mir - soweit ich mich erinnere - noch nicht untergekommen), würde ich das jedenfalls expliziter hinschreiben.

Das continue ist m.E. jedenfalls verkehrt. Da wird potentiell ein (oder mehrere) Event(s) weggeschmissen, der/die so auch nicht wieder auftauch[t|en].
Wenn's beispielsweise das Loslassen einer Maustaste war (auf das man gerade sehnlichst wartet), kann das ziemlich blöd sein und nach dem Fehler kann man sich totsuchen.

Thorsten Otto:

--- Zitat von: mfro am Di 23.02.2021, 12:51:52 ---Das continue ist m.E. jedenfalls verkehrt. Da wird potentiell ein (oder mehrere) Event(s) weggeschmissen

--- Ende Zitat ---

Nein. Wenn da steht

--- Code: ---if (event_ret == MU_TIMER)
{
    do_something();
    continue;
}

--- Ende Code ---

dann ist das lediglich eine kleine Optimierung. In dem Fall waren ja keine anderen bits gesetzt und müssen auch nicht weiter getested werden.
Natürlich müsste man dann theoretisch nochmal extra testen, ob MU_TIMER zusammen mit anderen Events aufgetreten ist. Ob man das will hängt aber von der Anwendung ab. In vielen Fällen wird man MU_TIMER nur behandeln wollen, wenn sonst nichts zu tun war,

PS.: das Problem scheint ja auch gelöst zu sein, und mit MU_TIMER nichts zu tun zu habne.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete