Shoutbox

I just got a nice idea for a feature! What do you think about creating a Plus! window based on an actual string instead of creating it based on a file name? That way, we could first load the XML in the script, make some changes and then create the window, like this:

code:

---

var txt = new ActiveXObject("Scripting.FileSystemObject").GetFile(MsgPlus.ScriptFilesPath + "\\Windows.xml").OpenAsTextStream(1, -1).ReadAll();
txt = txt.replace("helol", "hello");
var PlusWnd = MsgPlus.CreateWndFromString(txt, "WndPref");

---

Or, another thing: creating a window based on a XML DOM node object, like:

code:

---

var node = xml.selectSingleNode("//Window[@Id='WndPref']");
var PlusWnd = MsgPlus.CreateWndFromNode(node);

---

Both of these examples could save CPU usage because you don't need to re-save the file since you just send it right to the Plus! Scripting API, and it lets developers make some routine changes to the XML before creating the window, making translating windows a lot easier and faster. Well, what do you think?

It could have its uses I guess (although I don't know any which could be shorter than the normal method). eg: Not for translating as that could be done a lot easier and shorter by simply altering the controls' caption.

quote:

---

Originally posted by CookieRevised
It could have its uses I guess (although I don't know any which could be shorter than the normal method). eg: Not for translating as that could be done a lot easier and shorter by simply altering the controls' caption.

---

The problem is you can only translate controls in this way, elements cant be translated. So a better suggestion would be some sort of PlusWnd.SetElementText() method to make translation easier.

The ability to preview your PSM in colour?

eg with your name when you add colour you can see it but your psm displays the colour codes.

I agree with Mattike. And the great thing is not only to translate controls or reduce CPU... the great thing is that you can create a window with dynamic controls, ie: when developing the script, the developer may not know how many buttons his window should show. But in run time, the script can create a XML code that includes as many buttons as they're needed and then show the window.

quote:

---

Originally posted by Ashylay
The ability to preview your PSM in colour?

eg with your name when you add colour you can see it but your psm displays the colour codes.

---

1. This is not related to scripts.
2. PSM is displayed in color, if you add yourself to your own contact list.
3. The PSM space below the nice cannot show the PSM colored as Patchou still hasn't found a way on how to do it .

quote:

---

Originally posted by Felu
[
3. The PSM space below the nice cannot show the PSM colored as Patchou still hasn't found a way on how to do it .

---

I don't think that's the case, I'm sure I remember him saying it's not done on purpose for some reason or another.  Or I may be lying, I can't remember.

quote:

---

Originally posted by Eljay
The problem is you can only translate controls in this way, elements cant be translated. So a better suggestion would be some sort of PlusWnd.SetElementText() method to make translation easier.

---

And you can't translate MenuButtonControl menu's, <Help> tags (luckily there's the _ToolTip class which I use for that), and translating the Caption using SetWindowTextW has the disadvantage that it forces Plus! to add a Plus! styled TitleBar to the window, even if the XML doesn't specify one. And I guess that Plus! has to load the file contents in a string itself too, so why can't we just send the string straight to the API?

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.

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.