> What this seems to mean to me is that a) that handler will correctly
handle
> events for any object you add to the window/container, making it
unnecessary
> for the hosting application to do anything. This isn't probably likely.
If
> not, then b) you create an MFC class that handles events, *reflect* the
main
> windows event stream to there, parse the events before they hosting
> applications main window has seen them for anything smelling wxLua like,
> retrieve the handle for the wxLua *events* sink, pass the event you
trapped
> on to that, wait for wxLua to do its thing, then mark the event as
"handled"
> in the MFC class and exit, returning control back to the main MFC window
of
> the host.
>
> Now, anyone have a clue which, (a) or (b) is needed, and more to the
point,
> am I completely barking up the wrong tree here?
Both a and b exist as possibilities to... something? I'm not sure what
it is that you really want to do?
Please give a simple example of what you'd like to achieve.
John Labenski
Ok. This is the best response I have seen from anyone so far, so here is
hoping. lol
Trick here is, someone else wrote a MFC based application that "hosts" Lua
as its script system. This means its already implimented a lookup table for
dealing with things like callback, so if you "plugin" a script, defined
along with other things like text triggers, timers, etc., into the client,
it does several things:
1. Reads in the triggers, etc. and places them into an internal structure
for controlling them.
2. Looks through the script for functions like OnPluginConnect, which it
will call when you create a connection to a remote server, for example.
3. Create a new instance of the Lua engine to maintain code seperation
between it and other plugins, then loads in the script.
Some things like connecting, disconnecting, sending text, etc. automatically
attempt to find and call the function specific to them in each plugin
installed.
All well and good "so far". Now what happens when you want to extend the
client by either creating and ActiveX object or, worse, a new window that
**isn't** actually supported in the hosting application itself? Now you have
a problem. You can create it, but you only have means to talk to its
functions, not handle its events. For example, Internet Explorer supplies
two things:
1. A "State" function.
2. An Finished Loading *event*.
Currently, if you create and instance of IE in the script, you would need to
create a timer that periodically reaquests "state" from IE, to determing if
the page you ask it to load *has* loaded. The event isn't available. This
only gets worse if what you are trying to do is something like displaying a
picture.
Now, lets say you connect to a server and its text contains and MXP tag
(basically HTML for text servers):
<image="www.myserver.com\images\myleftshoe">
You can "trap" MXP events with OnPluginMXP, or some such. So here is the
code I would "like" to see (psuedocode of course, since I am fairly novice
at Lua...):
OnPluginMXP () {
mywin = createframe(GetFrame, blah...)
myimage = createpicturebox(mywin, blah...)
...do some sockets stuff to retrieve the image from the server...
myimage.image = retrieved_image
mybutton = createbutton(mywin, blah...)
wxconnect (mybutton.close, Iclosed)
}
Iclosed () {
note "To look at the image again, type 'look'."
}
Well, I think you get my point. The host *must* be the parent of mywin, or
the whole thing crashes. Its however not been entirely clear to anyone
trying to make this work as to how or if wxLua's own event handler works in
this environment. Your description would seem to imply that the OS will
automatically know that there is more than one handler, call the wx handler
*first*, then pass things down the chain to the main window. But, usually it
works the other way. MFC handles "all" messages in its own main windows
event system, and for any child window to recieve it first you must use
"message reflection" to get them to see it. As I see the problem, it hedges
on if wxLua's own handler(s) are also children of the MFC client, or if they
are independent, as far as Windows is concerned. If the later, it should
work just as though wxLua was running in an environment with "no" other
handler. If not, then each "plugin" will need to have events "reflected" to
them by the MFC system, so that they can handle them first. Otherwise MFC
will get the system message for the event, compare it to its own internal
set of IDs for the hosting application, then just ignore them. The hosted
script engines will never even see them.
*Warning, the rest of this gets a bit ranty, but it does explain the
situation we are currently confronted with*
Mostly this was started with a simple idea, back when Lua wasn't even an
option. Take Winamp, install a COM dll wrapper for it, use the script to
instance Winamp from inside the client, let its "SongChange" event tell me
when to check the song name, so I can update the text on the applications
info bar to show the "current" song that is playing. Only problem was.. That
script system at the time was VBScript, which doesn't have its own event
handler at all. Now.. We are looking at things like creating custom email
windows, maps, toolbars, etc., to enhance game play using the client. The
client has "no" support for events from any of these things imbedded in
itself, and the general feeling, by everyone else, who has even **less**
clue how it works than I do, is that, "Its going to bloat the application,
making it a huge download and you can always just write something in C++ or
Visual Basic to do this and use the function table for the client to have
that "talk" to the scripts through the client itself." Uh... Sure, if you a)
own one of those, b) have a clue how to do that and c) are not some casual
user who just wants to spend 10-20 minutes telling the script, "Make me a
window to show this.", then go back to playing the game. I would say that of
the thousands of people that do code script for the client, less 10% of us
have the expertise to code external applications to do this simple stuff,
and probably less than 10% of those that do want to waste time doing it in
the first place. That doesn't exactly make for a *huge* base of people who
are going to create new gadgets for the application, all of which ignore
pre-existing event sources in favor of direct linking every bloody thing
through internal client functions like OnCallPlugin, which have to *then*
act as event handlers anyway by calling the correct function, based on what
information was just passed to it.
Instead of finding a way to make events work, we are reinventing the wheel
and writing out own bloody event handlers. Its just completely silly and it
completely fails to address pre-existing applications or dlls, which don't
know how to talk to the client, and would require yet another translation
layer to be sandwitched into the whole mess to take *real* events and funnel
them into the functions supplied by the client for talking to it, 90% of
which the "script" needs, not the client, so we are doing this:
Application does Fire_Event -> Translation layer sorts out what the event
is, then does Fire_Event (CallPlugin) -> Client figures out which "plugin"
it belongs to, calls its "OnCallPlugin" function -> OnCallPlugin sorts
through the events **again** to figure out what to do about it, *finally*
calling the correct functions.
Note also, in the case of something like Winamp... We are talking about
creating a translation layer "for" the existing translation layer. Since
Winamp doesn't itself support ActiveX, but requires a plugin, you are having
it tell "its" translation layer to convert to ActiveX, then creating a new
translation layer to go from ActiveX to what the client supports, *then*
finally handling the events.
No one in their right mind is going to want to code the translation layer
for every bloody application some poor fool might want to use with this
client. And, as I said, it only gets more absurd when all you want to do is
create a window with a button and a picture on it.
_________________________________________________________________
Don’t miss your chance to WIN 10 hours of private jet travel from Microsoft®
Office Live http://clk.atdmt.com/MRT/go/mcrssaub0540002499mrt/direct/01/
-------------------------------------------------------------------------
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
