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
