Get the position of the control in the Windows openfile dialog - windows

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.

Related

Does XUL support different modality scopes?

Is it possible to create a dialog using XUL (specifically in Firefox) that is:
Always-on-top but does not blocking user interaction with a page
and/or
Only tab modal, not window modal
?
You can surely have a non blocking Dialog, but it will go to the background when you click the window. For reference see this:
window.openDialog("chrome://membees/content/dialog.xul",
"","centerscreen=yes, all=no, titlebar=yes, chrome=yes, toolbar=yes,
dialog=no, resizable=no,modal=no","");
But if you want a bit more of control you can create a panel instead, and take advantage of the level property:
level
Specifies whether the panel appears on top of all windows, or just on
top of the window the panel is in. If this attribute is not set, the
popup window level depends on the platform. On Linux, the default
value is top, otherwise, the default value is parent. If a panel has
one or more text fields, this attribute should not be set, otherwise
IME or on-screen keyboard popups will appear incorrectly. For these
reasons, you should avoid setting the level if not needed.
top
The panel is shown in front of all other normal windows, including those of other applications.
parent
The panel is shown just above the window the panel is in, but behind
other windows above it. If anchored, the child window maintains its
relative position to its parent window.
floating
The panel floats above the window the panel is in. On Mac, the panel
is only visible when the application is active.
To create it you have to add it to the base element <popupset> in your overlay, and then you open it with:
openPopup(anchor,position,x,y,isContextMenu,attributesOverride,triggerEvent )

How to add more than 254 Controls in vb6?

I'm working with VB6 and I have one form with multiple tab controls.
When I drag and drop any control in form it shows me this error:
VB6 has a limited number of named controls per form. To add more controls, you can use a control array. That means, give some related controls the same name, then you can access them by name and index number. So instead of OptionAlways, OptionMaybe, and OptionNever, you could have Option(0), Option(1), and Option(2).
Also, if your dialog is very complex and most of its features are rarely needed, consider moving some options to additional dialogs behind an [Advanced...] button.

Group dialog items to a single "Group" (Visual Studio)

I want to create a dialog window for change settings of an application. Below is a screenshot of Adobe Reader. After using Spy++, I guess that:
On the right side, all the control (buttons, combo boxes...ect) are belonged to a GroupBox.
For each category in the TreeView Control on the left side, there is a corresponding GroupBox which groups all the controls related to this category.
When users choose between different categories, it hides one GroupBox and shows another one GroupBox.
But in the source code (xxx.rc, resource file) below, I didn't see anywhere where I can specify the "parent" of a dialog item.
Even I open xxx.rc with "Resource View" (not viewed as codes), I can't find any option to specify the parent of a dialog item in its property page.
I would like to know how to assign a parent (which is a GroupBox in my case) to a dialog item, or group dialog items to a single group,in the .rc file, i.e when one create the dialog items. (I guess one can do so by modifying the .rc file.)
GROUPBOX "View",IDC_SECTION_VIEW,101,6,228,88
LTEXT "Default &Layout:",IDC_DEFAULT_LAYOUT_LABEL,107,19,108,9
COMBOBOX IDC_DEFAULT_LAYOUT,215,17,108,64,CBS_DROPDOWNLIST | WS_TABSTOP
LTEXT "Default &Zoom:",IDC_DEFAULT_ZOOM_LABEL,107,36,108,9
COMBOBOX IDC_DEFAULT_ZOOM,215,34,108,149,CBS_DROPDOWN | WS_TABSTOP
CONTROL "Show the &bookmarks sidebar when available",IDC_DEFAULT_SHOW_TOC,
"Button",BS_AUTOCHECKBOX | WS_TABSTOP,107,53,216,9
...
...
...
I would like to know how to assign a parent...
SetParent Windows API. You supply HWND of your control and the handle of the supposed new parent.
In resource script, the controls will be children of the dialog itself, but on runtime you are free to change this and group them into a hierarchy of your interest.
You might also want to consider putting the supposed child groups into separate dialog template and have it as "composite control" - to be instantiated separately and be a child of a higher level dialog.
UPD. Have a look at this simple project (C++/ATL): AtlChildDialog. In particular, at main dialog's WM_INITIDIALOG handler:
ATLVERIFY(m_ChildDialog.Create(m_hWnd, (LPARAM) this));
ATLVERIFY(m_ChildDialog.MoveWindow(50, 50, 200, 150));
m_ChildDialog.m_EditWindow.SetWindowText(_T("Some Text"));
m_ChildDialog.ShowWindow(SW_SHOWNORMAL);
m_ChildDialog.SetFocus();
All together on runtime:

PropertySheet with a TreeView (using WinAPI)

In my WinAPI program I use PropertySheet for a settings dialog box. I use property sheet with pages (tabs), i.e. I use PSH_PROPSHEETPAGE flag. But the software now have too many parameters for such a type of property sheet. So I want to use PropertySheet with treeview: the treeview on the left and the page with paramerets for the currently selected item in the treeview - on the right.
How can I do this? Can my current property sheet be modified for this and how?
(using only WinAPI, no MFC)
Standard property sheet is no longer good enough for you, so you basically have two choices here. You can either design a window (modal or modeless, dialog based or not) to host all your controls in a single view, with tree view, possibly tab control as well, and showing/hiding elements to follow tree view selection. And you will move all your controls into this window.
Or instead, you can create a similar window which hosts property pages. On tree selection change you will switch property pages as if they are selected by tabs in standard property sheet. The point is that you can use your existing pages intact making this new settings windows imitating behavior of standard property sheet. This is perhaps a more complicated thing to do, but should be flexible enough to do once and accept various pages, and you don't also need to touch your existing pages code leaving it good for both standard and this custom sheet with a tree.
Both ways assume you need to do quite some work since you are giving up using a standard piece of code - the property sheet window.

How to place a windowless control on top of a windows control?

Say, I have an Image control (which seems to be a window-less control) and I want to make sure that it is on top of a TextBox. No matter what I do, the Image control will not appear on top of the Text box.
Is there a way?
P.S. I know I can use a PictureBox, but it does not support transparency, thus I must have the Image control.
There is no way to place an image control over a normal textbox as they are drawn onto the form itself so will always be below any other windowed components.
If you have VB6 installation media there are drawn (windowless) versions of controls including a TextBox you can use that will (probably) do what you want; http://support.microsoft.com/kb/184687
A custom usercontrol of some kind if probably better .. what is it exactly you want to overlay the textbox with?
The Image Control is considered a graphical control, like shapes, so it is always inferior to text controls. If you really want a transparent image, you can use a Microsoft 2.0 Form instead(only if you have it). Images there can be on top of textboxes, and you can make it transparent by setting the Backstyle to Transparent(0).
Completely different approach to my other answer (hence the seperate Answer), but you can set AutRedraw and ClipControls on your Form to false and it will allow the Image control to render on the same layer as a windowed control. You can get some flakey redrawing in some cases but for a quick solution you could try it.
http://msdn.microsoft.com/en-us/library/aa733621(v=vs.60)
I've created a tranparent overlay control to add a kind of annotation layer on top of a VB6 app. I'll attempt to describe it from memory, and if that doesn't provide enough information then you can post back and I'll try to dig up the code.
First, add a new USerControl to you application. Give it a name like ImageEx, PictureEx, or TransparntImage. There are several properties that you will need to use. Ensure the control is Windowed, so it can sit on top of other windowed controls. Locate the MaskColor property and set it to Cyan (or whatever color you elect to use to indicate a tranparent area. There might be an addition property enable the masking behavior, just browse the properties. Set the control background color to that of the MaskColor. At this point you have an invisible control. In my control I painted on top of the surface for annotations, but you can PaintPicture or maybe even set the image property for a really simple approach.
Of course, to make this a re-usable control, you will want to code in your own properties that allow the MaskColor and image, etc to be set so that you can the drop one of these on any form you want.
Some links:
MaskColor Property
MackPicture Property
1) Remove all your textboxes , labels and ... (But memorize their name and location in the form)
2) Go to (project > components) and mark the (Microsoft Forms 2.0 Object Library) then click ok
3) Now you can see new controls under your default controls in your toolbox...
4) Use its textbox and label controls instead of the default controls
5) Right click on your Image Control then click (Bring To Front)

Resources