Hello. I was wondering if anyone had thought of making a jQuery-esque library for Messenger Plus! Live. I believe this would make it much easier and quicker to develop scripts, much like jQuery is for web dev.

For example, something like the following could be used as a simple googling script: (minus some parsing)

code:

---

$("ChatWnd").receiveMessage(
    function() {
        if(this.message.substr(0, 7) === "!google") {
            var wnd = this;
            $.get(
                "http://www.google.com?q=" + this.message.substr(9, this.message.length - 9),
                function(data) {
                    //parse data here
                    wnd.send(data);
                }
            );
        }
    }
);

---

code:

---

<Root>
    <ChatWnds>
        <ChatWnd>
            <Handle>{ json rep for HWND object, etc. }</Handle>
            <Contacts>
                <Contact>
                    <Blocked>false</Blocked>
                    <Email>lol@u.com</Email>
                    <Name>Amec</Name>
                    <PersonalMessage>Yo.</PersonalMessage>
                </Contact>
                <Contact>
                    <Blocked>false</Blocked>
                    <Email>lol@me.com</Email>
                    <Name>Yep</Name>
                    <PersonalMessage>Bro.</PersonalMessage>
                </Contact>
            </Contacts>
        </ChatWnd>
    </ChatWnds>
</Root>

---

I like the idea, but it'd be hard to implement I think. Then you either have to ship the file with every script that uses it giving you multiple copies on the same user's PC, or find a way to download it from an online source and execute it into the current script.

I've had a similar idea once, mainly because I would love to assign and remove event handlers like in jQuery (with bind() and unbind()).

However, if you would want to actually make such framework for Plus! scripts, you're going to need to find a way to create regular OnEvent_* functions in your script and mirror these to your framework. After some testing, I found that it was possible to create these in run-time by manually creating an extra script file and loading that with MsgPlus.LoadScriptFile. The problem is that you can't assign window event handlers without knowing their IDs to create OnWindowIdEvent_* handlers. To get these IDs, you'd need to ask the user of your framework to name all used windows in your script at initialization and whenever the user adds an extra window, he/she must remember to add it into the list.

One solution could be to ask for the paths to the interface XML files and collect all window IDs at initialization. The result of this scanning process could then be cached inside ScriptInfo.xml. The created script file with all mirrored events could be cached in a similar fashion. However these are all nasty workarounds, it is tough to do it right on top of the current scripting environment.

As for selecting objects with CSS-like queries, I don't think scripts would benefit from it that much. In the HTML DOM, it's good to have a selector engine since the current JavaScript functions aren't sufficient for modern scripts and there are many browser inconsistencies to overcome when crawling through the DOM. It's also a very logical way to select elements with CSS-like queries, since we're used to do that in CSS and thus we know exactly what we should expect.

I doubt this query language would make sense in Plus! scripting. Surely, you could have object types as tag names, attribute selectors and descendants, but why would you need all that? I think it's good to be able to plusQuerify an object and dynamically bind events on it, but why do you need to be able to select these objects like that? Most of the time, Plus! already gives you the object you need as event parameter, so just $(ChatWnd) should be enough.

quote:

---

Originally posted by Spunky
I like the idea, but it'd be hard to implement I think. Then you either have to ship the file with every script that uses it giving you multiple copies on the same user's PC, or find a way to download it from an online source and execute it into the current script.

---

quote:

---

Originally posted by Matti
...which really makes scripting easier

---

quote:

---

Originally posted by CookieRevised
... bigger, slower, more prone to errors, very hard to debug, beginning scripters don't even know what they actually are doing (and thus asking more questions as to why something doesn't work), etc....

---

lol really old post. So uhh... Since no one seemed interested, I decided to do this myself! Although, I did change it a lot from my original suggestion as I became a better ECMAScript "programmer"...

Source: https://github.com/tyscorp/plusquery/

Suggestions/additions/criticisms are welcome.

Edit: I guess I should have included more information...

Wrapper objects
It includes a set of "wrapper objects", which allow the interfaces to be extended. For example, you can overload ChatWnd.SendMessage to do other stuff...

Event Handling
It includes functions for binding/unbinding event listeners, to any plusQuery object. If it is bound to the main plusQuery object, it is always executed when the event is called. If it is bound to a plusQuery( * ) object, it is executed whenever the objects match.
So, if you bind "ChatWndSendMessage" to plusQuery, the function you specify will get called each time you send a message. If you bind it to a plusQuery(ChatWnd) object, the function is only called when you send a message from that ChatWnd object. (binding to instances is buggy atm. >_>)

Timers
It has setTimeout/setInterval/clearTimeout/clearInterval. Based on a mixture of mine and Matti's ideas.

Is also extends Object and Array a lot currently; I will be moving this to the plusQuery object. (except for the delicious Function.prototype.bind ;D)

The latest build is attached.

That is truly amazing!

Here's a suggestion: use combined getter/setter methods for the properties in the wrapper classes. Instead of storing this.original.Size in this.Size, make a method Size which can be called as a getter with Size() or as a setter with Size(newSize). Right now every wrapped property is read-only, although some properties should be read/write such as DataBloc.Size or Messenger.MyStatus.

Example:

js code:

---

$.wrappers.DataBloc.prototype = {
    Size: function (newSize) {
        if( typeof newSize !== "undefined" ) {
            this.original.Size = newSize;
        }
        return this.original.Size;
    }
}

---

This deserves its own thread though...

quote:

---

Originally posted by Matti
That is truly amazing!

---

quote:

---

Originally posted by Matti
Here's a suggestion: use combined getter/setter methods for the properties in the wrapper classes. Instead of storing this.original.Size in this.Size, make a method Size which can be called as a getter with Size() or as a setter with Size(newSize). Right now every wrapped property is read-only, although some properties should be read/write such as DataBloc.Size or Messenger.MyStatus.

---

quote:

---

Originally posted by Matti
Another thing I noticed is that you're extending Object.prototype. While this may work just fine in your library when using your version of Object.prototype.forEach, this surely will break a lot of scripts which iterate over plain objects using a standard for...in loop without the Object.prototype.hasOwnProperty check. I think it's better to simply drop the prototype extensions and only extend the static Object. This is not so much of an issue with the Array and String prototypes, as those should never be iterated over with for...in anyway.

---

quote:

---

Originally posted by Matti
The thing I miss is (of course) event binding on PlusWnd objects. If this were possible, we could write classes to work with window controls which can bind the necessary handlers to the used window events. Now, I understand that this is very tough to implement and would probably require a lot of hackish constructions. I found a way to inject function in the global object in run-time, but it's very, very ugly. Hopefully the event architecture gets fixed/improved in some future version of Plus!...

---

js code:

---

function OnMyWndEvent_Cancel(plusWnd) {
    $.trigger(plusWnd, "MyWndEvent_Cancel", plusQuery.$A(arguments));
}

$.addEventListener("MyWndEvent_Cancel", function (plusWnd) {
    //do stuff here
});

$.addEventListener("MyWndEvent_Cancel", function (plusWnd) {
    //do other stuff here
});

---

Simply amazing!

...oh hey. I just thought of something... It can be done using eval. (feeling kinda sick just by saying that)

js code:

---

var plusWnd = $(MsgPlus).CreateWnd("interface.xml", "yiew", 0);
//[...]
$.wrappers.MsgPlus.CreateWnd = function (XmlFile, WindowId, Options) {
    var toEval = "var On" + WindowId + "Event_Cancel = function (plusWnd) { $.trigger(plusWnd, '" + WindowId + "Event_Cancel', plusQuery.$A(arguments)); };";
    toEval += "var On" + WindowId + "Event_Destroyed = function (plusWnd, exitCode) { $.trigger(plusWnd, '" + WindowId + "Event_Destroyed', plusQuery.$A(arguments)); };";
    //etc
    (1, eval)(toEval); //indirect call to eval; makes it evaluate in the global scope
    this.original.CreateWnd(XmlFile, WindowId, Options);
}

---

The solution I came up with also uses eval() as there's no global object in JScript which stores the global variables. (In browser JavaScript, there's the global object "window" which holds the global scope.)
However, you'll have to do one extra thing to make it work...

When adding globals using eval() in run-time, the scripting engine will not register those added functions as event handlers. That is, if you add an OnWndIdEvent_Destroyed() event using eval(), it won't get called when the window is destroyed. The trick to get these registered is to use MsgPlus.LoadScriptFile(). When calling LoadScriptFile, the script file is loaded and the global scope is rescanned for event handlers. This results in the newly added functions to be properly registered.

Note that you don't need to trick eval() to be called in the global scope. By simply omitting the "var" keyword, the variable will be created in the global scope. It is generally a bad idea to omit the "var" keyword, but in this case it's sort of acceptable.

Proof of concept:

js code:

---

var plusWnd = $(MsgPlus).CreateWnd("interface.xml", "yiew", 0);
//[...]
$.wrappers.MsgPlus.CreateWnd = function (XmlFile, WindowId, Options) {
    var toEval = "On" + WindowId + "Event_Cancel = function (plusWnd) { $.trigger(plusWnd, '" + WindowId + "Event_Cancel', plusQuery.$A(arguments)); };";
    toEval += "On" + WindowId + "Event_Destroyed = function (plusWnd, exitCode) { $.trigger(plusWnd, '" + WindowId + "Event_Destroyed', plusQuery.$A(arguments)); };";
    //etc
    eval(toEval);
    $(MsgPlus).LoadScriptFile("_blank.js"); // black magic happens here

    this.original.CreateWnd(XmlFile, WindowId, Options);
}

---

quote:

---

Originally posted by Matti
there's no global object in JScript

---

quote:

---

Originally posted by Matti
Note that you don't need to trick eval() to be called in the global scope. By simply omitting the "var" keyword, the variable will be created in the global scope. It is generally a bad idea to omit the "var" keyword, but in this case it's sort of acceptable.

---

One thing I noticed

js code:

---

    $.addEventListener("ChatWndReceiveMessage", function (chatWnd, origin, message, msgKind) {
        if (msgKind === 1)
        {
            $.triggerCommand($(chatWnd), $(chatWnd.Contacts).GetContact(origin), message.split(' ')[0].toUpperCase(), message.split(' ').slice(1).join(' '), message, true);
        }
    });

---

JScript does have a global scope. In regular JScript (WSH) you can just do "var global = this" in global scope then access it anywhere.

It definitely worked at some point, but use of it was removed/broken by Plus! in an update to the scripting engine.
I'm sure there was a reason but I sure as hell can't remember it Maybe something to do with the event handling.

I know it worked because I made a script that allowed you to hook events or something like that, and my script broke

Edit: found it [Beta-ish Utility Release] Hook System
So it was broken at some point between 2006 and now, lol.

quote:

---

Originally posted by matty
One thing I noticed

You cannot obtain the Contact object by passing the origin parameter to the GetContact function.

---

js code:

---

$.wrappers.Contacts.prototype.extend({
    GetContact: function (str) {
        if (str.toLowerCase() === Messenger.MyEmail.toLowerCase()) {
            return this[0];
        } else if (this.original.GetContact(str)) {
            return $(this.original.GetContact(str));
        } else {
            for (var i = 0; i < this.length; i++) {
                if (this[i].Name === str) {
                    return this[i]; // Only returns the first match
                }
            }
        }

        return null;
    }
});

---

js code:

---

var match = /^\/([^ \n\r\v\xA0\/][^ \n\r\v\xA0]*)(?:[ \n\r\v\xA0]([\s\S]*))?$/.exec(message);
if ( match ) {
    var command = match[1]; // note: command will have no leading slash
    var parameters = match[2];

    var tmp = $.triggerCommand($(chatWnd), $.MyContact, command, parameters, message, false);
    return (tmp === undefined ? message : tmp);
}

---

js code:

---

var match = /^([^ \n\r\v\xA0]*)[ \n\r\v\xA0]?([\s\S]*)$/.exec(sMessage);
if ( match ) {
    var command = m[1]; // note: command will retain its leading character
    var parameters = m[2];

    $.triggerCommand($(chatWnd), $.MyContact, command, parameters, message, true);
}

---

quote:

---

Originally posted by Eljay
JScript does have a global scope. In regular JScript (WSH) you can just do "var global = this" in global scope then access it anywhere.

---

Ok I found when/why global scope was broken: Patchou's reply to 300 breaks NP script

It seems that when Patchou added the global enums (STATUS_BUSY, etc.), it broke the global scope

Offtopic sidenote:

quote:

---

Originally posted by Matti
The way I parse local commands is based upon Cookie's regular expression but instead of using the global RegExp object to retrieve the data, I use the result from exec() itself. It's better to use your local data rather than having to rely on global side effects.

---

quote:

---

Originally posted by Matti
Another thing I noticed is that you're extending Object.prototype.

---

quote:

---

Originally posted by Matti
Here's a suggestion: use combined getter/setter methods for the properties in the wrapper classes.

---

quote:

---

Originally posted by Matti
Also, the local command parsing should be a bit more sophisticated.

---

• Implemented dynamic function binding for PlusWnd events. Not sure if I'm going to do this, yet... I'll have to test a lot before I decide.
  
• Changed GetContact so you can't search by name. Haven't decided what I'm gonna do with this one... It's so simple with it there, but I'm aware of the pitfalls... Perhaps... ChatWnd.GetContactByName and ChatWnd.GetContactByEmail? Dunno.

quote:

---

Originally posted by Eljay
It seems that when Patchou added the global enums (STATUS_BUSY, etc.), it broke the global scope

---

quote:

---

Originally posted by CookieRevised
On topic, nice to see some advanced 'toying' (if I may use that word) with the scripting engine to create such a library and create such possebilities. But although I'm sure one could come up with an exotic use or examples for it, I must say, I can't see any real use of it in practice, certainly not for the average script and scripter, but also not for the more advanced scripts. But this said, again, great work .

---

Sure, but as for that specific example, that could be done in much easier ways too though I think (as in using a more straightforward library). So, maybe not the best example. But as long as you (and others) find it useful, then