I am using the Win32 API and MS Visual C++ 6 to build a tree view of a directory structure, with check boxes associated with each tree view item. My goal is to be able to check a parent folder, and have that automatically check all of its associated children.
However, after digging through MSDN, I have not been able to find a control notification message for an item being checked, only when an item is selected. I have considered using a selection notification message to prompt the program to poll the item and see if its current 'check state' is true, but I am not sure that checked and selected can be tied together in such a way, and am also concerned about the overhead associated with constantly polling items as a user moves through a very large directory.
Has anyone had experience setting up this scenario? Are my concerns about the overhead of polling a GUI element justified?
There isn't any notification. You can write your own, though. Just handle mouse click and use hittest to see if the mouse cursor is on the state image. For completeness handle the space key and send the same notification for the selected item too.
As of Windows Vista, Microsoft has introduced NM_TVSTATEIMAGECHANGING and a corresponding NMTVSTATEIMAGECHANGING structure. I'm not sure why this is not documented with the Tree View notifications but instead in the General Control Reference section.
This notification code is sent by the tree control when the state image is changing (i.e. when the check box is clicked).
The NMTVSTATEIMAGECHANGING struct has a iOldStateImageIndex and iNewStateImageIndex field that specifies the corresponding change. This information can be used to determine the new state image that will be displayed (1 is the unchecked box and 2 is the checked box)
Vista also introduces dimmed, partial and excluded checks though at the moment I'm not sure how those are represented by the state image index as the two base cases above.
Here is the best way by MSDN (TreeView::AfterCheck Event):
http://msdn.microsoft.com/en-us/library/system.windows.forms.treeview.aftercheck(v=vs.110).aspx
Related
I was using task manager to watch my dynamically created controls and found each time I'd create a TreeView with an ImageList, the GDI objects count would increase by 4 each time I destroyed the tree and created again. However, a ListView never had a problem.
I know of the TVS_CHECKBOXES issues with the state images and was already destroying of the state imagelist, but I then implemented:
ImageList_Destroy(TreeView_SetImageList(GetHandle(), nullptr, TVSIL_NORMAL));
and now the resource leak is gone.
So far it looks like you have to manually clean up images in WM_DESTROY for the following:
Button_SetImageList() - Have to set it to switch it to `BUTTON_IMAGELIST.himl=BCCL_NOGLYPH` to clear it.
TreeView_SetImageList(LVILS_STATE) - if you set it or used `TVS_CHECKBOXES`
TreeView_SetImageList(LVILS_NORMAL) - if you set it
BM_SETIMAGE and STM_SETIMAGE - destroy your own but also set to NULL and destroy returned handle to get rid of potential hidden bitmap handle if different handle than your own.
But a ListView is different, is that by design or should I just go ahead in WM_DESTROY with something like:
ImageList_Destroy(ListView_SetImageList(GetHandle(), nullptr, LVSIL_STATE));
ImageList_Destroy(ListView_SetImageList(GetHandle(), nullptr, LVSIL_SMALL));
ImageList_Destroy(ListView_SetImageList(GetHandle(), nullptr, LVSIL_NORMAL));
Note that using WM_NCDESTROY is too late for TreeViews.
The two controls are inconsistent in this regard.
The tree control does not take ownership of the imagelist you give it, so you remain responsible for freeing it.
The listview control does take ownership, unless you set the LVS_SHAREIMAGELISTS window style.
Note that the tree control also has a related quirk; if you set the TVS_CHECKBOXES style, you are responsible for freeing the state image list even though you didn't create it.
What you are seeing is documented behavior.
For a TreeView:
TVM_SETIMAGELIST message
TreeView_SetImageList macro
The tree-view control will not destroy the image list specified with this message. Your application must destroy the image list when it is no longer needed.
As well as:
Tree-View Control Window Styles
Constant
Description
TVS_CHECKBOXES
Version 4.70. Enables check boxes for items in a tree-view control. A check box is displayed only if an image is associated with the item. When set to this style, the control effectively uses DrawFrameControl to create and set a state image list containing two images. State image 1 is the unchecked box and state image 2 is the checked box. Setting the state image to zero removes the check box altogether. For more information, see Working with state image indexes.Version 5.80. Displays a check box even if no image is associated with the item. Once a tree-view control is created with this style, the style cannot be removed. Instead, you must destroy the control and create a new one in its place. Destroying the tree-view control does not destroy the check box state image list. You must destroy it explicitly. Get the handle to the state image list by sending the tree-view control a TVM_GETIMAGELIST message. Then destroy the image list with ImageList_Destroy.If you want to use this style, you must set the TVS_CHECKBOXES style with SetWindowLong after you create the treeview control, and before you populate the tree. Otherwise, the checkboxes might appear unchecked, depending on timing issues.
Compared to a ListView:
LVM_SETIMAGELIST message
ListView_SetImageList macro
The current image list will be destroyed when the list-view control is destroyed unless the LVS_SHAREIMAGELISTS style is set. If you use this message to replace one image list with another, your application must explicitly destroy all image lists other than the current one.
I am looking for a control many of us probably know, but I don't know it's name and don't have a real screenshot by hand, just this sketch:
In the left box one can select an operation or whatever, which then is moved to the right side. With the up/down arrows on the right, one can move this operation (or whatever kind of meaning the entry has) up or down in the order of execution.
How is this kind of control called? Or is it normally build by developers out of single controls? Is this control available in JavaFX 2? If not, I don't need exactly this control, but a control with the following features:
User can select multiple operations (duplicates allowed) out of all available operations
The user can arrange their order of execution
Thanks for any hint :-)
You need to use multiple controls to build up your interface. Use two ListViews with a MultipleSelectionModel for each (or at least the left one) and add a couple of buttons, that copy selected items from one list to the other and another couple of buttons which modify the position of selected items in the right list view by modifying the view's underlying item list.
listView.getSelectionModel().setSelectionMode(SelectionMode.MULTIPLE);
I have a project that I'm working on that has a TreeView Control in it. For everything underneath Level 1, those nodes are being used as a bookmark function, so we want a Tri-State CheckBox there. I found a control that I'm using here.
However, as the top two levels in the TreeView do not need bookmarking, the customer wants an Image there. I found this page who's response gets CheckBoxes to disappear on specific Nodes. Unfortunately, the API calls clash with the ones used in the above Tri-State TreeView and they both can't work at the same time.
Basically, what I'm looking for is how to get Images in nodes on the top two levels, and Tri-State CheckBoxes on the lower levels. I'd be more than willing to try another Tri-State CheckBox if necessary.
Also, when the user clicks on the Image in the top two levels, the image shouldn't change. I found this page which does keep the image from changing, but removes the PlusMinus, Lines, and RootLines from the control.
Sorry in advance that this is such a ridiculous and specific request.
Ok, I finally got this figured out. Using the Tri-State Treeview Control, I am able to still have access to the AfterClick event on the Treeview.
I had added a series of Checkbox icons to the ImageList, and after determining which CheckState (of the 3) my underlying object was in. Then I set the ImageIndex, SelectedImageIndex, and StateImageIndex (probably don't need the last one, but I was being thorough) to the proper index of the ImageList.
I won't post any code for now, but if you are trying to do the same thing, let me know and I'll upload until it becomes clear.
Perhaps hoping in a miracle, but let's try :-)
MyControl derives from Control. Its ControlTemplate contains
<ContentPresenter ContentTemplate="{TemplateBinding EditorTemplate}"/>
(Other details are omitted.)
Derived controls supply suitable EditorTemplate. For example MyTextControl specifies template consisting of a TextBox. (With proper bindings, of course.)
I won't describe what works (most scenarios), but what does not:
A collapsed MyTextControl instance is created. Later on this control is made visible. Here is what happens:
MyTextControl instance created, set to Collapsed
MyTextControl.Loaded event: At this moment the visual tree contains MyTextControl with no children.
In the Loaded handler I call ApplyTemplate(). In turn the visual tree is modified to MyTextControl -> ContentPresenter. That's all, no more children.
Stil in Loaded handler, I assign Loaded handler to the ContentPresenter.
Sometimes later the control is made visible. Its visual tree gets populated by TextBox internals: Border -> ContentControl -> ContentPresenter -> internal TextBoxView. In other words the control just works.
The problem is that the ContentPresenter Loaded handler was not called, i.e. I am not able to identify the moment when the control is ready.
I tried an alternative solution, i.e. instead of forcing ApplyTemplate() I simply waited in MyControl.OnApplyTemplate(). The sequence:
MyTextControl instance created, set to Collapsed
In the Loaded handler the visual tree contains MyTextControl with no children.
The control is made visible.
In OnApplyTemplate() the visual tree is MyTextControl->ContentPresenter.
Stil in OnApplyTemplate(), I assign Loaded handler to the ContentPresenter.
The rest is as before. The visual tree is populated by TextBox internals (the control works), but the above handler gets not called.
Does anybody know a way how to identify the moment when the control is fully loaded?
Note that I did the above with several other MyControl-derived controls. For each of them one of the above scenarios worked (sometimes one, sometimes another), but the TextBox-based control is the first one where I am not able to identify moment of loading.
Also note that this problem does not happen when the control is visible for all the time.
Ok, I'll answer myself. My current conclusion after 1 day and dozens of tests is that Loaded event is for birds. It happens on various stages of the control life cycle and in case of composite controls there is no warranty that the control is fully functional. In some cases it might be not fired at all.
Forcing template building by calling ApplyTemplate() is no solution either as in some cases it may result in building partial control tree.
OnApplyTemplate suffers similar problems - it might be called when only partial control tree is built.
After acknowledging the above statements I decided to give a try to LayoutUpdated event. I set up the handler in OnApplyTemplate() (I tried to use latest possible moment) and investigated the control tree. As a first approximation it seems to be sufficient to check if the ContentPresenter has children. If so, we'll say that the control is loaded and unregister LayoutUpdated handler. A more sofisticated test could be used, but the trivial one I just described is working for wide range of controls.
Originally I was afraid that the LayoutUpdated solution will be inefficient, but it looks like (using the described organization) the first handler call is exactly the place when the control is "loaded".
When using icon images without text captions, should the icon represent the current state or the next state? For example I have a block of text that I want to minimize / maximize or I want to toggle showing All User Records or just My Records. I'm sure there are compelling arguments for either side and know that consistency is key, but what are the arguments related to good intuitive user design?
There is neither standardization nor general human tendency on this. For example, MS Windows UX Interaction Guidelines specifies four basic kinds of toggling progressive disclosure control. Three out of four show the state-when-activated, while one shows the current state.
I believe if you test a particular approach on your users, you'll get different results depending on what you ask. If you show them a control and ask them what state the app is in, they'll tend to read the icon as if it were indicating the state. If you show them a control and ask them to change the state (where in some cases the state is already changed), they'll read the icon as if it were the state to achieve. It's precisely because of this they invented toggling buttons.
If you're lucky, users use the icon primarily for either reading the state or setting the state, and not both. Then let the icon indicate whatever the users use it for.
If they indeed use it for both reading the state and setting the state, you're basically hosed, but there are a few things you can try to minimize hosehood:
Use text in addition to or instead of an icon. When labeled with a verb (e.g., "Connect"), the control indicates the state the user gets. When labeled with an adjective or noun (e.g., "On Line"), it implies the current state.
If your lib doesn't support toggling icons, then consider using a checkbox control, if that's allowed.
If your lib doesn't support checkboxes, then consider two controls, one to set each state, where the current state is disabled. Not too good for reading the current state, but there's some precedence for this in pulldown menus.
Fiddle with graphic design or placement to make it consistent with the meaning you've chosen. For example:
Command buttons are always labeled with the action they commit, so if your icon indicates the state the user gets, then give the icon a raised appearance like a command button. If the icon indicates the current state, then give it a flat appearance.
Toolbar controls usually show the state they bring about, so put the icon at the top of the window if indicates the state the user gets. In contrast, icons in the "work area" of the window indicate objects or attributes, so icons there should show the current state. Icons at the bottom of the window (in the status bar) should also show the current state.
This has not been truly standardized. Folder icons, for example, show open folders when they are open and closed folders when they are closed. Same for disclosure triangles, etc.
However, in other contexts, this is not always true. In a movie player, the "Play" arrow shows when the movie is not playing, and it shows the pause icon when it is playing. Probably the thing to do is use your best judgment, then poll your users. If a preponderance of the people you test are confused by your icon choices, switch them around. Then test them again and see if your initial test holds up. :)
If you are just going to have one button to toggle between two states, then the button should represent the next state, because that is the action that the button will take when clicked.
You gave the example of text that is minimized/maximized. Think of any expandable tree interface you ever see in Windows. A minimized tree has a [+] next to it, because clicking the button will expand the tree. And a maximized tree has a [-] next to it for the same reason.
You could also try to make a toggle that is highlighted or "pressed down" like mihi says, but that might be more confusing.
I prefer the "next state" approach (click plus to expand, click minus to collapse).
One reason is that this is the most widely used approach, so doing anything else would confuse users (and me as well).
Another reason is that the "next state" approach looks more inviting for the user to click.
May I present Zoom's mute button:
It shows the current state, as an icon, and the action that will occur when you push the button, as text. In other words, the icon on the button is the current state and the label on the button is the new state. The current state and the new state are opposites, so the button appears to contradict itself unless you read it very carefully.
(I hate that button.)