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.
_________________________________________________________________
Valentines 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
-------------------------------------------------------------------------
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
