Locking up with ComboBoxEx

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Been having a heck of a time with ComboBoxEx32 windows. Now an issue has shown up in our app when one of our dialogs has an instance of that control AND the user moves another window. We have a "normal" paradigm in code where we perform a "TrackMove" which essentially captures the mouse in a loop and where we call while( GetMessage(&msg, nullptr, WM_PAINT, WM_PAINT, PM_REMOVE) ) { DispatchMessage(&msg); }

The issue is that we never leave the GetMessage loop. The ComboBoxEx32 window just keeps getting WM_PAINT messages. The app locks up. I have verified this stream of messages are different (time stamp shows that).

It appears that either the object's rect is never validated or something in the skinning code is causing paint messages to be sent.

I can turn skinning off when a dialog with a ComboBoxEx32 is created (assuming I always know when that might happen, which I don't in reality due to third party code) to avoid the issue.

I can also add a call to ValidateRect in the GetMessage loop to avoid the issue. That's what I'm busy doing now to all the code where we have such code.

Another issue that showed up is that another window we create and show doesn't completely paint. That's independent of the lockup unless I try to drag that window in which case it paints and we lock up. To fix that update issue I have to find where we calls ShowWindow and follow it up with UpdateWindow. I have found that the OnPaint message for this window isn't called. Only the background paints unless I call UpdateWindow.

Also, the lockup occurs whether I add a ComboBox synonym for ComboBoxEx32 which I posted about to fix another drawing issue where the background color of the the ComboBoxEx32 uses a skin color but the text does not.

A ComboBoxEx32 has a ComboBox child window. Perhaps this is the root of the issues we are having with ComboBoxEx32 windows. The ComboBox child window also uses owner draw.

Why hasn't CodeJock implemented a skin class specific to ComboBoxEx32? Is there some other way to work around these issues with the extended combobox?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 915	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: Locking up with ComboBoxEx Posted: Yesterday at 4:33pm
	Been having a heck of a time with ComboBoxEx32 windows. Now an issue has shown up in our app when one of our dialogs has an instance of that control AND the user moves another window. We have a "normal" paradigm in code where we perform a "TrackMove" which essentially captures the mouse in a loop and where we call while( GetMessage(&msg, nullptr, WM_PAINT, WM_PAINT, PM_REMOVE) ) { DispatchMessage(&msg); } The issue is that we never leave the GetMessage loop. The ComboBoxEx32 window just keeps getting WM_PAINT messages. The app locks up. I have verified this stream of messages are different (time stamp shows that). It appears that either the object's rect is never validated or something in the skinning code is causing paint messages to be sent. I can turn skinning off when a dialog with a ComboBoxEx32 is created (assuming I always know when that might happen, which I don't in reality due to third party code) to avoid the issue. I can also add a call to ValidateRect in the GetMessage loop to avoid the issue. That's what I'm busy doing now to all the code where we have such code. Another issue that showed up is that another window we create and show doesn't completely paint. That's independent of the lockup unless I try to drag that window in which case it paints and we lock up. To fix that update issue I have to find where we calls ShowWindow and follow it up with UpdateWindow. I have found that the OnPaint message for this window isn't called. Only the background paints unless I call UpdateWindow. Also, the lockup occurs whether I add a ComboBox synonym for ComboBoxEx32 which I posted about to fix another drawing issue where the background color of the the ComboBoxEx32 uses a skin color but the text does not. A ComboBoxEx32 has a ComboBox child window. Perhaps this is the root of the issues we are having with ComboBoxEx32 windows. The ComboBox child window also uses owner draw. Why hasn't CodeJock implemented a skin class specific to ComboBoxEx32? Is there some other way to work around these issues with the extended combobox?

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 915	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 5 hours 42 minutes ago at 10:50am
	This just keeps getting worse. I was forced to call UpdateWindow for another window that we display when our pane with the extended combobox is visible. Now on further testing I happened to go to the ribbon and click a tab and the ribbon won't update its display either. I have to click the ribbon to get it to update. I'm inserting a video showing the issue. The video shows our docking pane window with the extended combobox we use that handles WM_DRAWITEM since the CJ skinning code only manages to draw the dark background for the box but not the light text. The video shows me clicking ribbon tabs and then having to click the ribbon in an empty area before the ribbon updates. I would like to note that even if I don't use our custom draw comboboxex this display issue with the ribbon remains. uploads/3213/NonUpdatingRibbon.zip