[Home] [Downloads] [Search] [Help/forum]

Gammon Forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Suggestions
. . -> [Subject]  Event trapping...
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Event trapping...

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


Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Wed 07 Dec 2005 03:56 AM (UTC)
Message
Not sure how I missed this the last 53 times I looked, but check this out Nick:

http://msdn.microsoft.com/msdnmag/issues/01/03/connpoints/

Not all the prelim stuff, but the part starting at "The Bridge Solution".

This object obviously has the same problem if instanced using CreateObject as every other object, since you could no more get a script to respond to the events from it, than from the one you are bridging to. *But*, if the functionality of the bridge existing in Mushclient itself, then any object created within any script would gain the same benefit as VB does from it. The client could bridge the gap between to CreateObject command and the event catching, thus solving the major problem that you invented the UDP solution to get around. Which is a solution that only works for 'new' applications, not simple controls or existing applicatios, like the Winamp interface.

I bloody knew this had to be possible, just took me ages to find code for it. :(

Note, this could mean that you could provide a utils.newwindow function now, which would provide a generic blank window and we could use CreateObject to populate it with controls, then use the bridge to actually have the script respond to clicking its buttons and stuff. Its *****great!!!!***** Assuming you are interested in added such support that is. But even if not, then there are existing VB controls for different window types that could be less directly created, then again, with the bridge in place, is real easy to set up any kind of window you want from there. And here I went and made a complete ass of myself on another forum to ask yet again if anyone knew a solution. :(
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #1 on Fri 09 Dec 2005 04:53 PM (UTC)
Message
Not to complain or anything, but have you looked at this at all Nick? Maybe I need to clearify. This solution requires the bridge to be **in Mushclient** for it to work, or alternatively at least as a DLL that Mushclient itself employs, then provides script access to through the two commands that watch for this stuff. Though, I third command that could list available events from the object being watched would be useful as well, but that's just an interesting addition that could be made to improve it.
[Go to top] top

Posted by Nick Gammon   Australia  (21,322 posts)  [Biography] bio   Forum Administrator
Date Reply #2 on Fri 09 Dec 2005 11:45 PM (UTC)
Message
Yes, I was going to comment. :)

My mind boggled a bit reading the page. As far as I can see, the solution was written for ATL rather than MFC. Not sure if that will matter, it might.

I think the essence of the problem is that you are trying to funnel events from MUSHclient into an external control or whatever. This is pretty fundamental to making them respond to things (like needing to redraw the screen).

However because of MFC (Microsoft Foundation Class) libraries, I don't actually personally get most events. They are inside an inner loop inside MFC. Ones that are deemed relevant to me (eg. screen redraw, timer firing) are made available to me.

I'm not sure if the proposed solution here will work for me, I can try again soon. I wanted to get the other stuff released first, in case I had to revert everything.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Shadowfyr   USA  (1,783 posts)  [Biography] bio
Date Reply #3 on Sat 10 Dec 2005 12:02 AM (UTC)
Message
I doubt using ATL with MFC will be a problem, they are just libraries that add a bit of extra stuff in between to handle some things. Unless I am mistaken, what this thing is likely doing (I haven't looked at the actual code), is trapping the events, calling anything related to the object being watched, then passing any unhandled events on to the rest of the application. Unless I am wrong, this should mean it will have no effect at all on any code you already have. The only thing it does that I can't guess at, it correctly identify the names of events, so the right script functions can be called for them. The code to do that is... complicated and confusing, which is why I wanted to find a working solution, instead of driving myself nuts trying to actually figure it out. ;) lol
[Go to top] 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.


3,827 views.

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

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at FutureQuest]