From: John L. <jla...@gm...> - 2006-01-09 15:28:01
|
On 1/8/06, Chris Marrin <ch...@ma...> wrote: > > A while ago, John and I discussed the changes I made to the older > version of wxLua I was using. My big issue was being able to run the > wxApp event loop in a separate thread from Emma. Because of this I could > not call Lua functions that had been connected because they would run in > the wrong thread. So I came up with a native callback mechanism. This > basically used the same Connect() model that wxLua uses, but it uses a > form that registers a C++ callback rather than a Lua function. wxLua > would call this callback and my native function would send a message to > the thread running the Lua interpreter to execute the Lua function. > > All this inter-thread comm is done in my app, so all wxLua needs is the > ability to register native callbacks. I discussed adding this to this > latest incarnation of wxLua with John. It does not look like that was > ever added. I think, if I understand correctly, that the same can be implemented by just making the wxLuaCallback::CallFunction virtual (modules/wxlua/include/wxlcallb.h). In your program you will have your own ConnectEvent function, similar to the one you added in wxLuaInternals.cpp, but instead you'll create a new wxMyLuaCallback class with CallFunction overridden to do as you please. Does this sound like it'll work? There's nothing wrong with your method, but I think just making wxLuaCallback::CallFunction virtual is a little cleaner and simpler, but maybe it's not workable for you? > John, any resolution on adding this? If there is still interest, I will > switch over to your version of wxLua, make my changes there and make > them available to you. My goal, of course, is to use a stock version of > wxLua! I hope I can help and we can get this to work. I'll have some time tonight to fix the linking problem that Klaas was having. Regards, John Labenski |