Gammon Forum : MUSHclient : VBscript : Adding window with info about character

Entire forum ➜ MUSHclient ➜ VBscript ➜ Adding window with info about character

Adding window with info about character

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2

Posted by

Irzadi (7 posts) Bio

Date

Reply #15 on Mon 23 Feb 2004 09:16 AM (UTC)

Message

I have had some problems, namely if I change my target I sometimes got a message telling me that PCRE doesnt support a certain character (or something sound like that, I press enter right after I change my target which remove the error message and I cant reproduce the error).

But still, with PartialLine plugin and the other upgrades, it rocks !

Top

Posted by

Irzadi (7 posts) Bio

Date

Reply #16 on Mon 23 Feb 2004 10:15 AM (UTC)

Message

The message is :

Failed : PCRE does not support \L, \I,\N, \P, \p,\U,\u or \X at offset 2

Top

Posted by

Zuurstof (13 posts) Bio

Date

Reply #17 on Mon 23 Feb 2004 12:02 PM (UTC)

Message

Well I did some looking around, now I use this workaround to open the form. It seems it's some kind of bug.

now I use an api call to open the form and that works

Declare Function ShowWindow& Lib "user32" (ByVal hwnd As Long, ByVal nCmdShow As Long)

in the class

Load frm
lres = ShowWindow(frm.hwnd, SW_SHOWNORMAL)

Then I use another api to make sure it remains on the top all of the time. Now it's just matter of figuring out how I can handle lostfocus events from the client to make sure my window dissapears when somebody goes to another application and that is reappears when mushclient gets the focus again.

Thanks for all your help people!

Greetings Zuurstof

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #18 on Mon 23 Feb 2004 06:10 PM (UTC)

Message

Hmm. Ok. I think I see your problem... I had a similar crash trying to get around this limitation when fiddling with Python. A non-modal window *must* have a parent. The problem is your DLL does not have a 'main' window. Don't ask me why it isn't considered a main window, but it isn't. Thus when you attempt to open the window from the script, there is no primary window for it to identify as a parent and it crashes with an error.

Now, two prossible solutions: Use an EXE instead of a DLL, so that your main form becomes the primary window. This may still be possible with a DLL, but I haven't a clue why it won't work. This won't place it *inside* Mushclient, but I am confused as to why it needs to be. My fireworks gadget uses this method and works perfectly, it also automatically closes the moment you close mushclient or you directly destroy the scripts instance of the object.

Second option: *Before* creating the window, use world.GetFrame to send Mushclient's main window handle to your DLL and then when you create the form, set its parent to this handle, *then* show it. I have no idea if this will actually work or not, but that would make it a true child of Mushclient's primary window. This may be a really bad idea though, which is why I haven't attempted it. The results could be unpredictable and could generate a crash when you attempt to close Mushclient. On the other hand, it could turn out to work perfectly, which would open up the ability to use the wxPython extensions to do a mess of stuff that currently won't work at all in that script language, unless it runs in the Python GUI, instead of the scripting engine.

The fact of the matter is that VBScript, JavaScript, etc. *are not designed* to create instances of new windows inside the client running them. The reason for this is very simple, they don't have access to that client's address space, objects, windows or anything else. The only access they have to the program they are running in is through the calls that the client itself 'links' into the script engine when it starts. Programs like IE or Word, that do allow such things use their own methods to create the objects and their own methods to link the events and other features of that window or control into the engine, so that the script becomes aware of them.

What you are trying to do is get the script to create and object and suddenly have the client know that it exists and belongs to the client. Even if you managed to attach the new window to the client, it probably won't have a clue that this window belongs to it, what to do with it if something goes wrong or how to properly handle any messages related to it. The only way to do this is if a method existing like I mentioned earlier in this thread (for IE) that lets the client create the object and merely provides the script with the needed calls and references to use it. Any object created *by* the script itself *must* provide its own container (primary window) to display controls, including child windows.

Top

Posted by

Ked Russia (524 posts) Bio

Date

Reply #19 on Tue 24 Feb 2004 02:54 AM (UTC)

Message

"Second option: *Before* creating the window, use world.GetFrame to send Mushclient's main window handle to your DLL and then when you create the form, set its parent to this handle, *then* show it. I have no idea if this will actually work or not, but that would make it a true child of Mushclient's primary window. This may be a really bad idea though, which is why I haven't attempted it. The results could be unpredictable and could generate a crash when you attempt to close Mushclient. On the other hand, it could turn out to work perfectly, which would open up the ability to use the wxPython extensions to do a mess of stuff that currently won't work at all in that script language, unless it runs in the Python GUI, instead of the scripting engine.
"

I tried that with wxPython (well, using a LocalServer component instead of an Inproc DLL) and it didn't do much aside from causing type errors. Perhaps some sort of a cast is needed to get an appropriate object using the result of world.GetFrame. However, as I have a very faint idea of what exactly it is that world.GetFrame returns, and docking windows isn't among my priorities right now, I decided to let it rest. I find creating stand-alone toplevel applications in wxPython to be easier than trying to fit an extra process into Mushclient, and it's a pretty safe way of doing things too if not for a couple of problems. One is with wxPython's threading problem - needs to run in the main thread, which is impossible since COM needs to reside there, but a solution to this must exist. I've managed to get it to the point of being able to shut down and relaunch the application several times in a row without a single crash, though it still crashes sometimes. Another problem is getting the messages through to Mushclient from your stand-alone. Using callbacks provides a solution, but it is a very limited one. Another solution might be COM events, through pythoncom's DispatchWithEvents method, which lets you specify an event handling class in the script that launches the application and pass that class to the application when it is launched. However, the problem with that is the same as above - I don't know how events work in COM and haven't had the time to dig up anything substantial on the matter yet. Still, I remain convinced that wxPython is the best solution to the problem of spawning windows for Mushclient.

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #20 on Tue 24 Feb 2004 06:31 AM (UTC)

Amended on Tue 24 Feb 2004 06:33 AM (UTC) by Shadowfyr

Message

If you have Spy++ some place (It comes with VC++), then the 'handle' returned by GetFrame will appear in the list of windows like this:

--------vvvvvvvv--------
Window 0000063A "MUSHclient - [Some Mud Name [Closed]]" Afx:400000:8:14B6:0:6337

The first Hex number is the handle from GetFrame, the second part is obviously the title bar text and the last is a class name:

Afx - Referes to the Afx base class I think, all windows share this.
400000 - The instance of this window.
8:14B6:0:6337 - I have no idea, but 14B6 is always the number for Mushclient and 6337 may be somehow related to it being a child of Desktop. I can't remember what I read about it some place.

Anyway.. Handles to objects are 32-bit integers, so the value returned by things like FindWindow or Object.hwnd is the same identical number that GetFrame returns, or should be anyway. I checked the number shown using 'note hex(GetFrame)' against the value returned by Spy++ for the main window. This is not a direct object reference though, so the program may simply refuse to take the integer value and treat it as a valid reference, which would be really inconvenient. Also, Python may instead be seeing a variant and expecting a 32-bit integer (Long for VB, Int for C++). I have no idea.

In theory the number is correct. The issue is if you can convince the damn programs to use it.

Top

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #21 on Tue 24 Feb 2004 06:39 AM (UTC)

Message

It is an HWND (window handle). I doubt it is a COM object.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Shadowfyr USA (1,791 posts) Bio

Date

Reply #22 on Tue 24 Feb 2004 04:35 PM (UTC)

Amended on Tue 24 Feb 2004 04:39 PM (UTC) by Shadowfyr

Message

Which is what I said Nick. Apparently Python is somehow refusing to treat it as a valid hWnd though or something. Either that or the command he tried to use expected something else. Some of these languages are pickier than others about the 'type'. For instance.. Since it is passed to Python as a variant type, it needs to convert it into a known Python type. If the value is under the maximum for a 16-bit integer is may be seeing it as a 16-bit integer and failing because the calls that use an hWnd 'require' a 32-bit integer (Long type in VB and maybe Python).

Top

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #23 on Tue 24 Feb 2004 08:29 PM (UTC)

Message

Quote:

The message is :

Failed : PCRE does not support \L, \I,\N, \P, \p,\U,\u or \X at offset 2

Er, is this my bug or yours? Sounds like an escape sequence has made its way into the regular expression, (eg. \L).

Have you in fact put one there, or is "offset 2" a variable being expanded (eg. @target ...).

If so, perhaps the variable expansion should be escaping them.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Ked Russia (524 posts) Bio

Date

Reply #24 on Fri 27 Feb 2004 07:58 AM (UTC)

Message

Actually I tried passing GetFrame result to a frame (wxMiniFrame) object as a parent argument. I didn't check the type on this result, but I'll do that as soon as I get back to my computer whcih has all the needed stuff installed.

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.

83,117 views.

This is page 2, subject is 2 pages long: 1 2

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top