Microsoft KB Archive/276042

= BUG: Click and Change Events Do Not Fire For ImageComboBox Control in WFC Form =

Article ID: 276042

Article Last Modified on 6/14/2006

-

APPLIES TO


 * Microsoft Visual J++ 6.0 Standard Edition
 * Microsoft Java Virtual Machine

-



This article was previously published under Q276042



SYMPTOMS
When you host the Microsoft ImageComboBox ActiveX control in a Windows Foundation Classes for Java (WFC) Form, the Click and Change events are not fired.



CAUSE
The control messages are not handled for the events that are fired.



RESOLUTION
To work around this problem, override the wndProc method of the AxHost subclass for the ImageComboBox control, and handle the control messages that are required to produce these missing events.



STATUS
Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.



MORE INFORMATION
The Microsoft ImageComboBox ActiveX control and the Microsoft ImageList ActiveX control are ActiveX wrappers for the Windows common controls of the same names. The WFC ImageList control is a WFC wrapper for the Windows common control. When you use the ImageComboBox ActiveX control, you should also use the ImageList ActiveX control, not the WFC ImageList control, for the image collection object that is associated with the combo box.

The Visual J++ designer uses the AxHost class as a base class for ActiveX controls that are imported into the environment through the toolbox. The ImageCombo.java file is generated for the ImageComboBox control, and the ImageCombo class in this file is a subclass of com.ms.wfc.ui.AxHost. The AxHost class wraps the underlying ActiveX control in a WFC control for easier use with the Visual J++ designer and the WFC framework. You may notice that some standard or common ActiveX properties and events overlap those of a standard WFC control. In these cases, the ActiveX bridging code is dropped, and the standard WFC control framework takes over.

Workaround for Click and Change Events
A possible workaround for the event problem is to subclass the AxHost window and add functionality for the firing of the Click and Change events. To do this, override the wndProc method of the ImageCombo class, and handle the common control windows messages as desired.

The following code sample illustrates how to add to the default ImageCombo wndProc implementation to produce the missing events. Note that common control message IDs are contained in the high-order word of wParam; the low-order word is not used in this sample. For more information, see the Microsoft Developer Network (MSDN) documentation on CBN_XXX messages at the following Web site:

http://msdn.microsoft.com/library/psdk/winui/combobox_7icz.htm

// Workaround for Click and Change events /* #define CBN_ERRSPACE        (-1) #define CBN_SELCHANGE      1 #define CBN_DBLCLK         2 #define CBN_SETFOCUS       3 #define CBN_KILLFOCUS      4 #define CBN_EDITCHANGE     5 #define CBN_EDITUPDATE     6 #define CBN_DROPDOWN       7 #define CBN_CLOSEUP        8 #define CBN_SELENDOK       9 #define CBN_SELENDCANCEL   10 */  boolean selectQueued = false; public static final int FALSE = 0; public static final int TRUE = 1; protected void wndProc( Message m ) { switch (m.wParam >> 16) { case winc.CBN_SELCHANGE: // If we are a dropdownlist style, fire click now; // otherwise, wait until the CBN_EDITCHANGE message. if (this.getStyle(winc.CBS_DROPDOWNLIST)) { this._jcommem_eventmulticaster1.Click; m.result = FALSE; }     else selectQueued = true; break; case winc.CBN_EDITCHANGE: // Because we don't want to fire both a Click and a Change // event when the user selects an item from the list (so     // we can emulate what the intrinsic VB combobox does), // fire the click event now (instead of in response to     // the CBN_SELCHANGE message) but only if we have a      // CBN_SELCHANGE message queued. //      if (selectQueued) { selectQueued = false; this._jcommem_eventmulticaster1.Click; }     else this._jcommem_eventmulticaster1.Change;

m.result = FALSE; break; }   super.wndProc(m); }

