Is there a way to make combobox be dropping up instead of down?
I have answered that Q but it's in Delphi (the code is not so hard to understand though):
Can I programmatically set the position of ComboBox dropdown list?
You need to subclass the ComboBox hwndList (You obtain that handle via GetComboBoxInfo API) using SetWindowLong (GWL_WNDPROC) and handle WM_MOVE message to place that hwndList in a new position.
Not with the standard Windows combo boxes (Here are the available styles for combo boxes).
As #ILMV said, Windows will drop the box up instead of down if there is not enough space below the box.
You can test this with notepad - go to format -> font, and drag the box down so that the Script combo box is just above the start menu. Click the combo box - it drops up.
If you want it to always drop up, you'll have to make your own.
Related
I noticed that whole area around check box is clickable.
Is this a intentional functionality or a GUI bug? Problem is that user don't expect that if they click outside check box that value in chack box is changed.
It is intended that the user may click on the label. But clicking on the white space right of the label should actually not change the value. We will look into this.
It is different for list boxes: Because list boxes support selection as well, we decided to make only the check box clickable instead of the whole row to prevent the user from accidentally change the checked state if he just wants to select / focus a row.
I want a user to be able to select item(s) in my CListCtrl and then click on a button to act on those items. But when the focus is lost from the list, the selection is no longer shown, even if I set 'Always show selection' to true:
This happens both in the dialog test facility, and in my compiled application. I use list-mode, and have no icons, only text.
To reproduce:
Create a new dialog in the resource editor
Place a list-view control.
Set View = List in the properties
Set Always Show Selection = True in the properties
Add a button to the dialog
Press Ctrl-T to test the dialog
Select item(s) on the list, then press the button
..and the text is not visibly selected at all. Or is it... I can just
barely sort of see some very very faint selection in my screenshot - I
think. It's so faint I am not 100% certain it's there!
In addition to my comments: well, there you have it - they are selected, and in a different color, but it seems your screen settings are a bit off. Maybe your color settings, a high contrast mode, or the color setting for selected items in Windows.
The gray color in your screenshot is: #f7f3f7 - light gray, so you might have a problem seeing it, depending on the settings.
An interesting and very lightweight tool to check those things (zoom in, see the color values) is ZoomPlus. I use it every day, and there seems to be source code available too.
I my application, I have added a dropdown box to the standard windows file open dialog. This works fine, but I would like to position this drop box exactly below the file name and file mask edit controls, and its label exactly below the labels for these controls.
How can I get the positions of these controls and the corresponding labels (it depends on the Windows version and maybe even on theming, so using the constants that make the dialog look fine on my computer won't do)?
On Vista+, you should be using the IFileDialog, IFileOpenDialog and IFileDialogCustomize interfaces:
Common Item Dialog
Customizing the Dialog
You can use the IFileDialogCustomize::AddText() and IFileDialogCustomize::AddComboBox() methods to add a drop-down list and its label to the dialog, and if needed use the IFileDialogControlEvents::OnItemSelected event to react to the user selecting items in your drop-down list.
However, you cannot decide where custom controls are displayed when customizing this dialog. UI layout is controlled by the dialog itself:
The Common Item Dialog implementation found in Windows Vista provides several advantages over the implementation provided in earlier versions:
...
•Enables simple customization of the dialog, such as setting the label on the OK button, without requiring a hook procedure.
•Supports more extensive customization of the dialog by the addition of a set of data-driven controls that operate without a Win32 dialog template. This customization scheme frees the calling process from UI layout. Since any changes to the dialog design continue to use this data model, the dialog implementation is not tied to the specific current version of the dialog.
...
The only layout access it provides is the order in which you add your custom controls, and any visual grouping. So, you could use IFileDialogCustomize::StartVisualGroup() to create a new group, then call AddText() and AddComboBox() (in that order) to add those controls to the group, and then finally call IFileDialogCustomize::EndVisualGroup().
On the other hand, when using GetOpenFileName() instead, there are some different options for customizing that dialog, and they allow you much finer grain control over the dialog's layout:
Customizing Common Dialog Boxes
Open and Save As Dialog Box Customization
The preferred option is to create a custom dialog box template and specify it in the OPENFILENAME structure. Within the template, you can have whatever controls and layout you want, and then the template can be inserted as a child of a standard Explorer-style dialog, or as a replacement for a standard Old-style dialog. MSDN documents how to custom-position a template within an Explorer-style dialog:
Explorer-Style Custom Templates
To make room for the new controls, the system expands the default dialog box by the width and height of the custom dialog box. By default, all controls from the custom dialog box are positioned below the controls in the default dialog box. However, you can override this default positioning by including a static text control in your custom dialog box template and assigning it the control identifier value of stc32. (This value is defined in the Dlgs.h header file.) In this case, the system uses the control as the point of reference for determining where to position the new controls. All new controls above and to the left of the stc32 control are positioned the same amount above and to the left of the controls in the default dialog box. New controls below and to the right of the stc32 control are positioned below and to the right of the default controls. In general, each new control is positioned so that it has the same position relative to the default controls as it had to the stc32 control. To make room for these new controls, the system adds space to the left, right, bottom, and top of the default dialog box as needed.
The alternative, without using a custom template, is to obtain the dialog's own HWND directly (which can be gotten inside a hook function assigned to the OPENFILENAME::lpfnHook field) and then you have full access to do whatever you want with the dialog. Microsoft assigned fixed control IDs to the standard controls of an Explorer-style dialog (so you must specify the OFN_EXPLORER flag for this approach to work), and those IDs are consistent across Windows versions. Those IDs are meant to be used with the CDM_SETCONTROLTEXT and CDM_HIDECONTROL messages, but they can also be used with GetDlgItem() to get the HWND of certain dialog controls, in this case the cmb13, edt1 and stc3 controls:
cmb13
Drop-down combo box that displays the name of the current file, allows the user to type the name of a file to open, and select a file that has been opened or saved recently. This is for earlier Explorer-compatible applications without hook or dialog template. Compare with edt1.
edt1
Edit control that displays the name of the current file, or allows the user to type the name of the file to open. Compare with cmb13.
stc3
Label for the cmb13 combo box and the edt1 edit control
Once you have those HWNDs, you can manually query their current positions and sizes, add your custom drop-down list underneath them as needed, and resize the dialog's HWND to accommodate your drop-down list.
Whether you use a template or direct HWND manipulation, you would need to use a dialog hook function to process messages from your drop-down list as needed, such as the CBN_SELCHANGE notification.
For some fun and self-education, I'm tinkering with writing my own X11 toolkit. Here's something that's stumping me.
I have a traditional combo box display element, a typical combo box with a dropdown popup list, like all popular toolkits have.
For the dropdown popup list, I'm creating a new window, a child of the root window, appropriately positioned below the main combo-box display element.
The dropdown popup list is a window in its own full right, that implements keyboard-based navigation, to select the individual entries in the dropdown list.
So, I'm using SetInputFocus to set the input focus to the popup after it opens.
What I find is that when I do that, the window manager then redraws the frame of the main window to indicate that it no longer has input focus. Which is technically true, but I don't see the same results with the more mainstream toolkits, where, in the comparable situation, the main window's frame shows that it still has input focus.
For the pop-up window, in addition to setting override-redirect, I'm also doing everything I can think of, to tell the window manager what's going on: setting the window group leader ID in the popup window's WM_HINTS, setting WM_TRANSIENT_FOR, and setting _NET_WM_WINDOW_TYPE to _NET_WM_WINDOW_TYPE_COMBO; none of that seems to work (I verified that the properties are approriately set, via xprop).
It seems like I have to keep the input focus in the combo box window, and forward keypress and keyrelease events to the display elements in the dropdown popup, which feels clunky. Am I overlooking some property that would tell the window manager that the popup's input focus is linked to the main window's (besides the ones that I've mentioned), that would keep the main window's frame drawn to show that it has input focus, when the input focus is actually in the popup?
Most X11 override-redirect exclusive popup windows (menus, combo boxes, ...) grab the keyboard and/or pointer with either passive or active grab.
See XGrabKey, XGrabKeyboard, XGrabButton, XGrabPointer in the X11 programming manual.
Or maybe don't, because the manual is totally unclear about what the heck these functions are and how they can be used. Search the interwebs for usage examples, probably in other widget libraries. Unfortunately I don't know of a simple informative example offhand.
It is not necessary to call XSetInputFocus at all because all keyboard and/or pointer events are reported to the grabbing clients.
I am working on a sample application to display combo box. i could display the combo box.
But i want to remove the combo box drop down arrow.
please let me know how to do this.
You can't do this without painting the control yourself. But there's no point to do that because a combo box that can't be dropped down is an edit box. Use one of those instead, perhaps supporting auto suggest.
even with all of the common control library's support for owner/custom drawing, getting rid of the combo box is difficult to impossible. most likely impossible.
i would not have even tried if there weren't significant complexities involved to switching to a different type of control...
just my experience, and in a past life i did owner-drawn toolbars and such all day long.