gnash-commit
[Top][All Lists]
Advanced

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

Re: [Gnash-commit] gnash ChangeLog server/character.h server/gnash...


From: strk
Subject: Re: [Gnash-commit] gnash ChangeLog server/character.h server/gnash...
Date: Wed, 21 May 2008 16:41:25 +0200

On Wed, May 21, 2008 at 04:32:03PM +0200, Benjamin Wolsey wrote:
> 
> Am Mittwoch, den 21.05.2008, 16:01 +0200 schrieb strk:
> > On Wed, May 21, 2008 at 03:53:42PM +0200, Benjamin Wolsey wrote:
> > > 
> > > Am Mittwoch, den 21.05.2008, 15:30 +0200 schrieb strk:
> > > > On Wed, May 21, 2008 at 01:24:07PM +0000, Benjamin Wolsey wrote:
> > > > 
> > > > >       It seems that it might be possible for FsCommands to be called 
> > > > > before
> > > > >       the VM is initialized, and this change means they'll be 
> > > > > ignored. It 
> > > > >       appears not (and really ought not) to make a difference (at 
> > > > > least for
> > > > >       the testsuite and my own tests).
> > > > 
> > > > How does it seem then ? How did you find out ?
> > > > 
> > > It seems that it can happen when some idiot forgets to register
> > > fs_callback in Player.cpp after making those changes.
> > 
> > These are the cases in which an abort() is better then
> > an 'if (shitHappened) ignore();'
> 
> Except that in this case it's quite legitimate to have a user interface
> not registering a callback if it doesn't want it. A (single) warning
> message might be a better option.

I'm talking about 'fsCommand sent && VM::isInitialized()'.
Dunno if the fscommand interface allows that (intercepting the
request reguardless of an handler being registered or not), but
it likely should.

--strk;




reply via email to

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