Did you try the script in my last message? Because that also causes our application to close, and in that case it happens even if (in fact only if) the script is not run under the lua debugger. When the script exits, the ‘ExitInstance’ method of our application object is called which suggests that the main application message loop (the one inside the MFC) has received a WM_QUIT message. Do you have any suggestions about that one because we really need to be able to use the IUP progress dialog, so it’s a big concern for us (actually both problems are a big concern for us).
Here is a suggestion: IUP could call RegisterWindowMessage to define your own version of a ‘quit’ message that would have meaning only to IUP. When that message was received, by the iup.MainLoop, it would exit the loop. There would be no chance that this message would be acted on by anything else. 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 Em seg, 24 de jun de 2019 às 13:23, Simon Orde <simono...@family-historian.co.uk> escreveu: 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
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
