Shoutbox

quote:

---

Originally posted by matty
I would really like to have an OnProcessEvent_Terminate.

Why would this be beneficial to scripts? Simple. When dealing with system wide hooks, like hot keys. If the Windows Live Messenger process is terminated unexpectedly then you have all this cleanup to perform but no way of actually doing so. The benefit of this event would allow scripters to properly cleanup after themselves as if they would when OnEvent_Uninitialize is called.

Better yet instead of having a new event when the Windows Live Messenger process is terminated instead of just exiting why not allow the scripts to cleanup and call their Uninitialize event. This would make the most sense.

---

Everything in the Messenger process will be terminated directly, including Messenger Plus! and it's scripts running. There's no way to get that event triggered. Just think about the security holes it would cause, not being able to terminate a process.

quote:

---

Originally posted by markee
Time for some bumping.  Anyway, I found something that I'd like.  The ability to cancel the closing of a Plus Window.  Something like returning false to the OnWindowidEvent_Destroyed function would suffice I think.  This way I could just hide the window for a moment even if the user has tried to close the window through the task bar or the X in the corner or something.

---

This is already possible, using OnWindowidEvent_Cancel

quote:

---

Originally posted by Scripting docs
Return Value
A boolean value used by Messenger Plus! to ignore the request. If the function returns true, the cancel request is ignored, if it returns false (default the event is not handled), the window is destroyed.

---

I'd like an OnEvent_Import() as the initialize argument is also true when the script is enbaled =/

Ok, wow i forgot about this thread, i'll update the front page.

Also, if someone could tell me if any of the requests have been added?

quote:

---

Originally posted by MeEtc

quote:

---

Originally posted by markee
Time for some bumping.  Anyway, I found something that I'd like.  The ability to cancel the closing of a Plus Window.  Something like returning false to the OnWindowidEvent_Destroyed function would suffice I think.  This way I could just hide the window for a moment even if the user has tried to close the window through the task bar or the X in the corner or something.

---

This is already possible, using OnWindowidEvent_Cancel

quote:

---

Originally posted by Scripting docs
Return Value
A boolean value used by Messenger Plus! to ignore the request. If the function returns true, the cancel request is ignored, if it returns false (default the event is not handled), the window is destroyed.

---

---

And this is why we need a single page with every event, method and property, with a brief description and the minimum version number for each (in both a-z listing, a-z in their types and in their versions).  This would also make it easy to notice updates when a new version comes out.  I know it isn't an API request as such but it would make it easier.  And why did we need 2 functions for this feature as well? ExitCode === 2 tells us that it was one of these other methods of closing the window doesn't it?  Maybe Patchou just wanted to jerk us scripters about

I propose a new function for creating windows with a string and not just an .xml file.  This wouldmake translations easier and would mean that you wouldn't have those problems with unicode formatting, etc.  You could also have it more dynamic, like what as wanted in Adding labels to a window via script.

quote:

---

Originally posted by markee
I propose a new function for creating windows with a string and not just an .xml file.  This wouldmake translations easier and would mean that you wouldn't have those problems with unicode formatting, etc.  You could also have it more dynamic, like what as wanted in Adding labels to a window via script.

---

I already proposed this on the previous page, and I still think that it'd be helpful if we could do something likely. Whether it's a string, an XML Node, I don't care. But we really need a way to get control over the XML before we open the window. There are just too many things we can't change in runtime yet, and thus we need to use crappy workarounds.

To give an example... in Countdown Live 2.0, I wanted to use a MenuButtonControl for the "Extra", "Insert tag" and "Insert countdown" buttons. Because I couldn't modify those in runtime, I was forced to dig into the Win32 API again and write a workaround by using "regular" pop-up menus. These menus are positioned underneath the button and pop up when the button is clicked. Of course, this works great, but it would be lots easier if I could have just used some kind of method like PlusWnd::MenuButton_SetMenu(Control, MenuXML) or something. Just a method to change the window XML before loading will do also!

It has been a while since this thread was bumped and I didn't feel like making my own, new thread, so here goes.

I first wrote about this idea in markee's reply to Compatibility with Messenger 2009 Beta but it wasn't acknowledged.  I seriously think that it can't be too much effort for script developers to now have control over the colour of toasts and adding their own images to where the DP normally sits.  It would be very nice to have this ability so that toasts were easier to recognise if they were coming from a particular script.  Admittedly, I would love the ability to use my own plus window (even if we had to use the exact same dimensions), but I guess that would be asking a bit much when there are many other more valid features to be added first that are all scattered throughout this thread.

Commands like (!VER) sent to scripts before being parsed by Plus!?

quote:

---

Originally posted by SmokingCookie
Commands like (!VER) sent to scripts before being parsed by Plus!?

---

Already is the case... however the problem I noticed is that either custom emoticons and or normal emoticons don't show because you intercept the message then return it and they disappear if I am not mistaken. I will have to do some more testing with this.