Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, 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.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ Event trapping...
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Shadowfyr
USA (1,790 posts) 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. :( | | Top |
|
| Posted by
| Shadowfyr
USA (1,790 posts) 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. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,133 posts) 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 | | Top |
|
| Posted by
| Shadowfyr
USA (1,790 posts) 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 | | 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.
14,999 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top