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

Reply via email to