Hi, I just committed to the SVN a new global attribute called CUSTOMQUITMESSAGE. If set to Yes, the message processing it will use a custom quit message and it will not call PostQuitMessage.
Let me know if it works. Best, Scuri Em ter, 2 de jul de 2019 às 12:18, Simon Orde < simono...@family-historian.co.uk> escreveu: > Hi Scuri > > > > I do understand your caution about making a change – especially if no-one > else has reported the problem. Can I have another go at trying to change > your mind? There is an ambiguity here that I think may not be helping > things. > > > > In Windows, a thread can (optionally) have a message queue. They get one > if they do things that require a message queue. And in that case, a > message loop must be provided to process the messages in the queue. This > typically looks like this (in the page you sent a link to): > > > > // Start the message loop. > > > > while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) > > { > > if (bRet == -1) > > { > > // handle the error and possibly exit > > } > > else > > { > > TranslateMessage(&msg); > > DispatchMessage(&msg); > > } > > } > > > > Notice that in the comment they call it “the” message loop. From what > you’re saying, it sound like you’re thinking of the winLoopProcessMessage > function in the file iupwin_loop.c as the thread’s message loop. And > it’s true that it is *a* message loop. But it isn’t the thread’s main > message loop. It is IUP’s own message loop – a secondary message loop that > is nested within the main application message loop. At least it is in any > application, such as mine, which has other non-IUP windows in addition to > the IUP windows. My application is an MFC application. In an MFC > application, the main message loop is within MFC code at the highest > level. When the documentation (in the link you posted) talks about how > “the thread’s message loop terminates” (on receipt of a WM_QUIT message), > they’re talking as if the thread only has one message loop. Which is the > most normal thing. The point is, you don’t call a PostQuitMessage to get a > secondary message loop to exit. Or not unless you want the whole thread, > with all windows attached to it, to shut down. > > > > Incidentally, there’s nothing wrong with secondary message loops. We use > them too in a few places in the application. But one shouldn’t treat them > as if they were thread’s main message loop. > > > > I suppose it is possible that some applications might use IUP for all > their windowing requirements and have no non-IUP windows. Is that possible? > If so, I suppose it’s possible that winLoopProcessMessage might actually > function as the thread’s main message loop. So here’s another suggestion: > provide a mechanism whereby an IUP client can set a flag within IUP to > indicate whether it wants IUP to shut everything down on exit. That flag > could be enabled by default, so existing implementations will notice no > difference in behaviour. But an application like mine could set this off > at the outset. If the flag was disabled, IUP would behave as I proposed in > my last email, and use a registered windows message to exit its loop. If > the flag was enabled, it would behave as now and use PostQuitMessage. > > > > This would not only solve my problem, but also safely future-proof IUP > over the issue going forward. What do you think? > > > > Simon > > > > > > *From:* Antonio Scuri [mailto:antonio.sc...@gmail.com] > *Sent:* 02 July 2019 1:15 PM > *To:* IUP discussion list. > *Subject:* Re: [Iup-users] FW: IUP crash in Debug Mode > > > > Hi, > > > > If you take a look at: > > > Using Messages and Message Queues > > https://docs.microsoft.com/en-us/windows/desktop/winmsg/using-messages-and-message-queues > <https://docs.microsoft.com/en-us/windows/desktop/winmsg/using-messages-and-message-queues> > > > > The thread nomenclature may lead to another understanding, but you will > see that to use PostQuitMessage is the regular way of doing it. > > > > I don't think is a good idea to change that in IUP. I have no idea of > the consequences for other applications where everything is working. Until > today only your case has been reported. For now you can do it in your own > distribution, maybe in the future we can change that. > > > > Best, > > Scuri > > > > > > > > Em qui, 27 de jun de 2019 às 09:15, Antonio Scuri <antonio.sc...@gmail.com> > escreveu: > > Hi, > > > > I'm in the middle of several tasks here. I'll get back to this soon. > Thanks for sending the suggestion. > > > > Best, > > Scuri > > > > > > Em qui, 27 de jun de 2019 às 09:12, Simon Orde < > simono...@family-historian.co.uk> escreveu: > > I downloaded the source code for IUP 3.26 and 3.27 from SourceForge to see > if I could work out what was going wrong. I haven’t been able to work out > why sometimes IUP scripts cause the application to close – even, in some > cases, if it’s not running under a Lua debugger. But I have spotted some > behaviour that looks clearly wrong to me, which I believe can be easily > fixed, and which if fixed should solve the problem. In both 3.2.6 and > 3.2.7 there is one and only call to PostQuitMessage and only one place > where the WM_QUIT message is mentioned (and for that matter, only one place > where ‘GetMessage’ is called), and it’s in the file iupwin_loop.c. The > 3.2.6 and 3.2.7 versions of this file are identical. > > > > I believe that the following 3 small changes would fix the problem: > > > > (1) Insert this line to the top of iupwin_loop.c (at say line 26): “static > UINT win_quit_msg_id = 0;” > > (2) The IupExitLoop function currently looks like this: > > > > void IupExitLoop(void) > > { > > char* exit_loop = IupGetGlobal("EXITLOOP"); > > if (win_main_loop > 1 || !exit_loop || iupStrBoolean(exit_loop)) > > PostQuitMessage(0); > > } > > > > … and should be changed to this: > > > > void IupExitLoop(void) > > { > > if (win_quit_msg_id == 0) > > win_quit_msg_id = ::RegisterWindowMessage("IUP Quit Message"); > > > > char* exit_loop = IupGetGlobal("EXITLOOP"); > > if (win_main_loop > 1 || !exit_loop || iupStrBoolean(exit_loop)) > > PostMessage(NULL, win_quit_msg_id, 0, 0L); > > } > > > > > > (3) The winLoopProcessMessage function currently looks like this: > > > > static int winLoopProcessMessage(MSG* msg) > > { > > if (msg->message == WM_QUIT) /* IUP_CLOSE returned in a callback or > IupHide in a popup dialog or all dialogs closed */ > > return IUP_CLOSE; > > else > > { > > TranslateMessage(msg); > > DispatchMessage(msg); > > return IUP_DEFAULT; > > } > > } > > > > … and should be changed to this: > > > > static int winLoopProcessMessage(MSG* msg) > > { > > if (win_quit_msg_id == 0) > > { > > win_quit_msg_id = ::RegisterWindowMessage("IUP Quit Message"); > > if (win_quit_msg_id == 0) > > return IUP_CLOSE; > > } > > > > if (msg->message == win_quit_msg_id) /* IUP_CLOSE returned in a > callback or IupHide in a popup dialog or all dialogs closed */ > > return IUP_CLOSE; > > else > > { > > TranslateMessage(msg); > > DispatchMessage(msg); > > return IUP_DEFAULT; > > } > > } > > > > > > That’s it – except that there are a couple of comments in the same file /* > WM_QUIT */ that can simply be removed. The code in each case is fine as it > is and does not need to be changed. Probably you should define “IUP Quit > Message” (or whatever your preferred string is) as a constant string at the > top of the file, for greater robustness. > > > > Theoretically you could use WM_USER + ? as the message id, but it’s more > robust to use a registered message. That way you can be 100% sure that > there won’t be a conflict with any application-defined messages, which > there could be if you took the WM_USER approach. > > > > The Windows documentation says that the PostQuitMessage function > “Indicates to the system that a thread has made a request to terminate > (quit)”. That is clearly not the case here, so PostQuitMessage should not > be used. > > > > Any thoughts anyone? Scuri? > > > > Simon > > > > > > > *From:* Antonio Scuri [mailto:antonio.sc...@gmail.com] > *Sent:* 24 June 2019 6:27 PM > *To:* IUP discussion list. > *Subject:* Re: [Iup-users] FW: IUP crash in Debug Mode > > > > > Is there any way I can stop it doing that? > > > > No > > > > > Has IUP always posted WM_QUIT messages? > > > > I think Yes > > > > > I wasn’t clear from your reply what you think needs to be done. > > > > Actually neither I... > > > > > From my point-of-view, I don’t want IUP to ever close down my > application in any circumstances. > > > > Yes, it wasn't meant to do that. When you are showing an IUP dialog the > iup.MainLoop will hold the execution until a WM_QUIT message is posted. The > same happens when iup.Popup is called, but in this case there is a > secondary message loop, when the quit message is posted it returns to the > mainloop. The idea, and it works when not debugging, is that IUP receive > the quit message, and returns the control to the application just like a > secondary message loop. > > > > The problem is that your application loop is intercepting our quit > message in debug, apparently because of the message pump process. Notice > that IUP has its own way to message pump by using IupLoopStep. We use that > to implement the Lua debugger in the IupLuaScripterDlg predefined dialog. > > > > To be more specific and not being, I think something in the message pump > should be changed, but I'm not sure what. > > > > Best, > > Scuri > > > > > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users