Event trapping...

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. :(

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.

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.

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