wxlua-users

[wxlua-users] I have some questions...

[Patrick E. <sha...@ho...>]

I am using a client to play MUDs which recently went withLua as its "main" 
scripting system. This works nicely, but has a fatal flaw imho, which is 
shared by all other script systems in this context. wxLua would correct this 
flaw, by adding the capacity to develop new GUI elements within the context 
of the client's own functions and windows. Right now, we have to do some 
screwy things, like creating a dummy window in the client, which cannot be 
undocked and dropped some place else, then using that to send output (with 
color), or using an internal notepad, which has the same issue. We can't add 
buttons, icons, graphical maps, etc., without implimenting them as ActiveX 
applications, to be instanced and loaded from in the script, and which must 
be specially linked to the client's own entry points to talk to it. The 
script system can call these entry points without the hassle, since they are 
automatically exposed to it *and*, more to the point, people don't need to 
learn C++, MFC, etc., etc., and buy some complicated compiler to do anything 
using scripting. At least, until you need those GUI features...

So, I would like to be able to convince the developer to switch to wxLua 
instead. But, several questions need answering:

1. Threading. This already causes some issues. While coprocedures can be 
used and suspended/resumed to "fake" true threading, no additional threading 
systems are available. One reason being to avoid the script going out of 
sync with the data incoming to it. You don't want some complex process 
handling something to deal with line 50, while the client is displaying line 
120, and a third script is altering the contents of line 114, which must, 
after that, be redisplayed in the correct order... The fear is obvious. How 
do events effect the situtation in cases where the script system and client 
are in the same thread space, and anything the script does may "suspend" the 
client until its finished?

Put simply, none of us have a real clear understanding of just how the heck 
the event system works, or what effect that could have on the client.

2. We don't have a clue how the event system works at all in this context. 
Does the client, which is written in MFC, need to have some adjustment made 
for the event generators and sinks to even work within wxLua? If so, how? If 
not, then why not?

3. Now, this is the one that is the cause of some of the angst about the 
above issues. How does wxLua deal with cases where *it* isn't the initial 
GUI host? Put simply, the client has its own windows. There is a function 
added a while back, so that other applications could get better data on the 
client windows position, etc., called "GetFrame". This returns a handle to 
the main window of the client. This means that, in theory, making a new 
window is as simple as telling the frame creation function in wxLua to use 
"that" handle as the parent, not NULL. However, this could potentially have 
an impact on just how events get handled.

Now, my impression is that the new frame and its objects should become 
children of the main client window. This should mean that MFC will 
automatically pass any messages for those objects "to" the correct child 
window, and that event generated by those should correctly call the 
functions in wxLua that they have been "connected" to. But I admit complete 
ignorance on the subject with respect to *if* this is true, not to mention 
how to fix the problem if its not. Obviously, most examples that the wxlua 
system comes with "assume" that the client has no window, and that wxLua 
itself will create the master window. This doesn't lend any information one 
way or the other as to what the result will be in any case this isn't the 
way things are set up.

Thanks for any help you can provide on these issues. The client I use is 
quite good, but needing to rely on "external" extensions to provide new GUI 
elements adds a level of complication that makes it unlikely for most people 
to even try developing such extensions. It adds a what is a nasty learning 
curve and huge cost to doing so, or, in the case of free compilers, which 
lack the additional tools to make development easy, it creates an "insane" 
learning curve, which 99% of the clients users are never going to over come, 
and which even most of those that already have the skill and tools, don't 
want to waste on it. wxLua could potentially solve a huge problem if it will 
work as I hope it does in such an implimentation.

_________________________________________________________________
Valentine’s Day -- Shop for gifts that spell L-O-V-E at MSN Shopping 
http://shopping.msn.com/content/shp/?ctId=8323,ptnrid=37,ptnrdata=24095&tcode=wlmtagline

Re: [wxlua-users] I have some questions...

[John L. <jla...@gm...>]

On 1/30/07, Patrick Elliott <sha...@ho...> wrote:
> I am using a client to play MUDs which recently went withLua as its "main"
> scripting system. This works nicely, but has a fatal flaw imho, which is
> shared by all other script systems in this context. wxLua would correct this
> flaw, by adding the capacity to develop new GUI elements within the context

This would be easy to do with wxLua.

> So, I would like to be able to convince the developer to switch to wxLua
> instead. But, several questions need answering:
>
> 1. Threading. This already causes some issues. While coprocedures can be
> used and suspended/resumed to "fake" true threading, no additional threading
> systems are available. One reason being to avoid the script going out of
> sync with the data incoming to it. You don't want some complex process
> handling something to deal with line 50, while the client is displaying line
> 120, and a third script is altering the contents of line 114, which must,
> after that, be redisplayed in the correct order... The fear is obvious. How
> do events effect the situtation in cases where the script system and client
> are in the same thread space, and anything the script does may "suspend" the
> client until its finished?

If they're in the same thread then only one of them is active, events
will only be sent when your functions are idle. You cannot have "while
1 do ... end" since you don't allow the event loop to run unless you
call wxApp::Pending() and Dispatch(). I believe there was some
messages on wxlua-users about this too?

> Put simply, none of us have a real clear understanding of just how the heck
> the event system works, or what effect that could have on the client.

The event system is the GUI main loop. All GUI calls MUST be made in
the main thread since that's what the underlying system, MSW, GTK,
OSX, supports. You can create wxThreads in wxLua (untested, but there
shouldn't be any reason why they wouldn't work) and use wxPostEvent to
queue events back to the main thread where you can then call GUI
functions.

You can also "fake" threads using EVT_IDLE, these are idle events that
are sent when the event queue is emptied and you can use
wxIdleEvent::RequestMore (IIRC) to keep it going.

> 2. We don't have a clue how the event system works at all in this context.
> Does the client, which is written in MFC, need to have some adjustment made
> for the event generators and sinks to even work within wxLua? If so, how? If
> not, then why not?

Please see #1 and #3.

> 3. Now, this is the one that is the cause of some of the angst about the
> above issues. How does wxLua deal with cases where *it* isn't the initial
> GUI host? Put simply, the client has its own windows. There is a function
> added a while back, so that other applications could get better data on the
> client windows position, etc., called "GetFrame". This returns a handle to
> the main window of the client. This means that, in theory, making a new
> window is as simple as telling the frame creation function in wxLua to use
> "that" handle as the parent, not NULL. However, this could potentially have
> an impact on just how events get handled.

See wx-users mailing list for messages about using wxWidgets as a
plugin for photoshop. I believe there is code about how to do this,
perhaps on the Wiki? I know it can be done in C++ and there's no
reason why it wouldn't work with the lua bindings since wxLua is
really only translating from lua to C to wxWidgets C++ and back. We
may have to wrap the HNDWND however or just treat it as a void*
pointer.

> Now, my impression is that the new frame and its objects should become
> children of the main client window. This should mean that MFC will
> automatically pass any messages for those objects "to" the correct child
> window, and that event generated by those should correctly call the
> functions in wxLua that they have been "connected" to. But I admit complete
> ignorance on the subject with respect to *if* this is true, not to mention
> how to fix the problem if its not. Obviously, most examples that the wxlua
> system comes with "assume" that the client has no window, and that wxLua
> itself will create the master window. This doesn't lend any information one
> way or the other as to what the result will be in any case this isn't the
> way things are set up.

See the photoshop plugin discussions.

> Thanks for any help you can provide on these issues. The client I use is
> quite good, but needing to rely on "external" extensions to provide new GUI
> elements adds a level of complication that makes it unlikely for most people
> to even try developing such extensions. It adds a what is a nasty learning
> curve and huge cost to doing so, or, in the case of free compilers, which
> lack the additional tools to make development easy, it creates an "insane"
> learning curve, which 99% of the clients users are never going to over come,
> and which even most of those that already have the skill and tools, don't
> want to waste on it. wxLua could potentially solve a huge problem if it will
> work as I hope it does in such an implimentation.

The way I see it is, you'll create your own plugin module, a DLL I
suppose with a bit of C++ code as described in the photoshop plugin
wx-users/wx-dev message threads, create a wxLuaState (eg. a lua_State)
and then throw code at it.

Some simple examples of the C++ side are in
wxLua/modules/luamodule
wxLua/apps/wxluafreeze
wxLua/apps/wxlua

Hope this helps,
    John Labenski

Re: [wxlua-users] I have some questions...

[Patrick E. <sha...@ho...>]

>From: "John Labenski" <jla...@gm...>
>Reply-To: wxl...@li...
>To: wxl...@li...
>Subject: Re: [wxlua-users] I have some questions...
>Date: Tue, 30 Jan 2007 13:41:28 -0500
>
>On 1/30/07, Patrick Elliott <sha...@ho...> wrote:
> > I am using a client to play MUDs which recently went withLua as its 
>"main"
> > scripting system. This works nicely, but has a fatal flaw imho, which is
> > shared by all other script systems in this context. wxLua would correct 
>this
> > flaw, by adding the capacity to develop new GUI elements within the 
>context
>
>This would be easy to do with wxLua.
>
> > So, I would like to be able to convince the developer to switch to wxLua
> > instead. But, several questions need answering:
> >
> > 1. Threading. This already causes some issues. While coprocedures can be
> > used and suspended/resumed to "fake" true threading, no additional 
>threading
> > systems are available. One reason being to avoid the script going out of
> > sync with the data incoming to it. You don't want some complex process
> > handling something to deal with line 50, while the client is displaying 
>line
> > 120, and a third script is altering the contents of line 114, which 
>must,
> > after that, be redisplayed in the correct order... The fear is obvious. 
>How
> > do events effect the situtation in cases where the script system and 
>client
> > are in the same thread space, and anything the script does may "suspend" 
>the
> > client until its finished?
>
>If they're in the same thread then only one of them is active, events
>will only be sent when your functions are idle. You cannot have "while
>1 do ... end" since you don't allow the event loop to run unless you
>call wxApp::Pending() and Dispatch(). I believe there was some
>messages on wxlua-users about this too?
>
Yep. This is already a known issue. Causes all sorts of hassle when trying 
to do something like the attempt I made to use an API call in vbscript (the 
client supports like 7-8 options for script engines, though Lua is likely to 
eventually become the "only" one, do to its features and portability) to 
open an http port, load a page, then display the current ranking from that 
page for the MUD. Hung the client, mostly due to dialup, for like a minute 
and a half waiting for the function to return the data. lol

Nah, 90% of the time the scripts are idle, with the client handling 
everything. Its only when timed, triggered or macro events, generated by the 
client, happen and those either call a script function, or execute 
"immediate" code, that the scripts become active, for the duration of what 
ever that script does. This is usually fractions of a second. The issue here 
is a bit more complicated though, since the clients means of making these 
calls is to have its "own" events simply perform a call to the script. No 
GUI elements fire events that are handled by the script system at the 
moment. So if, for example, you had an input box, the client would do this:

Show box.
Handle "OK" button event.
Check to see if master script or any "plugin" contains OnTextBox or 
OnPluginTextBox function.
Call any functions that do exist for that.

Plugins in this context are XML files containing triggers (fire on incoming 
text), aliases (fire on user input), timers and any script related to them, 
all in a self contained instance. Each plugin can use a different language, 
and more to the point, each one that uses script in that language produces a 
seperate instance of the script engine, so that all variables and functions 
in them exist independently, without naming conflicts or other issues.

What this means is that if you could have plugins for several things, such 
as:

a) main script, for those things hard to do in a plugin - written with 
PhpScript
b) tracking how many items you found in a quest, sent to the main output - 
written with VBScript
c) icon bar for spells - written with wxLua
d) window for tracking player health graphically - written with wxLua
e) window for displaying graphics, using callbacks for the MXP protocol - 
written with wxLua
f) text window for chat, with a seperate chat input - written with wxLua
g) some plugin to keep track of potions you can make - written with Python
h) something else - written with Perlscript
etc.

All of them with entirely independent variable and script spaces, of which 
c, d, e, f and *maybe* g are have some sort of GUI elements that can or do 
generate events that their "specific" scripts need to handle.

> > Put simply, none of us have a real clear understanding of just how the 
>heck
> > the event system works, or what effect that could have on the client.
>
>The event system is the GUI main loop. All GUI calls MUST be made in
>the main thread since that's what the underlying system, MSW, GTK,
>OSX, supports. You can create wxThreads in wxLua (untested, but there
>shouldn't be any reason why they wouldn't work) and use wxPostEvent to
>queue events back to the main thread where you can then call GUI
>functions.
>
Umm. English please? lol But seriously, MFC handles all that internally 
itself, passing the needed events to the correct places, at least *when* 
everything you are using is MFC. Its slightly less certain what happens when 
you attach someone else's window to the main GUI frame of an application 
that didn't create it, even if the window is made by a script system which 
is running "in" that applications event system. Where trying to shoehorn 
things in place here I think, and most applications avoid it, like IE does, 
by having all objects create "through its own" instancing system. wxLua as a 
stand alone environment doesn't have a main window until you make one. 
Things like Photoshop, which you meantion, have fairly specific interfaces 
"designed" to deal with these things, and its not clear how they work, since 
having the interface code to make a plugin isn't the same thing as having 
the code *for* the interface itself.

The thread I found in using it with Photoshop is also talking about MACs, 
which tend to have different event sink systems than Windows too, so not 
sure how it would translate.

> > 3. Now, this is the one that is the cause of some of the angst about the
> > above issues. How does wxLua deal with cases where *it* isn't the 
>initial
> > GUI host? Put simply, the client has its own windows. There is a 
>function
> > added a while back, so that other applications could get better data on 
>the
> > client windows position, etc., called "GetFrame". This returns a handle 
>to
> > the main window of the client. This means that, in theory, making a new
> > window is as simple as telling the frame creation function in wxLua to 
>use
> > "that" handle as the parent, not NULL. However, this could potentially 
>have
> > an impact on just how events get handled.
>
>See wx-users mailing list for messages about using wxWidgets as a
>plugin for photoshop. I believe there is code about how to do this,
>perhaps on the Wiki? I know it can be done in C++ and there's no
>reason why it wouldn't work with the lua bindings since wxLua is
>really only translating from lua to C to wxWidgets C++ and back. We
>may have to wrap the HNDWND however or just treat it as a void*
>pointer.
>
Not possible to use "void*" or the like. That is **only** allowed if its the 
first window in the thread space. Creating one that way will briefly give 
you a frame, then immediately crash both the client and the script engine. I 
tried it with Python way back before we had a "getframe" function in the 
client, and well before I know how to use the windows API functions to do a 
FindWindow... lol I gave up on trying for over a year, and went looking for 
other options instead. Later the GetFrame function was added, but by then I 
was wandering down a dead end search for a COM bridge to get events 
working... At the time I had even less of a clue how events worked than I do 
now, and given that I am still confused about it... lol

> > ...
>
>See the photoshop plugin discussions.
>
Things like this don't give me much confidence:

"but the interesting thing for me is now whether Photoshop has installed
its own handlers which would be delivered with events even using this
implementation, or whether it still needs the old WNE style version.
Then I'd have to install some low level handlers presumably at the app
level which then would deliver synthesized events to the plug-in
connection point. the alternative being that we'd run the old style WNE
event loop for these situations, which would mean that I would not need
any additional code."

And that is ignoring how most of the thread is about MAC, not Windows...

>The way I see it is, you'll create your own plugin module, a DLL I
>suppose with a bit of C++ code as described in the photoshop plugin
>wx-users/wx-dev message threads, create a wxLuaState (eg. a lua_State)
>and then throw code at it.
>
That is what he is doing now, with Lua. The issue becomes, what happens if 
that code then creates a window, sticks some buttons on it, then expects the 
events from those things it owns, but the client itself is the parent of 
(again, you can't create two master windows in the same application, and as 
a dll, Lua and wxLua exist as "part" of the client application, as far as 
the OS is concerned. Most implimentations are "not" going to be using the 
clients window as its main, or, as with things like IE, limit the feature 
you can create, by "requiring" that you use the clients version of 
CreateObject, or what ever, to make the new items, as well as having "it" 
handle the "connect" function and the events. Its not entirely clear what 
happens if you want the client to host the objects made by the script, but 
the script to instance them and call the connect functions for the objects 
events, instead of letting the client do it, or alternatively, as is most 
common in all the examples usually do, have the script do "all" of the event 
handling and GUI creation.

We are looking at a mixed bag here. I personally think that it should work 
anyway. At worst, it might be necessary to do something like:

main_events {
  Is this my event?
    handle_event
  else
    a = 0
    loop
      script = scriptlist[a]
      pass_event_to (script)
      a = a + 1
    until scriptlist[a] = NULL
}

In other words, it may be necessary to override the MFC main event loop and 
add code to send each active script engine the events that the client 
recieves, but would normally go, "What the #$#$? I don't own that!"

>Some simple examples of the C++ side are in
>wxLua/modules/luamodule
>wxLua/apps/wxluafreeze
>wxLua/apps/wxlua
>
I'll take a look, but I suspect these will use the same "wxLua creates all 
the GUI elements" types. I don't find a wide dearth of examples that deal 
with *unusual* cases with... almost any language. lol

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline