Hi Scuri – I wasn’t clear from your reply what you think needs to be done.
From my point-of-view, I don’t want IUP to ever close down my application in
any circumstances. So I don’t want it to ever post any WM_QUIT message (or
call PostQuitMessage). Is there any way I can stop it doing that? I can’t see
that there is anything wrong with my debugger’s message pump. And if I don’t
crank the message pump, the debugger won’t work. I tried just ignoring the
case when PumpMessage returns false, but that didn’t solve the problem.
I have a similar problem with progress bars. I enclose an example below.
Unlike my previous example, if I run this script normally, the application
closes down when it ends (having I think received a WM_QUIT message because the
app’s ExitInstance method gets called at the end). For some reason, if I run
it under the Lua debugger, the application does not close down. It’s hard to
know what is going on, because if I run it under both the Lua debugger and the
Visual C++ debugger I get ASSERTs in the MFC which prevent further processing
(“mfc140ud.dll!02ed5d93()” - and no usable stack info between that and WinMain).
Has IUP always posted WM_QUIT messages? We are now running IUP 3.26 and Lua
5.3 having upgraded from IUP 3.11.2 and Lua 5.1. We did not used to have this
problem before we upgraded.
Simon
The following script crashes the application when run normally
require "iuplua"
local cancelflag
local gaugeProgress
local function StartProgressBar()
cancelbutton = iup.button {
title = "Cancel",
action=function()
cancelflag = true
return iup.CLOSE
end
}
gaugeProgress = iup.progressbar{ expand="HORIZONTAL" }
dlgProgress = iup.dialog{
title = "Note Replacement in Progress",
dialogframe = "YES", border = "YES",
iup.vbox {
gaugeProgress,
cancelbutton,
}
}
dlgProgress.size = "QUARTERxEIGHTH"
dlgProgress.menubox = "NO" -- Remove Windows close button and menu.
dlgProgress.close_cb = cancelbutton.action
dlgProgress:showxy(iup.CENTER, iup.CENTER) -- Put up Progress Display
return dlgProgress
end
dlg = StartProgressBar()
gaugeProgress.value = 0.0
for i=0,10000 do
-- take one step in a long calculation
-- update progress in some meaningful way
gaugeProgress.value = i / 10000
-- allow the dialog to process any messages
iup.LoopStep()
-- notice the user wanting to cancel and do something meaningful
if cancelflag then break end
end
dlgProgress:destroy()
-- distinguish canceled from finished by inspecting the flag
print("cancled:",cancelflag)
From: Antonio Scuri [mailto:antonio.sc...@gmail.com]
Sent: 20 June 2019 1:20 PM
To: IUP discussion list.
Subject: Re: [Iup-users] FW: IUP crash in Debug Mode
I think the problem is really the WM_QUIT processing.
When the message is processed it is removed from the queue so it is not
processed again. Popup dialogs in IUP has a secondary message loop. That's why
iup.GetParam and iup.Alarm work ok.
The problem is not at your script. The problem seems to be with message
processing.
WM_QUIT is posted at the button click when iup.CLOSE is returned or
IupExitLoop is explicitly called. Clicking in the X (the close button of the
dialog) does not generates a WM_QUIT message because it only hides the dialog.
Since it is the last IUP visible dialog, it will end the message loop in a
complete different way.
Since the iup.MainLoop is run after your application message loop it
shouldn't be a problem because it will work as a secondary loop for the
application and it will catch WM_QUIT messages posted by IUP.
But If I understood it right, I think CMyApp::PumpMessage is processing
WM_QUIT messages posted by IUP.
Best,
Scuri
Em qui, 20 de jun de 2019 às 08:04, Simon Orde
<simono...@family-historian.co.uk> escreveu:
I did the test. I changed the OK ‘button’ to a ‘flatbutton’. I also had to
change “action” to “flat_action”. It didn’t make any difference. The
application appeared to have received a WM_QUIT message when you click the OK
button, exactly as before.
Couple more things: I wondered if setting the NATIVEPARENT window handle of the
dialog would make a difference. I was able to get that to work using
“iup.SetAttribute(dlg, "NATIVEPARENT", hWnd)”, but it didn’t make any
difference to the problem.
I said in an earlier email that code following dlg:destroy never gets called if
you click the OK button. I now think that that’s wrong. I think the code does
get called, but it’s hard to tell and hard to test because the application is
dying fast (as the WM_QUIT message has already been posted). So the fact that
the lua_pcallk command rets 0 (no error) is probably of no significance.
For interest, if I run the script under a debugger, I have to crank the message
pump myself, so I call CMyApp::PumpMessage at various points so that the
editor/debugger gets a chance to process messages. The code tests to see if
CMyApp::PumpMessage returns false. It should only do this if a WM_QUIT message
has been received. And if you click the OK button, CMyApp::PumpMessage does
indeed return false, seemingly during the call to dlg:destroy (i.e. before the
next script line has been processed, as far as I can see).
If I don’t run the script under the debugger, I don’t crank the message pump.
Instead there’s a message loop in the bowels of the MFC. But that calls
CWinApp::ExitInstance if the PumpMessage call returns false. I can put a
breakpoint in my applications ExitInstance method call and this seemingly gets
called exactly when you would expect – i.e. in the same circumstances that
CMyApp::PumpMessage in the editor’s message crank would return false.
In my view, the big clue is that iup.GetParam and iup.Alarm both work fine
with no problems. What is it that they are doing which is different to what my
script is doing?
Simon
From: Antonio Scuri [mailto:antonio.sc...@gmail.com]
Sent: 19 June 2019 8:33 PM
To: IUP discussion list.
Subject: Re: [Iup-users] FW: IUP crash in Debug Mode
Ok.
Can you make a simple test? To replace IupButton by IupFlatButton and check
if there is any difference?
Best,
Scuri
Em qua, 19 de jun de 2019 às 15:05, Simon Orde
<simono...@family-historian.co.uk> escreveu:
… sorry – yet more clarification.
When I said “if I modify the script to add something (a message box) say, after
the call to “dlg:destroy()”, the message box code never gets called if I call
dlg:destroy.”
Again – what I meant is that if you click on the ‘OK’ button in the dialog, the
script exits at the call to dlg:destroy(). But it doesn’t exit there if I
closed the dialog by clicking on the ‘X’ in the dialog’s top-right corner. In
that case, the script continues to execute after the call to dlg:destroy() and
the message box is displayed.
Simon
From: Simon Orde [mailto:simono...@family-historian.co.uk]
Sent: 19 June 2019 6:57 PM
To: 'IUP discussion list.'
Subject: RE: [Iup-users] IUP crash in Debug Mode
To be precise, when I said “If I run the iup dialog script from my previous
post… in (Visual C++) debug mode … it will close the application”, I meant: “…
it will close the application if you click on the OK button in the dialog”. It
will not close the application if you click on the ‘X’ in the dialog’s
top-right corner. Just wanted to be 100% clear about that.
Simon
_______________________________________________
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
