John Labenski a écrit : > > On Sun, May 17, 2009 at 4:04 PM, John Labenski <jlaben...@gmail.com > <mailto:jlaben...@gmail.com>> wrote: > > On Sun, May 17, 2009 at 2:47 PM, TOUPIN Youen > <youen.tou...@wanadoo.fr <mailto:youen.tou...@wanadoo.fr>> wrote: > > It seems the problem comes from the Connect function call, > which uses > the current lua state to register the event callback. When the > callback > is called, it is from that lua state, which, in my case, is the > coroutine, not the main lua thread. Is there any reason for this > behavior ? Wouldn't it be better to get the main lua thread (I > think it > can be retrieved from the coroutine) when the Connect function is > called, and use it instead of the coroutine ? > > > I don't think your example makes sense. You create a coroutine > that creates a wxDialog then yield it and try to resume it from > the yielded coroutine. Shouldn't the wxDialog be created in the > main thread which can control the coroutine as appropriate? > > > I should clarify, in Lua there is no way for a coroutine's code to be > run when it's yielded, unless I'm missing something. You, with the > wxWidget's event loop can "cheat", so to say, and pop back into the > yielded coroutine to run code which would not normally be possible. > > I think it's a reasonable constraint that a coroutine cannot resume > itself since 1) it stays truer to Lua's behavior, 2) doesn't require > second guessing the user by swapping back to the main thread, which > would be unexpected to say the least, 3) the fix is simple, put any > code that will control a coroutine into the parent thread that created > the coroutine where it belongs. > > Regards, > John Thanks for the quick answer.
I know it doesn't make sense to resume a coroutine from itself (didn't even know it was possible to execute something from a yielded coroutine), that's not what I'm trying to do. What I was trying to do is to create the dialog from the coroutine, then yield, and when a button is pressed, it executes some code from the main thread, that resumes the coroutine. This would allow for example to create code like answer = promptUser( "Some question" ) The promptUser function creates the dialog, registers a callback on a button click event, then yield (so it must be called from a coroutine). When the button is clicked, it resumes the promptUser function, which gets the answer from a text control, destroys the dialog box, and returns the result. The only problem is that, in the current implementation, I need to call the Connect function from the main thread to register my callback, so I can't write such a promptUser function that contains everything to create the dialog, I will have to create the dialog from the main thread, and promptUser will simply show/hide it when needed. This does not allow to call multiple promptUser in parallel, for example. And if my dialog is complicated and needs to be created differently depending on promptUser parameters, it will become more complicated to implement. More generally, it creates a dependency between my promptUser function, and some initialization code that need to be executed from the main thread. Maybe the good solution for this problem would be to have the possibility to decide from which thread the function must be called, when it is registered on the button click event (with an extra parameter of the Connect function for example). It would give more possibilities to the user, while staying simple (no obligation to provide the additional parameter) and backward compatible (the default behavior would be to call the function from the thread that registered it). There is another problem, however : I don't know if it is a good idea to create a dialog at the moment it is needed. I'm not used enough to wxWidgets to know if it can introduce some uncomfortable lag in the application. Regards, Youen. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
