|
|
Oct 21, 2012 at 3:01pm
Timing bug???
Hello
In the below patch the getpenloc message looks to be delayed, if you look at max window you see that penloc messages arrive after write messages…
is it a bug or is it normal?
PB
|
|
|
Oct 21, 2012 at 3:16pm
Hi,
IMHO the scenario is :
- write A,
- append penloc attribute to the outlet queue and schedule the dumpout,
- write B,
- cancel the dumpout, append penloc attribute, schedule it again,
- write C,
- cancel the dumpout, append penloc attribute, schedule it again,
- dumpout.
AFAIK, it seems to be implemented with a Qelem task.
|
|
|
Oct 21, 2012 at 3:20pm
requesting the mouseposition from the dropfile object is simply kicked out of the
main thread, the left to right order order of your two messages stops beeing
valid when the penloc message arrives inside the GUI object.
the mouseposition is only tracked every 20 ms (or 50, i can never remember)
and so it would be asked too much to wait for it.
to get back to the desired order just store “write $1″in a buffer (for example
[zl reg] or [list x x]) and fetch it there when the mouse location later is beeing
reported from the GUI object´s output.
of course with “write A, write Z, write E” you will run into trouble.
you´d have to build a shift register to be able to store and fetch those safely.
but i beleive that your application approach will allow you to store multiple
keyboard inputs in another form than as consecutive messages.
-110
|
|
|
Oct 22, 2012 at 7:57am
Hello
thanks a lot for your answers,it helps me a lot!
Pierre
|
