On Jul 28, 2005, at 4:53 AM, Alex Tweedly wrote:
Thomas McGrath III wrote:
Pardon me chiming in here.
When using things like players and speech etc. it is our
responsibility to close them ourselves in our code when and if for
any reason our program is to quit. So I would put a piece of
script in a on closeStack that takes care of the player when closing.
Quite right - except that the context here is that the "Player"
that Charles was referring to is the Dreamcard Player, which he's
using to run the stacks.
This is because players and speech use libraries and/or QT etc. to
work and like a serial port that is opened it must be closed or
problems may occur. This is good coding practice.
Maybe you can have in each stack an on closeStack that checks if
all three (+-) stacks are closed and 'then' closes the player only
if all are closed.
We do indeed need to do that with audio, video etc. players - but I
don't think it's possible for a stack to close the DC Player in a
controlled way, and arguably it shouldn't need to.
If you double-click a stack icon to run it, when the stack closes
'it' should disappear completely (i.e. taking the player away with
it). Otherwise, there's no way to provide a transparent experience
for the user - she shouldn't need to know whether the software I've
distributed to her is an application in its own right, or uses some
player mechanism to run.
Thanks to both. It's true that I forgot the possibility that my user
will close stack-windows _without_ pressing my nice new Quit button.
I should trap onClose messages in some logical order which will
depend on the design of my app.
Charles
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
