OK, cancel ... well, cancel something.  I found a stupid error in my Windows version of "glutMainLoop" in which I was checking for all windows being closed only if we had been through an idle cycle.  So naturally we had a call to the idle callback after the last window was closed and before we exited.

Steve is absolutely right, we don't have to generate any more callbacks once the last window is closed.  And so we can have control return to our "glutMainLoop" function, drop out of the loop, clean up GLUT's mess (which has some problems of its own still), and then exit.

Incidentally, my previous remark about being ignorant was not meant sarcastically; after reading it from my in-box I realized that it did not sound anywhere near as light-hearted as I had meant it.  I apologize if I have stepped on anybody's toes.

John F. Fay

-----Original Message-----
From: Stephen J Baker [mailto:sjbaker@link.com]
Sent: Tuesday, October 29, 2002 3:20 PM
To: freeglut-developer@lists.sourceforge.net
Subject: Re: [Freeglut-developer] RE: Window Destruction Callback

On Tue, 29 Oct 2002, Chris Purnell wrote:

> On Tue, Oct 29, 2002 at 10:08:00AM -0600, Fay John F Contr AAC/WMG wrote:
> > Since GLUT exits immediately, there are no more callbacks generated when the
> > user clicks on the "x".  If we drop out of the freeglut main loop and then
> > exit, then the idle callback may easily get called again.

Not if we prevent that.  If freeglut has decided that it's going to
return from main-loop because all the windows are closed then it
shouldn't call anymore user callbacks on the way out.

> > I was checking this out with a three-window application and it keeps
> > crashing.)  Without the application defining a window destroy callback,
> > there is no way for the application to find out that the window has been
> > closed.  So when it tries to render the window in its idle callback, we get
> > a "window ID %d not found!" warning from freeglut, followed by a program
> > crash when I call "glutSwapBuffers".
> >
> > So now it's time for a design decision.  Shall we:
> >
> > (1) make the default behaviour absolutely compatible with GLUT and exit
> > immediately, or

That seems the simplest thing - the least likely to break existing apps.

> > (2) make the default behaviour clean up after itself and possible break some
> > GLUT applications?

I don't see a problem with returning from main-loop without calling any
more callbacks along the way.  Once you've made the decision to return,
there needn't be any other actions taken.

> Rendering to the window in the idle callback is bad practive but people do
> it.

Yes - they do.    :-(

I never understood why though.

> Which is why glut exits immediatly on a window close button event.
> The only other behaviour that does not break stuff is to leave the window
> open.


Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker@link.com           http://www.link.com
Home: sjbaker1@airmail.net       http://www.sjbaker.org

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
Freeglut-developer mailing list