Ok, first, lets drop the whole bloody DLL vs ActiveX stuff. That was "never" the intent of what I was saying, beyond mentioning the similarities, which I only recently have come to understand to a reasonable degree. I simply used the similarity to sideline into another issue.
That said, I take it you haven't read "any" of my other posts on the subject I am trying to talk about? Lets try to put this simply then.. Right now there are three ways to create windows, mappers, or any other feature, and have them talk to Mushclient.
1. Link the TLB for Mushclient into them and use CallPlugin.
2. Use UDP.
3. Create a ghost world and use TCP/IP.
The problem with "all" of these solutions is two fold. First, you can't use a control or program you did not **specifically** write for Mushclient, unless its "only" interfaces are one way. I.e. You can, like a database, pass them the "location" you want the response to go in, if they respond, but not let them respond "later", when they are done with some task. Second, they are all basically work arounds, with CallPlugin being the only one that comes even "close" to letting the applications talk directly to your script. This means that existing applications or controls are unusable, if they expect the client that asks to use them to get their response directly, through and event. Only those you can create a sort of Mushclient aware shell to fit in, or you stick on an application of your own (basically the same thing), can talk to Mushclient, indirectly.
This also has another side effect. Anything like custom windows, new notepad windows, etc., all have to be included "in" Mushclient itself, even of some languages, including Lua, make handling those thing from the script trivial, if often requiring, the right addon libraries. Why? Because even "with" those libraries, there is no way to link something as simple as a button click to your script. The script simply cannot ever tell the connection point, "When someone clicks this button, call this script function."
Think about it. That leaves *huge* gap in what you can do. It also means that any potential solutions have to be hard coded into Mushclient, which leaves Nick as the one that has to decide how they should work, not the people that get the idea in the first place, who are not always happy with the solution Nick comes up with.
What I would like to be able to do is create a plugin that can do roughly the following:
win = createobject("Some window object")
win.parent = GetFrame
button1 = createobject("VBButton")
button1.parent = win
button1.lable = "Press me!"
...
Advise ("Button1_Click", "OnBut1_Click")
function OnBut1_Click ()
note "Someone clicked me!!"
end function
In other words, skip the whole insane mess needed to indirectly make this work. Have the plugin itself define, say, a window that contains icons, to keep track of your spells, let the script respond to clicks on them that are intended to recast the spell, etc. And **not** require that every poor user that wants to do this has to buy a $600 compiler and either dozens of books on how to do anything, or get a college degree, just to write a completely seperate program, which then has to be installed some place, to stick a few pictures in a window. Imho, this is completely rediculous. And it limits even what those of us that can do these things are able to do with the client, because we spend almost as much time trying to figure out how the program should talk to the script as we do designing the program.
A good example of this is the recent mapper. Why? Because I am sure the zMud mapper uses DLL interfaces of ActiveX, which means it "should be" possible to tie it into a Mushclient script, but not if all out-going intefaces are disabled, because the script can't connect them. The solution will invariably be so Mushclient centric that its non usable for anything else, or so generalized, that we have to resort to TCP/IP or UDP to make the connections instead, one of which doesn't always work well, and the other of which requires a imho bizzare hack that, while it works, simply clutters the client with extra worlds that are not invovled in "any" direct game playing.
However, more to the point.. I wouldn't mind seeing, as part of these plugins, something that could read in a "description" of the window you want and another "design" plugin that uses the user_mode switch for its window, so you can *actually* create, place, resize, rename, relabel, etc. the controls you want, save the result to a file, and then import it to your new plugin to provide a pre-designed window of any kind you want. That also requires more direct access to the controls, since all MFC and ATL solutions "assume" that the code that does this is referring to "the window that the code itself belongs too." Or at least, there is no indication how you tell it to change that for any window except the active one, which we absolutely don't have to have happen. Imagine Every window, control and button in Mushclient's main window suddenly becoming movable... while at the same time "all" of the windows controls, buttons, menus, etc. are diabled and stop working. Very bad idea... lol
So, what we need is:
1. Some way to use IUknown::Advise to link a script to the events.
2. Some way to access Ambient_UserMode, but limit it to only script created windows.
Having those, we can create a form designer plugin *and* build damn near anything we want "in" the client, instead of hoping someone with a Bachelors degree, or better, in programming, and the money to buy the tools, decides to bother making some gadget everyone would like to have.
This is in essense what I would like to see be possible. It bugs me that the script languages "can" be extended with readily available libraries for a lot of it, but two relatively minor limitations prevent it from working at all. Or that when Nick does agree to add something, its by hardcoding it into the client, when imho that should be necessary, or for that matter, always desirable. |