Software > Coding

Hilfe! evnt_multi() ignoriert Mausklick

<< < (3/5) > >>

Count:

--- Zitat von: mfro am Di 23.02.2021, 08:08:06 ---
--- Zitat von: Count am Di 23.02.2021, 08:05:47 ---
--- Zitat von: Chocco am Mo 22.02.2021, 20:43:46 ---Mit (event_ret & MU_TIMER) werden doch alle anderen Events ausgeblendet. Mit (event_ret == MU_TIMER) würden nur die ausschließlichen Timer Events abgegriffen.

--- Ende Zitat ---
Nach einer Nacht darüber schlafen, hast du natürlich recht. ;)
Aber das ist leider nicht die Ursache. evnt_multi() liefert wirklich erst beim zweiten Klicken das richtige Event MU_BUTTON zurück.

--- Ende Zitat ---

was hast Du konkret geändert?

--- Ende Zitat ---
Nichts. Ich schreibe das Ergebnis von evnt_multi() direkt in eine Datei und beobachte das. Und es wird alle 300 ms (CURSOR_BLINK_RATE) MU_TIMER (0x20) zurückgeliefert. Erst nach dem zweiten Mausklick MU_BUTTON (0x02).

mfro:
Hast Du das "continue" rausgemacht?

Count:

--- Zitat von: mfro am Di 23.02.2021, 08:20:24 ---Hast Du das "continue" rausgemacht?

--- Ende Zitat ---
Nein, ich habe die Bedingung in (evnt_ret == MU_TIMER) geändert.

Count:
Ich habe jetzt mal in einer Header-Datei, die von jeder Quelldatei eingebunden wird, das wind_update()-Makro umgebogen. Meine eigenen Header-Dateien werden immer erst nach den System-Headerdateien eingebunden, also auch immer nach <gem.h>.

--- Code: ---#undef wind_update
#define wind_update(a) my_wind_update(a)
void my_wind_update(short);
--- Ende Code ---

Die Funktion sieht so aus:

--- Code: ---void my_wind_update(short a)
{
    static const char* what[] = { "END_UPDATE","BEG_UPDATE","END_MCTRL","BEG_MCTRL" };
    FILE*f=fopen("A.TXT","a");
    fprintf(f,"wind_update(%s)\n",what[a]);
    fclose(f);
#undef wind_update
#define wind_update(a) mt_wind_update(a,aes_global)
    wind_update(a);
}
--- Ende Code ---

Die Ausgabe in A.TXT zeigt keine Auffälligkeiten:

--- Code: ---wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
wind_update(BEG_UPDATE)
wind_update(BEG_MCTRL)
wind_update(END_MCTRL)
wind_update(END_UPDATE)
--- Ende Code ---

mfro:

--- Zitat von: Count am Di 23.02.2021, 08:44:56 ---
--- Zitat von: mfro am Di 23.02.2021, 08:20:24 ---Hast Du das "continue" rausgemacht?

--- Ende Zitat ---
Nein, ich habe die Bedingung in (evnt_ret == MU_TIMER) geändert.

--- Ende Zitat ---

Das ist dann zwar nicht die Ursache für dein Problem, aber trotzdem falsch. Das "continue" hat da nichts verloren, das "==" auch nicht.

Die AES führen bei evnt_multi() unterschiedliche Events, die "quasi-zeitgleich" auftreten, zusammen. Deine Event-Behandlung sollte also immer den Event (mit einer Abfrage auf das gesetzte Bit, also

--- Code: ---if (evnt & MU_....)

--- Ende Code ---
"rausfischen", den es bearbeiten möchte, aber weiterhin die Behandlung anderer Events *nicht* "abklemmen". Das "continue" macht aber genau das. Zusätzlich bearbeitest Du jetzt einen Timer-Event nur dann, wenn er alleine auftritt.

Mehr kann man erst sagen, wenn Du deinen angepassten Code noch mal zeigst.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete