Re: [Plib-users] pui help

[Brian S. <sch...@ho...>]

>>Hmmm - what's unusual about this is switching all of those GLUT function
>>callbacks within a PUI callback which presumably is in turn inside one of
>>those very GLUT callbacks that you're changing.
>>
>>I've never tried to do that kind of thing.  I'd usually have just one GLUT
>>callback for each of those events - and use an 'if' statement at the start
>>of the callback to make it do nothing in 'back-button' mode.   That 
>>somehow
>>seems 'kinder' than switching the callbacks around all the time.
>>
>>So I wonder if this is some kind of a GLUT screwup.
>>
>>Have you tried building this application against 'freeglut' (and if you
>>have - have you tried building it against the classic 'GLUT')?  There are
>>several freeglut developers on this list - so it's not like I'm just 
>>trying
>>to punt the problem over to someone else!
>>
>>I'm thinking that if somehow the return stack was being corrupted - then
>>backButton->hide() would be the first thing to attempt to do a 'return',
>>so it would be the thing that would show up in the crash report even 
>>though
>>it is not the code with the bug in it.
>>
>>It's a long shot - but that's the only odd thing I can see from the
>>information you've given us.
>>
>>The actual hide function itself is *FAR* too simple to cause this problem
>>unless either the stack or the 'backButton' pointer is corrupted.
>>
>>You could discount the latter possibility by doing:
>>
>>   fprintf ( stderr, "backButton=%p\n", backButton ) ;
>>
>>...and sticking that in the line just below the 'new OneShot' - and again
>>just before the call to 'hide()'.  If the address changes then that's
>>what screwed up.  If it doesn't change then it's something else.
>>
>>However, this is very likely to be some kind of general memory screwup -
>>which means that the odds are high that this will eventually turn out to
>>be an application bug.
>>
>>>Unhandled exception in program.exe: 0xC0000005:  Access Violation.
>>
>>I don't know Windows/MSVC - but if that '0xC0000005' is a memory address
>>then it's a suspiciously round number...such as you might get in the
>>scenario I'm suggesting above where the return address has been screwed 
>>up.
>>
>>It's very hard to diagnose these things at long range.
>
>Steve,
>   I stuck in those printfs and the address did change, I'm looking through 
>my program again and can't seem to find why it is doing this.  Is it 
>because I am changing the GLUT callbacks inside a pui callback?  The reason 
>I have different callback function is mainly for organizational purposes, I 
>dont like functions that are thousands of lines long it looks messy.  As 
>for Bruce's comment the button is a global variable declared in a .h file 
>so that is not the problem (with VC++6 it wouldn't compile otherwise).
>

Another thing I just remembered is to get to the second display function I 
(simplified) click on the screen.  So I am changing all the glutCallbacks 
inside my glutMousefunc callback,  I'm not sure if that is what you meant by 
chaging the callbacks inside the pui callback which is inside a callback.  I 
actually change glutcallbacks within a glutcallback a lot throughout the 
program but no problems there

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/