Combo-box behavior bugs

[Alex Korchemniy]

I am using a combo box in the commandbar...

I only receive a change event when a user presses enter or tab. If a user
types in text in the combo and moves to the next combo using the mouse the
text the user just entered in the first combo disappears. What is the work
around for this? Is it at least possible to get the window handle of the
underlying combo so I can subclass it?

Another problem... how do I correctly use a combobox with multiple
documents. For some reason the combo box seems to be shared across multiple
documents.

Alex Korchemniy

 

[Helmut Obertanner]

Hello Alex,

1. this is the default behaviour for the Forms 2.0 ComboBox
i had no Idea how to subclass it - sorry.
Maybe someone knows a workaround.

2. Add a unique Tag to your ComboBox e.g. Document.GetHashcode();
So you can assign the Button to your Document.

Hope this helps,

regards,
--
Helmut Obertanner
Technical Consultant
Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich

.... and IT works!

 

[Alex Korchemniy]

1. I'm not sure what forms 2.0 has to do with ms office commandbar... but I
dont think I'll be able to do from the automation model. I'll need a way to
subclass the combo.

2. I again don't see how that is useful. My problem is this... when Word
start I sink the events for the combo. In a new document the event for the
combo (Change) does not work! Also... when I try to use the values from the
combo they get pulled from the first documents combo.

AK

 

[Helmut Obertanner]

Hello Alex,

The Office.ComboBox is a Forms2.0 Control as I know.

could you show us the code how you creating your combobox for each document ?

regards
--
Helmut Obertanner
Technical Consultant
Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich

.... and IT works!

 

[Alex Korchemniy]

Im doing pure ATL COM... and I create the combo in IDTExtensibility2
OnConnection

// Add the bar item
CComPtr <MSOffice::CommandBarControl> spBarItemField;
CComVariant vToolBarType(4); // MsoControlType::msoControlComboBox
CComVariant vShow(VARIANT_TRUE);
spBarItemField = spBarControls->Add(vToolBarType,vEmpty,vEmpty,vEmpty,vShow);
ATLASSERT(spBarItemField);

// Query for combo
CComQIPtr <MSOffice::_CommandBarComboBox> spComboField(spBarItemField);
ATLASSERT(spComboField);
m_spComboField = spComboField;

// Set some properties
spComboField->PutVisible(VARIANT_TRUE);
spComboField->PutCaption(L"PAField");
spComboField->PutEnabled(VARIANT_TRUE);
spComboField->PutTooltipText(L"PAField");
spComboField->PutTag(L"PAField");
spComboField->PutDropDownWidth(200);
spComboField->PutWidth(200);

 

[Alex]

Hello Alex,

I am using a combo box in the commandbar...

I only receive a change event when a user presses enter or tab. If a user
types in text in the combo and moves to the next combo using the mouse the
text the user just entered in the first combo disappears.

That's how all Office combo-boxes work.
Try it with Word's built-in "font" or "style" combo-boxes.

What is the work
around for this? Is it at least possible to get the window handle of the
underlying combo so I can subclass it?

Not that I know.

 

[Alex Korchemniy]

Yes, I know that its default behavior in Word. I can confirm that by typing a
font in the font combo and then attempting to select a font size... what I
typed will disappear.

Still... I need a solution. I have two combos: category and field. The user
types in a category and then immediately types in the field... then they
click on the add button. Advanced users will have no problem using the tab
key. However, novice users that use that are not accustomed to using the tab
key will report this as a bug.

A possible solution is to subclass the combo (or the combos edit window) and
when focus leaves the window I save the text... overriding MS's default to
erase the text. I just need to get the window handle.

 

[Helmut Obertanner]

Hello Alex,

well, I'm not a C++ programmer, but i can read your code.

The problem with multiple documents is a general problem.
I tried it with a C# AddIn.

when you create the CommandBar in OnConnection Method,
the comboBox is created once when Word loads your addin.
So I created a DocumentWrapper that is created when a document is opened
that holds a reference to the created document.
I created the ComboBox in Document.CommandBars not in Application.CommandBars.
But the problem was still the same.
So I havn't tried, but my next step would be to register for the ComboBox
event everytime when a documentwindow is activated and unregister when it's
deactivated.

When I have time I will try it, you could try it too.


regards,
--
Helmut Obertanner
Technical Consultant
Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich

.... and IT works!

 

[Alex Korchemniy]

I still do not have a solution for the strange behavoir of comboboxes. I've
tried sinking events for documents, when a new document is encountered I
create an instance of my class CDocWrapper, create a document specif combo
and buttons and sink events for those. The problems only get worse.

Maybe someone from MSFT can help?

 

[roxanaio]

I have some similar problem, in Outlook 2003 and not found a
solution yet.
I created an add-in in C# and added a CommandBarComboBox control on the
toolbar. I defined a Change event handler for this control and it fires
randomly. Sometimes only the first time I change the text in the combo
and sometimes the second time too. But no more then this.

My code looks like this:

CommandBarComboBox filterButton = (CommandBarComboBox)
patBar.Controls.Add(MsoControlType.msoControlComboBox,
Missing.Value,.Missing.Value,Missing.Value,Missing.Value);
filterButton.AddItem("Find contact", 1);
filterButton.ListHeaderCount = 1; filterButton.ListIndex =
1; filterButton.Width =
150; _CommandBarComboBoxEvents_ChangeEventHandler oEditHandler = new
_CommandBarComboBoxEvents_ChangeEventHandler(filterButton_Change); filterButton.Style
=
Microsoft.Office.Core.MsoComboStyle.msoComboNormal; filterButton.Change
+= oEditHandler;
nextOneStartsGroup = true; filterButton.Parameter =
buttonInfo.SearchFilter;

Tell me please if you found a solution for your problem or have any
idea about mine.

Thanks.

 

[Helmut Obertanner]

Hello roxanaio,

i have posted a small example how to deal with buttons and Comboboxes in
Outlook here:

http://www.outlookcode.com/codedetail.aspx?id=789

if the commandbar is in a Inspector have a look here:

http://www.outlookcode.com/codedetail.aspx?id=797


maybe it is usefull to you.
--
Helmut Obertanner
Technical Consultant
Softwaredevelopment
DATALOG Software AG | Zschokkestr. 36 | D-80687 Munich

.... and IT works!

 

[Alex Korchemniy]

Frustrated with 97 support and these problems, I had my partner port
everything to VBA. I had exactly the same problem in VBA. The problem at its
core seems to be this: the first instance is what is always going to be used,
word doesn't automatically handle multiple documents for you. When the
document changes you have to find the control again and reattach events.

 

[roxanaio]

I solved the problem very simple... Seems like GC collects the object I
declared localy (in the method used to create all the controls in the
toolbar) and used when creating the combo: filterButton, although the
combo continues to appear in the toolbar and the item can be found
between the controls collection in the CommandBar object.
I declared a hashtable stored globally in the addin for all my controls
in the toolbar and added them after creation. This way, the events work
just fine. My code is the same, but in the end added this line:

m_globalHash.Add(someKey, filterButton)

I never use the hash in my code for any other reason, but simply store
it.

 

[David]

Did this solution work for ATL/C++ ?
David

I solved the problem very simple... Seems like GC collects the object I
declared localy (in the method used to create all the controls in the
toolbar) and used when creating the combo: filterButton, although the
combo continues to appear in the toolbar and the item can be found
between the controls collection in the CommandBar object.
I declared a hashtable stored globally in the addin for all my controls
in the toolbar and added them after creation. This way, the events work
just fine. My code is the same, but in the end added this line:

m_globalHash.Add(someKey, filterButton)

I never use the hash in my code for any other reason, but simply store
it.