denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Denemo-devel] d-AttachQuitCallback and friends


From: Richard Shann
Subject: [Denemo-devel] d-AttachQuitCallback and friends
Date: Mon, 19 Oct 2009 15:56:57 +0100

I have checked in a new implementation for d-AttachQuitCallback. Now the
script you give to this command is the only thing that is executed when
the user does a close on the score you have open when you attach the
callback. And, as before, the callback is a once only, so if you want it
to stick around you must call d-AttachQuitCallback during the callback.

That it is the only thing done means that if you want the user to be
able to close the score you must include (d-Close) as the last thing in
the script. An example:


(d-AttachQuitCallback "(d-WarningDialog \"Quitting the Game\")(d-Quit))")

I notice I have put d-Quit here, I am not sure what the difference is
between that and d-Close...

Now, the new implementation arose through thinking about the general
subject of running denemo under the influence of scripts. The other
examples we have are d-OneShotTimer d-GetMidi and d-GetKeypress (or
Command etc). These all hand control back to the user and so their use
becomes problematic if the user does something unexpected.

Consider for example a timer which is going to fire off and write a
chord into the score: what if the user has lost interest and just opened
their masterpiece in progress? The timer fires off and a chord gets
inserted into their masterpiece. They are not best pleased.
The same applies to the other examples.

In the current implementation, if the user uses Open or (OpenRecent,
Example, Template) it replaces the music in the current score, which
means that quit callbacks, timers and keyboard/midi gets all affect the
newly opened score. If the user opens in a new tab then the quit
callback will *not* affect the new score, but, at the moment the others
will. It is conceivable that one might wish them to, but in general it
seems a bad idea.

So I plan to make timers fail to do anything if the score is not the one
on which the timer was issued, and likewise keyboard and MIDI inputs.
In the case of the keyboard and MIDI inputs, I expect you to be able to
switch back to the score that issued the request and the next keypress
there will be received by the script. I am not sure what I may be able
to do with missed timers if you switch back to the issuing score.

Richard






reply via email to

[Prev in Thread] Current Thread [Next in Thread]