Shoutbox

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.

---

However none of the other Messages are processed on a Process Wide basis (it seems).

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;
    }
}

---

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

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?

---

No, it is how Windows works. See MSDN library.

As I suspected, painting a window requires a whole set of things to do, which on their turn depend on what messages are recieved. So breaking one thing in the chain and nothing happens at all.

Since WM_PAINT is blocked from executing in the Plus! interface window. The whole repainting procedure of that window never finishes and thus it also doesn't send out a new WM_PAINT to the new focussed window. Hence the convo window isn't repainted. If you use Spy++ you will also notice that Windows constantly tries to repaint the Plus! window (WM_PAINT is constantly send in a loop), but it constantly fails (because you trapped the WMP_PAINT message of the Plus! window from finishing).

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