I think I understand now. Your mainloop doesn't end until (mainWindow.Created) is false. But your DoEvents is not running on the message-loop thread so the WM_CLOSE message never gets processed and you run forever. I guess this confirms that DoEvents must be run on the UI thread.
What I don't understand is why you wanted to use another thread in the first place. Are you saying that even when your main loop and Application.Run is all on the same thread that you still get the no-close problem? Gary Leighton -----Original Message----- From: Ben Kloosterman [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 05:43 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Controls / DirectX and threading Yeah I know its dodgy , which is why im posting it here trying to find an alternative ( one of the threads lock when a resize happens and stops rendering) . I had a read of the Close bug and it is not the same thing as I am not removing anything though it may relate. The problem I have is I cant stop the animation ( or do anything) as I dont even get the close event. If i got the event I could destroy everything. I have read some C++ posts saying DirectX can interfere with WM_Close events and I think something like that is going on. Anyone have any bright ideas ? Ben > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED]]On Behalf Of Gary Leighton > Sent: Monday, 20 January 2003 11:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Controls / DirectX and threading > > > Application.Run creates a message-loop on the current thread. > > I would be suprised if DoEvents will work on the non-UI thread, > but I'm not > sure about this. > > DirectX can have problems with multi-threading when operating full-screen, > but I'm not aware of any problems when working in a window. > > My guess is that the Close window problem is not related to threads. There > is a documented error to do with forms not closing when a child > control that > has focus is removed. Could this be the problem? > > Gary Leighton > > -----Original Message----- > From: Ben Kloosterman [mailto:[EMAIL PROTECTED]] > Sent: 18 January 2003 06:24 > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Controls / DirectX and threading > > > Ok I had a problem when using DirectX 9 to render to a control > that the form > ( actually a subform created from the mainform) would no longer > handle close > events, all other events were handled properly . Looking at all > the managed > DirectX samples they started the rendering loop from main() which > I suspect > is a different thread then the UI thread created by Application.Run , this > is not really practical as the program I want to write is 90% forms. as a > workaround solution starting the rendering as a new thread seemed to work > fine. > > My question is whether this is save as the Rendering and > Application.DoEvents is done on a different thread from the UI. More > specifically does DirectX interfere with the UI thread and does > Application.DoEvents invoke the UI thread. > > Ben Kloosterman > > PS; code is below > > public virtual void Run() > { > try > { > if ( Init != null) > Init(this , new EventArgs()); > MethodInvoker mi = new MethodInvoker(mainloop); > mi.BeginInvoke(null , null ); > } > // catch > } > > private void mainloop() > { > System.Windows.Forms.Control mainWindow = this; > mainWindow.Show(); > while (mainWindow.Created) > { > Application.DoEvents(); > // TODO Get the app's time, in seconds. Skip rendering if no > time elapsed > if (Idle != null) > Idle(this , new EventArgs()); > Application.DoEvents(); > } // while > } > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > > KSS Ltd > A division of Knowledge Support Systems Group plc > Seventh Floor St James's Buildings 79 Oxford Street Manchester > M1 6SS England > Company Registration Number 2800886 (Limited) 3449594 (plc) > Tel: +44 (0) 161 228 0040 Fax: +44 (0) 161 236 6305 > mailto:[EMAIL PROTECTED] http://www.kssg.com > > > The information in this Internet email is confidential and may be > legally privileged. It is intended solely for the addressee(s). > Access to this Internet email by anyone else is unauthorised. > > If you are not the intended recipient, any disclosure, copying, > distribution or any action taken or omitted to be taken in > reliance on it, is prohibited and may be unlawful. When addressed > to our clients any opinions or advice contained in this Internet > email are subject to the terms and conditions expressed in the > governing engagement letter or contract. > > This email message and any attached files have been scanned for > the presence of computer viruses. However you are advised that > you open any attachments at your own risk. > > > You can read messages from the Advanced DOTNET archive, > unsubscribe from Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
