> What else is different about the way we do things? Nothing, just that. What I'm used to see is the Lua context is just one and the same in the entire time the application is running. To destroy the Lua context every time is just different for me, not a wrong way to do things.
> does IUP ever call PostQuitMessage? Yes, it does. IupExitLoop does call it. But since IupMainLoop is running this should end the IUP loop, not yours. Although maybe there is a possibility there. Best, Scuri Em qua, 19 de jun de 2019 às 14:53, Simon Orde < [email protected]> escreveu: > Hi > > > > Thanks for the reply. > > > > >> First, what do you mean by Debug Mode? Are you debugging the Visual C++ > application or the Lua script? > > > > By ‘Debug Mode’ I mean that I am running my Visual C++ application under > the Visual C++ debugger. My application has its own editor/debugger for > running Lua scripts. If I run the iup dialog script from my previous post, > and I run the script in (Visual C++) debug mode, either using my app’s Lua > debugger or running it normally, it will close the application. However, > if I create a Release build of my application, the same script will not > close my application, whether I run it under the Lua debugger or not. > > > > >> Second, you have a very peculiar configuration as we speak previously > > > > I don’t know what the normal setup is. Our setup has worked well for us > up to now. When a user runs a script (either under the Lua debugger or > not), we call luaL_newstate() to create a new Lua state for that script. > To run the script, we call lua_load to load it, and lua_pcallk to execute > it. When lua_pcallk returns, we call lua_close to close the Lua state. > That’s pretty much what we’ve done for some considerable time now (albeit > with an older version of Lua and IUP) and it’s worked well with no > significant problems. > > > > We like this way of working. It means that different scripts can’t > accidentally or deliberately interfere with one another. It means that > every script executes in a clear, well-known environment. And there are > other benefits. > > > > What else is different about the way we do things? The most obvious is > that we use dynamic linking to load the Lua DLLs. We did that because it > seemed to keep lines of dependencies cleaner and more explicit. It has > worked fine for us up to now (some years now) with no problems – running > scripts of all types using multiple Lua modules apart from, or as well as, > IUP. > > > > One change was discussed in an earlier email on the Lua forum. Previously > we used to auto-open IUP within the C++ code, and then manually close IUP > at the end. On advice from you, we no longer do that. The user now has to > call “require( "iuplua" )” at the start of the script. The problem we then > had was that if an error occurred, and the script returned without closing > IUP, IUP windows would be left and the application would crash when you > closed lua. So we now we execute this string just before closing the Lua > state: “if iup and iup.Close then iup.Close() end*”. * That seems to work > well and solves most of our problems. > > > > I don’t think the way we close IUP and close a Lua state has anything to > do with the problem, because if I skip both (don’t close either of them) > the application still shuts down. > > > > I don’t know if it’s a clue, but 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. What happens is that my call > to lua_pcallk returns at that point – and with a 0 return code which seems > surprising. Given that it hadn’t finished executing all of the code, I > would have expected a non-zero return code. > > > > >> Can you send us the call stack at the crash > > > > I think I may have misled you by saying that the application crashes. > What actually happens is that the application closes. It actually closes > in a fairly orderly way. Mine is an MFC application, and the CWinApp’s > ExitInstance function is called which is what happens in a normal orderly > closedown. This suggests that the main message loop has received a WM_QUIT > message or something like that (does IUP ever call PostQuitMessage?). I > get some errors at this point – but they are my own program errors which > are produced because the code didn’t expect to have the application die so > suddenly like that. So there’s no useful information to be gleaned from > the call stack. It’s usually sitting just below the main message loop at > this point. > > > > Does any of that suggest anything? > > > > Simon > > > > > > > > *From:* Antonio Scuri [mailto:[email protected]] > *Sent:* 19 June 2019 11:52 AM > *To:* IUP discussion list. > *Subject:* Re: [Iup-users] IUP crash in Debug Mode > > > > Hi Simon, > > > > I can't see anything wrong with your script. > > > > First, what do you mean by Debug Mode? Are you debugging the Visual C++ > application or the Lua script? When not in debug mode it works? > > > > Second, you have a very peculiar configuration as we speak previously. > Maybe you will have to build IUP with debug information so we can see where > it is crashing. > > > > Can you send us the call stack at the crash (even using IUP without > debug info)? > > > > Best, > > Scuri > > > > > > > > Em ter, 18 de jun de 2019 às 13:53, Simon Orde < > [email protected]> escreveu: > > Hi – I’m using Lua 5.3 and IUP 3.26 to run embedded Lua scripts in my > Visual C++ 2017 application, and I’m having problems with IUP dialogs which > cause my application to crash – but only in debug mode. For example, the > following script will cause my application to crash if (and only if) you > click the OK button: > > > > require( "iuplua" ) > > > > btn = iup.button { name="ok", title="OK", > > action = function() > > return iup.CLOSE > > end > > } > > dlg = iup.dialog{btn; title="Test dialog"} > > dlg:show() > > iup.MainLoop() > > dlg:destroy() > > > > > > The crash actually occurs in the dlg:destroy() call. If I comment out > “return iup.CLOSE” it does not crash (and pressing OK doesn’t close the > dialog either ). If I close the dialog by clicking on the cross in the > top-right corner it does not crash. If I don’t comment out “return > iup.CLOSE” but instead comment out dlg:destroy() it will crash my > application when the script ends (but only if I’ve clicked the OK button). > > > > I know that iup.GetParams is implemented using an iup dialog, but that > seems to work fine for me. For example, this code does not crash even if I > click the OK button to close the dialog: > > > > require("iuplua") > > > > iTest = 1 > > > > iup.GetParam("Options", nil, "Test %i\n", iTest) > > > > > > Presumably iup.GetParam must be doing something very similar to what I’m > trying to do. But it is doing it in a way that does not crash my app. > Anyone got any thoughts on what’s going wrong? All help much appreciated. > > > > Simon > > > > _______________________________________________ > Iup-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/iup-users > > _______________________________________________ > Iup-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
