I have now only come to realize the issue with WM_PAINT message being captured. If you register the WM_PAINT message and don't return it to the window, it actually will prevent WLM from repainting as well.

To test this theory import the script, open a conversation window, click the Enable button on the Scripts window then try typing you will notice no characters appear until you click the Disable button.

How come patchy does the script capture WM_PAINT from other windows aside from its own? Is this an issue with the script engine and that specific message?

I realize this is in the Scripting Docs

quote:

---

Originally posted by Scripting Docs

Remarks
In case of doubt, always return -1 to make sure the message is properly received and interpreted by the window. Preventing standard system messages (like WM_PAINT) to be processed by the window can have disastrous effects.

---

in WM_PAINT ytou need to call stuff like BeginPaint() if you don't want to break Windows.

code:

---

function OnTestWndEvent_MessageNotification(oPlusWnd, nMessage, wParam, lParam){
    switch (nMessage) {
        case 0xf /* WM_PAINT */:
            var PAINTSTRUCT = Interop.Allocate(64);
            Interop.Call('user32', 'BeginPaint', oPlusWnd.Handle, PAINTSTRUCT);
            return repaint ? -1 : 1;
            break;
    }
}

---

When you click on the conversation window, it will normally trigger a WM_PAINT on the previously focussed window, which is the Plus! interface window because it needs to be repainted too since it goes from having the focus to a non-focussed window.
If you return 1 at that point, the window can't be repainted and the whole 'changing focus' routine can't be performed and blocks all the rest.

Something like that?

Use Spy++ or the likes to monitor WM_PAINT messages in normal circumstances to see what I mean.

I'm not saying this is or isn't a bug in Plus!. Though, I think it isn't and this is just how Windows works and shows that one should be very carefull with hooking messages as there can be far going consequences... eg: some stuff depends on some other stuff which depends on some messages being recieved which depends on WM_PAINT; a whole cascade of events. Pulling one element out of the chain and the whole thing stops working...

EDIT: above written without refreshing thread (so I didn't saw reply of Patchou yet)

quote:

---

Originally posted by matty

Not to be rude, but this seems as more of a work around does it not?

---

Ok I understand the sequence now makes a lot more sence, merci cookie wookie!