Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Python
➜ Thanks Nick! (and other semi-useful info)
Thanks Nick! (and other semi-useful info)
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| WillFa
USA (525 posts) Bio
|
Date
| Mon 11 Aug 2003 11:13 AM (UTC) |
Message
| Hi Nick,
I'm back. Sorry for falling off the face of the earth. I'm really glad that you got Python working in MushClient. I guess I'm really going to have to start mudding again. (No time!)
I read over the threads in this forum, and I have a couple of comments/answers/speculation:
Shadowfyr's window thing I don't think will work. I believe that Mushclient's implemented in a single threaded model, so that all plugins and scripts block execution until they exit. Spawning this child window would deadlock the main client until he closed it. It might be possible to implement an out of process Python server that a plugin can grab a reference to. There's a reference available at http://aspn.activestate.com/ASPN/docs/ActivePython/win32com/win32com/win32com/html/QuickStartServerCom.html for getting started.
As for getting the Methods and Properties directly linked in the global namespace (avoiding world.foo): the "from world import *" won't work because "world" isn't actually a module, but an object with the class "win32com.axscript.client.pyscript.NamedScriptAttribute".
The plugin Python_Version.xml calls the code
"world.note ("Modules = "+ str(sys.builtin_module_names))"
which gives a listing of module names that can be imported without searching the pythonsearchpath.
world.note ("Modules = "+ `sys.modules.keyes()`)
which will give a listing of all modules active in the name-space, which I think is closer to your intentions.
(incidentally, the back-quotes are a shorthand for the repr() function, which is very similar, but not identical to, str() )
CoCreateInstance and IActiveScriptParse... I mentioned that a year ago. ;)
Thanks again, Nick. :) My e-mail's changed so the old one is no longer valid. New one's in my profile if you need it.
WillFa | Top |
|
Posted by
| Shadowfyr
USA (1,787 posts) Bio
|
Date
| Reply #1 on Mon 11 Aug 2003 07:56 PM (UTC) |
Message
| Actually the window issue goes way beyond that. Mushclient already can execute multiple windows, having notepads, etc. open. The main issue (assuming this isn't what you meant) is that Mushclient makes the scripts sleep. This means that you could open a window once you have access to the frame reference, but while you could display things like pictures, you can't use any buttons on the thing or other controls that actually result in user input. The other more obvious issue is that you can only have a single 'master' window. The one attempt I made that more or less did create a window attempted to make a parentless window (i.e. a master). The window appeared, however, no test button ever appeared on it and closing it caused Mushclient to blow up (obviuosly the OS didn't have a clue 'which' master window it was supposed to be telling to close or how to release the resources properly.
Now the first issue will in the next version be only half a problem. Assuming for instance that you use a control that has scrolling built in, then you may be able to feed text to it and still have the scroll bars work, etc. Showing a picture is easy. Anything that does not specifically require direct human interaction that would cause a system event should be possible. This is a fairly limited, but still possibly useful function.
Now as for making this work... We do need a Python wrapper for Mushclient. I have no clue how to actually do this and the COM support in Python is not something I have looked into real closely. In theory, it should be possible to run a script from inside of your plugin, etc. as a seperate execution. I.e. The plugin merely initiates the Python modual and does calls to it, just like any other COM program, but the Python modual that is run would handle all the communication the other direction throug the Mushclient COM interface, save where something can be returned directly from the call, like retrieving a value from a field or the like. It is not impossible, it just requires figuring out how to get a python script to run from inside a plugin, while executing as a seperate process, the same as any normal COM app.
However, since I had no easy means to latch onto the mushclient window and retrieve things like its WindowRect() attributes, I temporarily put the idea on a back burner. It now may be possible with the next version of Mushclient to more easilly accomplish this, so figuring out how to correctly support COM and talk to Mushclient direct from a Script + a way to execute an outside process from a Python plugin are all that is really needed. I haven't any real clue how to do either. lol I will look at your link to see if it helps though. ;) | Top |
|
Posted by
| WillFa
USA (525 posts) Bio
|
Date
| Reply #2 on Tue 12 Aug 2003 02:41 AM (UTC) |
Message
| Don't know if you care enough Nick...
It looks like the reason that PyScript isn't making the functions of World Global is because IProvideMultipleClassInfo isn't implemented.
The subroutine for Children's found in Framework.py in the FindBuildSubItemsEvents def.
From the commandline in MushClient, running:
/from win32com.axscript import axscript
/world.note(`world._scriptItem_.dispatch.QueryInterface(axscript.IID_IProvideMultipleClassInfo)`)
raises:
COM Error: No such interface supported (0x80004002)
I think you mentioned in the past that you prefer the list of function calls in a flat object model for speed reasons... but if I'm wrong, ever consider a deeper object model?
c = world.triggers.trigger()
c.name, c. pattern, c.options = "foo", "hits", eEnabled
world.triggers.add(c)
reads so much easier with current scripting language syntax. But the bit I know about OLE/AX interfaces, I know it's a lot of work and a real bitch and a half.
Thanks Nick :) | Top |
|
Posted by
| Nick Gammon
Australia (23,046 posts) Bio
Forum Administrator |
Date
| Reply #3 on Thu 14 Aug 2003 08:16 AM (UTC) |
Message
| If I redid it I would do a more sophisticated model, but I - and others - are used to this one now. ;) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| WillFa
USA (525 posts) Bio
|
Date
| Reply #4 on Thu 14 Aug 2003 08:32 AM (UTC) |
Message
| Isn't that what a 4.0 version would be for? ;)
| Top |
|
Posted by
| Shadowfyr
USA (1,787 posts) Bio
|
Date
| Reply #5 on Thu 14 Aug 2003 08:30 PM (UTC) |
Message
| Except that it would break backward compatibility WillFa. I don't see it being a major problem as is. The only issue is documentation, which in some cases can be a pain. For instance, looking up speedwalk won't get you any place, you have to generate an internal list of Option names to find the one to turn it off and on. There are similar annoyances with other things as well. I don't need or want several levels of scope to have to worry about for easilly identified commands. I happen to like being able to simply drop world. and use just the functions name.
Now the inability of someone to make real plugin script calls and the goofy addition of things like AddTriggerEx, instead of overloading the AddTrigger function so that it accepts both the old and extended format do bug me just a little. It makes things more confusing to add a new function, instead of overloading an existing one so that you can optionally us additional parameters imho. And you are quite right that having to build your own interface to get the current CallPlugin feature to work is silly. In theory it might not be 'quite' as bad if you could arbitrarilly pull a function name out of the string and the parameters needed and execute it, but even that requires something more suffisticated than one string to pull off effectively.
For the most part these things are just annoying and inconvenient, but that doesn't mean something shouldn't be done to try to improve them. | Top |
|
Posted by
| Nick Gammon
Australia (23,046 posts) Bio
Forum Administrator |
Date
| Reply #6 on Thu 14 Aug 2003 11:05 PM (UTC) |
Message
| Overloading functions is a C++ concept which applies at the source level - that is, the compiler inspects the arguments and works out which function to call, or to supply default arguments to.
It doesn't work so well at the object level (COM) because there is no compiler, you are calling a precompiled piece of object code, that the system only knows the address of and the number of arguments it takes. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Shadowfyr
USA (1,787 posts) Bio
|
Date
| Reply #7 on Fri 15 Aug 2003 01:24 AM (UTC) |
Message
| Odd.. I have seen stuff about COM that suggests the ability to do it somehow. Maybe I read it wrong. :p | Top |
|
Posted by
| Nick Gammon
Australia (23,046 posts) Bio
Forum Administrator |
Date
| Reply #8 on Fri 15 Aug 2003 03:05 AM (UTC) |
Message
| As I have said before, I am moving away from using things like AddTrigger (and AddTriggerEx) in favour of more flexible ways of achieving the same thing, like ImportXML, which lets you just supply the options you want. See:
http://www.gammon.com.au/scripts/doc.php?function=ImportXML
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
19,182 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top