Rif.: Catch WM_DEVICECHANGE sent by a DLL through my application handle

[Daniel Coelho]

Hi.

I'm using a DLL that manages an USB device and after detecting the event DEVICEARRIVAL, sends me the message WM_DEVICECHANGE to notice me that I have to do some actions.
"This function initialises the USB DLL. It registers the USB device notification in the operating system. The

operating system sends now a WM_DEVICECHANGE message to hHandle."

I give the DLL my application handle in order to receive the windows message:
"hHandle - Handle to application that handles USB device events."

How do I catch this message sent from the DLL through my application handle?

Hope I was clear.
Thank you.

[RobertoBozzolo · Accepted solution]

Not exactly sure if this is the correct answer, not even if you will succeed in using it (I've tried in the past to use this command with unsatisfactory results but I found another way to do wat I wanted so I leave this way aside...): I suppose you can use RegisterWinMsgCallback to register a callback to be executed when this message is sent to your application.

An alternative is to use InstallWinMsgCallback from the Programmer's Toolbox, as shown in \samples\toolbox\msgdemo.prj example.

As always when dealing with SDK, be sure to use a robust error handling system when using these functions!

[Daniel Coelho]

What kind of error handling are you refering to?

I've already tried InstallWinMsgCallback and I managed to receive the window message, but I don't understand of I'm receiving the message from the OS or if it is the DLL sending me the message.

What I understand from the DLLs documentation is that the DLL will send to my application the window message.

So how can I tell that the window message I receive is from the OS when the USB device is connected or if it is from the DLL?

Maybe I'm confusing things.

[RobertoBozzolo]

---

"This function initialises the USB DLL. It registers the USB device notification in the operating system. The

operating system sends now a WM_DEVICECHANGE message to hHandle."

---

As far as I can understand you have an initialising function that activates DLL functions and registers it in the system. That message exists only after all this has been done ("...the operating system sends now...").

You could try plugging the device without initialising the DLL and verifying if you receive the message or not.

In any case this seems a mechanism that is specific to the hw/sw you are using: you will need to refer to device documentation and/or producer support to clarify your doublts.

And you will absolutely need to use all error signals the interface offers to you: function return values, global error flags and so on. Be sure also to investigate on error causes if there are functions for getting more details, as normally these informations are useful to debug your code.

[Daniel Coelho]

That is why I ask, whenever I turn on/off the device I receive the WM_DEVICECHANGE even if the DLL isn't initialized.

That is why I can't tell if I'm receiving the WM from the DLL.

Could it be a problem of the Window Handle I'm sending to the DLL?

HANDLE hHandle;int postHandle = 0;

InstallWinMsgCallback (panelHandle, WM_DEVICECHANGE, UsbCallback, VAL_MODE_INTERCEPT, NULL, &postHandle);
hHandle=(HWND)postHandle;

USB_Init(HANDLE, hHandle, LPVOID (*pCallback)(UINT, UINT LPVOID), CHAR* sPath)
(USB_Init)(hHandle, &Callback, sPath);

[RobertoBozzolo]

Oh well, I may be wrong but it seems to me that you will never receive messages from the DLL directly! As far as I can understand, the purpose of init function is to make the system aware of the new device, so that it can route the correct messages. This information is inside the OS, no on the CVI side. If for some reason the CVI handle does not change from one execution to the othe, you will receive messages event before the init function has executed if this operation has been done previously.

I repeat: I may be wrong as I don't know the device you are working on, but if I am right you should not receive the messages if you make a try after a system reboot and before running the init function.

[Daniel Coelho]

It worked the other way arround.

If first I plug the device and power it on, wait a couple of seconds and then make the Init() function, I receive the propor action/eventss through the Callback() function I've passed to Init().

If I first call the Init() and then plug the device, I receive the WM_DEVICECHANGE but no actions are sent to my Callback.

So I've concluded that the InstallWinMsgCallback() works properly but not all the time!

Am I missing something?

By the way, the device I'm using is a radio witch comunicates through USB bus and has a proprietary DLL for communication.

[Daniel Coelho]

Not sure about InstallWinMsgCallback() not working, the function may work properly, because I receive the WM.

I'm thinking about the wParam and the lParam and maybe the data isn't passed as aspected to the DLL.

Let me explain:

I have to call another Dll function, DeviceEvent(wParam, lParam) when the WM_DEVICECHANGE occurs,

and in fact, when the device is turned on, 3 WM occur and the DeviceEvent() is called 3 times, when I power down the device the same happens 2 times.

When I call Init(hWHND, &Callback, sPath), I expect a WM_DEVICECHANGE, then the DLL sends information to my Callback saying "Connected".

If the InstallWinMsgCallback() works and I don't get the "Connected" information on my callback, I have to assume that when I called DeviceEvent(), the wParam and lParam weren't passed correctly and the DLL can't connect to the device.

Is it possible what I've suggested above?

[RobertoBozzolo]

Daniel, we are coming into device spevific details I don't know. The fact that sometimes the mechanism is working should indicate that there is no basic error in the code (I'd expect that if lparam or wparam is incorrect, it is always incorrect: if sometimes it is working the problem may be in other parts). But I have really no elements to tell what can be wrong in this situation.

[DanielCoelho]

I understand what your're saying and I appreciate your effort,

I'm just trying to expose ideias and see if any o them seems sounds like the source of the problem or solution.

In fact, I was wrong when I said that it worked sometimes. It looked like it worked!

I built the same ideia in a VC++ application that already had the WindowsProc() function in the new project template and I just added the case for the WM_DEVICECHANGE message.

This VC++ code worked how it is expected to work, so I still believe that CVI implements the message handling in a different way.

Thanks for your time, Roberto 😉

I'll try to work around this thing if I can't see a solution.