Possible messages bug with 3.1

[Ron]

Yes please use Postmessage!!! A deadlock will occur other wise. Do my examples tell you to use SendMessage ?

[Ron]

Sorry!! I got confused with the hardware plugin side. Let me think about this problem for a while.

<font size=-1>[ This Message was edited by: RonB on 2002-03-11 13:53 ]</font>

[Ron]

I've tested beta9 with the alarmtimer plugin that uses the same SendMessage function as you reported earlier and this one works without a problem... There must be something else in play... did you by any chance link to a group that links to itselfs ( never ending loop ?)

[Ron]

I have no idea what is cause this, but if the postmessage solves this please use postmessage.

[Ron]

I'll look into this as soon as the current rewrite work is completed. At this point many some of the routines have been rewritten including some that take care of event processing. So things might be different already.

[mattwire]

OSDMenu has been causing the latest beta9 to freeze when minimised, with the trayicon staying on. If girder window visible there is no problem. Here is the line which causes the problem:
If Curcommand.lValue2 <> 0 then SendMessage(SupportFunctions.targetHWND, WM_USER+1024,0, integer(Curcommand.lvalue2));

If I change it to PostMessage then all is ok.
This message is sent as my menu is closing, it only seems to freeze when using girder to send a keypress to the menu.

<font size=-1>[ This Message was edited by: mattwire on 2002-03-11 00:32 ]</font>

[mattwire]

You sent me the code example to execute a command, using sendmessage.
Also, all your examples seem to use sendmessage.
When should I use PostMessage and when should I use SendMessage?
-SendMessage for updating my window/PostMessage for girder?

[mattwire]

No, it doesn't matter what command I tell it to execute. It only occurs when the menu is closing - the onOpen Command works fine with sendmessage. This is what happens when it closes:
procedure DoQuit;
begin
if oldfont <> 0 then SelectObject(htxDC, oldfont);
if htxfont <> 0 then DeleteObject(htxfont);
if htxDC <> 0 then ReleaseDC(hOSDWindow, htxDC);
if hOSDWindow <> 0 then DestroyWindow(hOSDWindow);
hOSDWindow:=0;
{ PROBLEM LINE NEXT! }
If Curcommand.lValue2 <> 0 then SendMessage(SupportFunctions.targetHWND, WM_USER+1024,0, integer(Curcommand.lvalue2));
PostQuitMessage(0);
end;

[mattwire]

Just to reiterate, it is only deadlocking when Girder is used to send keypresses to the menu. If I use the mouse directly on the menu there is no problem.
I press a key which triggers girder to send 'Enter' to my menu. My menu executes girder: 'girder -eventstring app_digiguide_on' and quits, sending the OnMenuEnd command to girder. The only difference with the mouse is that girder is not sending a keypress to the menu.

[mattwire]

Ok, I'll stick to PostMessage. I wonder though, whether girder is getting 'overloaded' and that is causing it to deadlock?
Of course it could just be my coding...