>From: "John Labenski" <[EMAIL PROTECTED]>
>Reply-To: wxlua-users@lists.sourceforge.net
>To: wxlua-users@lists.sourceforge.net
>Subject: Re: [wxlua-users] I have some questions...
>Date: Tue, 30 Jan 2007 13:41:28 -0500
>
>On 1/30/07, Patrick Elliott <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
