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).
/ 
