   MFC message loop
  HeyI am rather new to MFC and therefore have a little question.I am doing a small game where all you have to do more or less is click some buttons!! (sounds really cool eh?? :-) )In this little game I need to continuously check whether some variables have been set and I have therefore implemented my own message loop (as it was described in another thread in this forum). This also seems to work just fine, but my problem is, that all the variables that I need to check are in my CSampleDlg class and my message loop are in the CSampleApp class. I therefore need some connection between those two, but the only place that I can find this connection is in the InitInstance method in the CSampleApp class.CSampleDlg dlg;m_pMainWnd = &dlgHowever this dlg variable gets destroyed I suppose when the InitInstance method is exited, and therefore all there is left is the m_pMainWnd. Am I suppose to use this m_pMainWnd to get to the variables in my CSampleDlg class (and if so how ?? ) or is there some other way??(I guess my problem is that I do not fully understand the structure of a MFC application...sry..)TX AW   
  Inside MFC you should not create a message loop, as this is unnecessary. You could use the OnIdle message handler of the application for this. In this handler you can call some function in of the dialog to check those variables.   ;  In addition to jeroenb's comment on using OnIdle, you have some fundamental design flaws.The instantiation of your CSampleDlg class within the InitInstance member function of CSampleApp suggests that CSampleDlg is invoked as a modal dialog (check for dlg.DoModal();), meaning that it remains on top of its parent window until it is dismissed by clicking on "OK", "Cancel" or other equivalents. The implication of this, however, is that your regular application (CSampleApp) events will not have a chance to fire until the CSampleDlg instance exits.To solve this, move the variable checking logic into the CSampleDlg class, using its OnIdle handler. In addition, provide accessors to query the state of the variables. Then, after DoModal returns, have the CSampleApp instance call the aforementioned accessors to retrieve their value as at the end of DoModal.Utilizing this approach also means that you don't have to take the nonstandard approach of making an instance of CSampleDlg a member of CSampleApp.   ;  Hi both.Tx for the fast reply.However I am not sure I fully understand your replies, so just to be sure I will just describe my problem again.I have only two classes CSampleApp and CSampleDlg In CSampleDlg I have the variables I need to check constinuously.That is all.<Inside MFC you should not create a message loop, as this is unnecessary. You <could use the OnIdle message handler of the application for this.All I did in the first place was to let my CSampleApp class overwrite the Run and OnIdle methods and then use these overwritten methods as my gameloop. Is that what you mean?<To solve this, move the variable checking logic into the CSampleDlg class, <using its OnIdle handler.Hm. The variables checking logic is already in the CSampleDlg class. They are the ones I need access to.And the CSampleDlg class does not have an OnIdle method does it??<Utilizing this approach also means that you don't have to take the nonstandard <approach of making an instance of CSampleDlg a member of CSampleApp.The code:CSampleDlg dlg;m_pMainWnd = &dlgin the InitInstance method in the CSampleApp class was made by visual? But is this a wrong way to do it??It's probably just me who's way of track, but again1: Where should the "message loop" be(my OnIdle and Run method is in CSampleApp)?2: How can I access the CSampleDlg class from this methodloop(run and onidle)?Tx againAnders   ;  Since you have a dialog based MFC app your OnIdle and Run of the App will never be called!As the default MFC dialog doesn't get the OnIdle handler you can resort to a much simpler approach: Set a timer in the dialog and check your variables in the OnTimer handler.Either way, OnTimer or OnIdle will not be in fixed time slices but if a few ms difference aren't a problem it's the easiest way to go.   ;  LOL:-)I am already using timers in the application...wonder why I didnt think if thattx again.