Sending message from control dll

[msmith]

I have my first <compiler generated> dll controll working fine.

I decided to add additional functionality to include sending mouse information messages (events).

The following code is in the WM_RBUTTTONDOWN event processing code:

Code Select Expand


OBM_MOUSE equ 28672
...
proc !ControlProc,hwnd,wmsg,wparam,lparam
...
mov eax,6
mov [_ArgSafe0],eax
mov eax, dword [hwnd]
invoke SendMessage, dword [ControlParentTemp],OBM_MOUSE,[_ArgSafe0],eax


I believe that the MASM syntax would be something like:

Code Select Expand


OBM_MOUSE equ 28672
...
proc ControlProc,hwnd,wmsg,wparam,lparam
...
mov eax,6
mov _ArgSafe0,eax
mov eax, hwnd
invoke SendMessage, ControlParentTemp,OBM_MOUSE,_ArgSafe0,eax


Any program using the dll with this code in the dll crashes with an exception error.

I use almost identical code to send a WMCOMMAND message for "click" and it works fine.

I get the error even though the right mouse button was not pressed and the calling program ignores the event.

Can anyone see what the problem is?

[zooba]

Possibly stack or register corruption. Make sure that ESI, EDI, EBX, ESP and EBP are the same before and after the SendMessage command.

If this isn't it, we'll probably need to see a bit more code (specifically, the code which selects the message to send and the procedure which receives it).

Cheers,

Zooba :U

[msmith]

Hi zooba,

The code that selects it is simply a case statement with WM_RBUTTONDOWN.

I removed all of the code that receives it so that it will fall throught to the default window procedure.

The WM_COMMAND message that words fine is virually identical.

Could the problem have something to do with RegisterWindowMessage

[zooba]

Possibly, though I would've thought a problem like that would return an error code, rather than cause an exception. Your code below seems to be passing a constant though, so that may be the issue.

According to MSDN, you pass RegisterWindowMessage a string containing the (unique) name of the message, and then you use the return value as the message. You need to RegisterWindowMessage the same name in each app/DLL, store the return value and use that as the message wherever you've got OBM_MOUSE.

[msmith]

zooba,

You may be right. It seemed strange to me that RegisterWindowMessage requires a string.

Also, from the clieint side, it seems to be no problem to "make up" message numbers and just use them with no problem. I check for these message numbers in the dll (server) and process them with no problem. An example would be OBM_SETBACKCOLOR (0400h) as well as several others. The WM_USER docs only require the number to be in a certain range.

Going the other direction (server to client) is where the problem shows up.

I may just resort to the WM_NOTIFY message, although I don't like the way it works with required structure etc. A hard way to do an easy thing.

Also, WM_RBUTTONDOWN and all of its cousins are no good for this because they contain no hwnd arg.

As always, thanks for your advice.

Mike

[zooba]

The messages from WM_USER - 07FFFh can be used freely internally, though some controls use these messages already.

RegisterWindowMessage returns a message from 0C000h - 0FFFFh which is guaranteed to be unique throughout the whole system. It seems quite easy to use:

Code Select Expand

.data
    sOBM_MOUSE    BYTE    "OBM_MOUSE",0
    OBM_MOUSE     DWORD   0

.code
    invoke RegisterWindowMessage, OFFSET sOBM_MOUSE
    mov    OBM_MOUSE, eax

Then as long as you remember that OBM_MOUSE is a memory location rather than a constant (so you can only compare it with a register now) you're fine. And you can do whatever you like with the dwParam and lParam parameters :U

[msmith]

I have to register it in both the exe and dll don't I?

[zooba]

Yep. The first call will find a unique value and assign it to the name. The second call will find the name and return the value associated.

[msmith]

zooba,

I was doing something wrong yesterday because OBM_MOUSE now works fine.

I had ripped out all of the related code last night because it was causing exception errors.

I put it all back in tonight to make sure it still behaved the same. I was going to then implement RegisterWindowMessage like we discussed.

Here is the code I put back in tonight:

Code Select Expand


; LN:171 SENDMESSAGE ControlParentTemp,OBM_MOUSE,6,hwnd
mov eax,6
mov [_ArgSafe0],eax
mov eax, dword [hwnd]
invoke SendMessage, dword [ControlParentTemp],OBM_MOUSE,[_ArgSafe0],eax


I don't see any difference with this code and the original code I posted last night.

There must have been a typing error elsewhere that was logically incorrect and syntactically correct.

So, at least for the time being, I don't need RegisterWindowMessage after all.

The way it works is fairly nice because I can get an event for:

1 MOUSEENTER
2 MOUSELEAVE
3 MOUSEMOVE
4 MOUSELBUTTONDOWN
5 MOUSELBUTTONUP
6 MOUSERBUTTONDOWN
7 MOUSERBUTTONUP

The (sub)event number is returned in wparam while the control's handle is returned in lparam.

This allows a lot of possibilities like holding a button down and doing doing something as long as it is down.

It works independently and concurrently with the regular command and click events.

I will use this event in all of my controls (where it makes sense). This particular control is a button that has background and foreground colors, text, bitmap, and sound. It also has an optional flat style so that it is flat until the mouse hovers at which time it "inflates".

Thanks again for the help.

Mike