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
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
