SetPanelAttribute crashes USB device detection

[richferrara]

I am developing an application for LabWindows 2010 that reads and writes to/from a hardware board via a USB connection.  The program initializes the interface on startup by calling InstallWinMsgCallback to detect any WM_DEVICECHANGE messages sent to the main panel.  The callback receives the WM_DEVICECHANGE message and detects whether power has been turned on or off to the board by looking for wParam == DBT_DEVICEARRIVAL (power on) or DBT_DEVICEREMOVECOMPLETE (power off).  The device information in lParam is used to configure the board.  The callback also receives WM_DEVICECHANGE messages with wParam == DBT_DEVNODES_CHANGED but ignores these.

Our application can be controlled either by the user or from an "automation" server program.  When automation is turned on, the application disables input to the main panel.

The problem I'm seeing is that when certain attributes of the main panel are set to false (including ATTR_MOVABLE and ATTR_CLOSE_ITEM_VISIBLE), the USB interface crashes.  The crash is indicated by a different message being posted to the callback with a message ID of 1004 (hex 3EC), even though InstallWinMsgCallback was never called with this message ID.  Once the crash happens, the program no longer detects when power to the board is turned on or off.  The callback will still receive DBT_DEVNODES_CHANGED messages when the board is powered on or off, but not DBT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE.

I have looked for information on the meaning of the 1004 error code on various websites that list WM_xxx message opcodes, but this code isn't listed.  I've also noticed that after the crash, the program will still continue to process all messages for other USB devices -- for example, if I plug a portable USB drive into a port on the PC.  Only the detection of the hardware board is affected.

Does anyone have an idea what could be causing this?

Rich Ferrara

[jallen88]

Rich,
Could you provide some more information about the hardware: USB interface, board manufacturer and model, etc?

Also, have you tried using different USB ports (front and back of the computer) to see if this is isolated to just a particular port?

If you call SetPanelAttribute before or after the InstallWinMsgCallback, does this change the behavior at all? Just to clarify, the program operates correctly unless you call SetPanelAttribute with ATTR_MOVABLE and ATTR_CLOSE_ITEM_VISIBLE.

Is there any other information included with the '1004' message?

[richferrara]

Jared,

Our program interfaces with two different boards.  Both are made in-house.  The vendor ID code is 0x04B4 and the product ID codes are 0x1004 and 0x57E1.  (I'm guessing the "1004" value is a coincidence, since the vendor ID is hex and the 1004 I saw in the Windows message number is decimal.)  The USB connections are the standard type A on the PC and type B on the boards.

I tried switching the boards to connect to different ports on the PC with the same results.

When I added a SetPanelAttribute call to the program initialization to set the main panel to be non-movable and non-closeable before calling InstallWinMsgCallback (or when I changed the default panel settings in the UIR file), the USB interface didn't crash when I turned automation on -- but it did crash when I then turned it back off.  So it appears that it's not the fact that the attributes are set to false that's causing the crash; it's the act of changing them.

I found that changing the ATTR_SIZABLE attribute has the same effect, and there may be more.  But there are other panel attributes that don't cause any problems (including ATTR_DIMMED, ATTR_VISIBLE, and ATTR_TITLE).

The first time I got the 1004 message in the callback, wParam was set to 0x00040322.  After that, I got another 1004 message every time I changed the automation setting.  Each time, the upper 16 bits of wParam incremented by 1 while the lower 16 bits remained 0x0322.  Since I can't find any information about the message, I don't know what those bits mean.

Rich 

[jallen88]

Rich,
What is the specific method call(s) you are making to InstallWinMsgCallback()?

Is it possible for you to attach a code snippet?

[richferrara]

I am attaching two files.  USBConnection.c contains the code that initializes the USB interface and the callback function that is being called by InstallWinMsgCallback.  GuiInhibitUtility.c contains the common routine that we call when turning the automation function on.  It is called for our application's main panel using PostDeferredCall.  We are running on Windows 7 Ultimate, in case that helps.

Rich

[jallen88 · Accepted solution]

Rich,
After looking at your code, I believe that the error may be related to calling InstallWinMsgCallback() and then manipulating the panel that the message callback is linked to.

If you manipulate the panel by changing its attributes, I believe you must call RemoveWinMsgCallback() to remove the handler, and then call InstallWinMsgCallback() to re-enable it. Please try modifying the code to remove and install the callback when manipulating the window appearance.

This may not apply to you, but in the function documentation for InstallWinMsgCallback(), it states that "A message callback cannot be installed for a LabWindows/CVI child panel."

[richferrara]

Removing and reinstalling the Windows message callback eliminated the 1004 message when turning automation on and off, but it did not change the other effects.  The boards are still not being detected when powered on and off.  It appears that this code change did not fix the error, it only removed the notification of the error.

[richferrara]

I figured out another way around the problem: Since I'm not actually using the panel handle parameter in the Windows message callback, I can create a blank panel and direct InstallWinMsgCallback to send the Windows messages to this panel instead.  Then when we turn automation on, I don't have to disable this panel since it's never actually displayed.  The USB connection stays up.

Thanks for the help, your posts helped me solve the problem!

[jallen88]

Rich,

Glad to help! Your workaround is something I would not have even considered. Good work sir!