locked
How to have command bar combo box update text without pressing enter RRS feed

  • Question

  • In the Visual Studio toolbar find combo box, you can enter text and tab out or click away and it'll retain the current text.  I have a combo box that I've added to a custom toolbar, if I type into it and tab out or click away, it'll revert back to what I had previously, which is the value it had the last time I typed something and pressed enter.  How can I make my combo box have the same behavior as the find combo box?  Is it in how I implement IOleCommandTarget for the combo box?  Do I need to define the FilterKeys flag in the .vsct file?  If so, what do I do to implement the filter keys callback?  Or is there something else?
    Thursday, September 22, 2011 9:08 PM

Answers

  • >Do I need to define the FilterKeys flag in the .vsct file?

    This.

    The contract is that your Exec will be called with your combo's command ID and a non-null in paramter which will be an array of 5 objects that looks like this

    [0] = HWND (int, it will always be 0 as we have no HWND for the combo's edit box, this was non-null in 2008 before we were using WPF)

    [1] = the filterkeys message (int)

    [2] = the wParam of the windows message

    [3] = the lParam of the windows message

    [4] = the current text in the control area

    The incoming filterkeys message value will be one of the values here and it will indicate what kind of action is occuring.

    Basically what the find dialog does is remember the text when it gets FilterKeysMessage_LostFocus and stores it internally so that the next time we ask for the display text it returns that text.  It returns VSFILTERKEYS_DODEFAULT in the out param of its Exec call to indicate to the shell that it should do whatever it was planning to do, there are other return codes here that allow you to change what happens in various situations, but you probably only need VSFILTERKEYS_DODEFAULT.

    Ryan

    Friday, September 23, 2011 4:49 AM

All replies

  • >Do I need to define the FilterKeys flag in the .vsct file?

    This.

    The contract is that your Exec will be called with your combo's command ID and a non-null in paramter which will be an array of 5 objects that looks like this

    [0] = HWND (int, it will always be 0 as we have no HWND for the combo's edit box, this was non-null in 2008 before we were using WPF)

    [1] = the filterkeys message (int)

    [2] = the wParam of the windows message

    [3] = the lParam of the windows message

    [4] = the current text in the control area

    The incoming filterkeys message value will be one of the values here and it will indicate what kind of action is occuring.

    Basically what the find dialog does is remember the text when it gets FilterKeysMessage_LostFocus and stores it internally so that the next time we ask for the display text it returns that text.  It returns VSFILTERKEYS_DODEFAULT in the out param of its Exec call to indicate to the shell that it should do whatever it was planning to do, there are other return codes here that allow you to change what happens in various situations, but you probably only need VSFILTERKEYS_DODEFAULT.

    Ryan

    Friday, September 23, 2011 4:49 AM
  • Thanks Ryan, that helps a lot.  I was looking for an interface to implement for the callback, I would never have guessed how to do these steps via IOleCommandTarget.Exec.
    Friday, September 23, 2011 2:39 PM
  • Yes, we have overloaded IOleCommandTarget to do a number of things (like fetching the display text for a combo via Exec as well). The decision to do so long predated my time on the team and I personally think it was, in retrospect, a bad idea.  That said it was likely made because the routing logic in VS is very much written to deal with IOleCommandTarget.  FilterKeys routes like any other QS/Exec type request. To get that same routing behavior without using IOleCommandTarget would have meant either abstracting the routing code to know nothing about the target interface of the items in the route or what to do with each item(the routing code is rather complex, and rather old :)) or duplicating the entire routing logic in a DoFilterKeysStuff kind of method.  In the face of that kind of decision the most expedient thing to do is to try and find a way to make the functionality you want 'fit' into what the code already does.

    Ryan

    Friday, September 23, 2011 3:19 PM