Problem with CComboBox::GetCurSel()

acerunner316

I'm running a thread that constantly checks GetCurSel() to make a comparison. The problem occurs when I click the arrow on the droplist and move the mouse over selections. Before actually clicking to select something, the GetCurSel() seems to be returning the value that the mouse is highlighting. Is that correct? Shouldn't GetCurSel() return the actual value selected? How can I solve this?

Zac Howland

acerunner316 wrote:

I'm running a thread that constantly checks GetCurSel() to make a comparison. The problem occurs when I click the arrow on the droplist and move the mouse over selections. Before actually clicking to select something, the GetCurSel() seems to be returning the value that the mouse is highlighting. Is that correct? Shouldn't GetCurSel() return the actual value selected? How can I solve this?

Polling the GUI constantly is probably not what you want to do. Instead, try caching the value you need to compare within your thread and create an even for it to check on each interval to see if he needs to update its value. When you change the selection in the ComboBox, trigger the event. Alternatively, you could also create a variable that is shared between the GUI thread and the other thread and set its value when there is a new selecting in the combo box. You will need to use Critical Sections for either of these solutions, though.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

Michael Dunn

If you just need to know when the selection changes, you should handle CBN_SELCHANGE - no need to do something as complex as a polling thread.

--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

David Crow

acerunner316 wrote:

I'm running a thread that constantly checks GetCurSel()...

Does this thread own the UI control? Only the owning thread, which is usually the primary thread, should be interacting with the UI controls.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

acerunner316

what do you mean "own the UI control"? The thread begins on initialization of the window. And runs continuously with a sleep(10). Anyways, I've already tooks Zac's advice and stored a variable. That's what I was going to do, but that involved changing a lot of code, so i was hoping there was another way to do it. It's probably the best way though.

David Crow

acerunner316 wrote:

what do you mean "own the UI control"?

UI controls (e.g., buttons, listboxes) are owned by a thread, usually the primary thread. Folks new to multi-threaded programming often make the mistake of having secondary threads communicate directly (e.g., SendMessage()) with those UI controls. Nasty things happen as a result.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

Zac Howland

acerunner316 wrote:

what do you mean "own the UI control"? The thread begins on initialization of the window.

When a control is created, it is created within the context of a thread (usually the main thread is the only one that deals with UI stuff -- with VERY rare exceptions).

acerunner316 wrote:

And runs continuously with a sleep(10).

As a side note, anytime you are calling Sleep, you really need to take a closer look at your design. You should almost never have to call that function. See below for a better solution.

acerunner316 wrote:

Anyways, I've already tooks Zac's advice and stored a variable.

Make sure you wrap any reads/writes to that variable with Critical Sections (in both the UI and worker threads). Also, to eliminate the need for the thread to be constantly running (and calling Sleep, add an event that you will signal after changing the variable in the UI thread. In the worker thread, call WaitForSingleObject on that event.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

Steve Echols

If the item's in your list are unique, you could work around this using: CString value; m_combo.GetWindowText( value ); m_combo.FindStringExact(-1, value ); Or you could cache the selected index in a member variable in your SelChange handler. I'd probably go with option 2.

- S 50 cups of coffee and you know it's on!