Community
Participate
Working Groups
it doesn't exist a method to open the popup of the combo (like a setPopupVisible(true)in the JCombobox of swing)
It could be useful to implement dynamic positioning in the droppeddown combo while typing text (like the address combo of Internet Explorer for example). Anyway there should be a mean to dropdown the combo when using only the keyboard.
As a workaround, this utility class may help (win32 users): import org.eclipse.swt.internal.win32.OS; import org.eclipse.swt.widgets.Combo; public class Util { public void showPopup(Combo combo, boolean show) { if (!combo.isDisposed()) { OS.SendMessage(combo.handle, OS.CB_SHOWDROPDOWN, show ? 1 : 0, 0); } } public boolean isPopupShowing(Combo combo) { boolean result = false; if (!combo.isDisposed()) { result = (OS.SendMessage(combo.handle, OS.CB_GETDROPPEDSTATE, 0, 0) != 0); } return result; } }
*** Bug 75688 has been marked as a duplicate of this bug. ***
This is low priority. It isn't needed by Eclipse and the capability is not available on all platforms so we can't really offer the API. I'm not sure how an application is supposed to use it (ie. what is "dynamic positioning while typing text").
I would really like to see this added. I would like to add the ability to my commercial software for the user to type text into the combo box, by which triggers the combo box to open. My idea, is that the combo box is searchable. Meaning that if it contains identification numbers in accending order, that the user may type in a number which triggers the opening of the combo box. I have the functionality written so that it will scroll the list, but am finding it difficult to trigger the dropdown to open when text is typed into the combo.
Ok, I understand.
CCombo has an internal method called "dropDown" -- can this be made public? It's pretty useful to be able to programmatically drop down a combo box. I'm using a ComboBoxCellEditor in a GEF-based editor and want the combo to drop down right away when the cell editor is activated. This will eliminate an extra mouse click and make it easier to use.
(In reply to comment #5) > I would really like to see this added. I would like to add the ability to my > commercial software for the user to type text into the combo box, by which > triggers the combo box to open. > My idea, is that the combo box is searchable. Meaning that if it contains > identification numbers in accending order, that the user may type in a number > which triggers the opening of the combo box. > I have the functionality written so that it will scroll the list, but am > finding it difficult to trigger the dropdown to open when text is typed into > the combo. Hello, so do I make a solution, but as you I have a problem with the dropdown. Moreover, my solution have problem with the last release of Eclipse 3.1RC3 Can you help me with this problem Thanks Stefano
Since there is no API to do this on the Mac (implemented with HIComboBox or CreatePopupButtonControl()), we can't really offer the API, other than as a hint.
(In reply to comment #2) > As a workaround, this utility class may help (win32 users): It seems my mouse cursor disappears if I do this work around. Until the combo box list is closed. Any work arounds for the workaround? Thanks
(In reply to comment #5) > I would really like to see this added. I would like to add the ability to my > commercial software for the user to type text into the combo box, by which > triggers the combo box to open. > My idea, is that the combo box is searchable. Meaning that if it contains > identification numbers in accending order, that the user may type in a number > which triggers the opening of the combo box. > I have the functionality written so that it will scroll the list, but am > finding it difficult to trigger the dropdown to open when text is typed into > the combo. I have a separate button (w/ icon) that when pressed I'd like to show the Combo popup. I would like it to do exactly as the JComboBox.showPopup() works
It seems that OS X 10.4 has added the API HIComboBoxSetListVisible() (ASIDE: also they added API to find out when an item is selected so we can get rid of the horrible hack in Display). SSQ, we should consider adding this API providing that GTK and Motif can do it. I'm thinking: setListVisible(boolean); getListVisible();
regarding comment 1, on windows you can press F4 or ALT+DOWN_ARROW to show the combo box. While you guys are investigating cross-platform combo functionality, could you also look into notification for the dropdown being shown and hidden. This affects many clients that currently suffer a large delay when handling a selection change event.
In the current 3.3 M4 build I see for Windows and GTK you have added asetListVisible method but it is not public. Any idea when it will be?
Still haven't investigated GTK, Motif and Photon. Since M5 is supposed to be an API freeze, assuming the investigation was successful, we need approval from the PMC to add API.
(In reply to comment #15) > Still haven't investigated GTK, Motif and Photon. Since M5 is supposed to be > an API freeze, assuming the investigation was successful, we need approval from > the PMC to add API. > On GTK this is already implemented since some time at least M4 has a method named setListVisible() which is package scoped. Now that M6 is passed would you mind adding at least a package visible method to MacOSX?
I added the method. Note that I don't know how to drop down a read only combo (one created with CreatePopupButtonControl()) on the Mac.
Are there any updates on this issue? We really need to control read-only combo's drop-down list programmatically on mac. Plus, can't understand why the setListVisible method has package access?
The use case I ran into for needing to know if the drop down is visible is I have added a org.eclipse.jface.fieldassist.ContentProposalAdapter to my read/write org.eclipse.swt.widgets.Combo and set the keystroke param and auto activation chars to null so whenever the user typed anything the proposals would display. However, if the combo box has been expanded prior to typing, once the user begins to type the proposals display on top of the combo dropped down and the focus is kept on the drop down rather than the proposals. It clutters the screen and user could become confused. So my end result is that I wanted to know if the combo list is visible, disable the org.eclipse.jface.fieldassist.SimpleContentProposalProvider and interact with the combo list. I had hoped the API would handle this case gracefully but if not, it would sure be nice to be able to handle this programmatically through a listener that is fired when the list is expanded. So I知 asking for an additional enhancement to this bug to be able to catch when the list is displayed and closed.
Steve, can you use HIViewSimulateClick on the popup menu? That seems to be what you're trying to accomplish.
Guy F. says: "HIViewSimulateClick with kControlPopupButtonPart is indeed the correct way to programmatically open the popup menu." This might answer your question about how to programmatically drop down a top level menu item.
Created attachment 84594 [details] Patch for Mac OS X version of setListVisible for read-only Combo Here's a change to Combo that handles making a read-only popup visible. The change is as I described, but kControlPopupButtonPart is not exposed in any header. It's not exactly a magic value, however.
A google search for kControlPopupButtonPart gives nothing, making it magic ... but I don't care. Does the code work with "0" instead of "1". Did you test the patch? It looks good providing that simulate click doesn't send any fake mouse events, which from reading the doc, is shouldn't. We also need to implement Combo.getListVisible() but I have code around somewhere that checks to see whether a menu is open and that code should work fine.
I have released the HIComboBoxIsListVisible() native into HEAD.
... and /*public*/ boolean getListVisible() for Combo.
Created attachment 84693 [details] Simple test for Combo.setListVisible() Here's a test case. I'm going to modify the patch a bit because currently it shows the popup regardless of the state of the visible parameter. The other problem is that once visible, any click elsewhere in the window hides the list, and I don't think that behavior is controllable.
Created attachment 84694 [details] Patch that tests 'visible' before setting list visible Slightly better patch. Previous version didn't check for 'visible' first, so the list always gets shown.
There is also a few cross-platform issues that we need to think about. For example, if the combo box is hidden, disabled or zero size, does the list still show?
(In reply to comment #25) > ... and /*public*/ boolean getListVisible() for Combo. why was the changed checked in at package level rather than public? If the change was public this would help my use case where I need to know if the list is visible or not when the user begins to type in the combo box. In addition, what was the thought on a way to catch via a listener when the list is opened and closed?
(In reply to comment #29) > In addition, what was the thought on a way to catch via a listener when the list is opened > and closed? This is a good question; reading through the other comments, I can see where this might be useful. In Carbon we could get the menu handle and listen for kEventMenuOpening and kEventMenuClosed. Cocoa will fire a NSPopUpButtonWillPopUpNotification, but I don't see a matching close notification.
> why was the changed checked in at package level rather than public? While working on the API way back when, carbon didn't support the API. We can't make a method public on one platform and not on another. The /*public*/ is used to release the code and save the work in progress. Normally, we don't do this for space reasons but the amount of code is small.
I have the code everywhere but cocoa. Scott, got code?
Fixed > 20071207 Bogdan, my Linux machine is very old. I'll need to test the code on your machine monday. Duong, fix bug 119057 right away so that CCombo matches Combo for the next M-release. There is a patch. Be sure to update the Javadoc and the @since field.
Steve, does this need a contributed tag?
Nope. Scott is a committer.
