Mac->Win revisited

[Charles Hartman]

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