There are two main panels used for different purposes. One of the panels is used for making some drawings, using dc(Panel-D), the other one contains some buttons for getting user inputs(Panel-I). The issue is about the placement of these two panels. I am trying to place Panel-I over Panel-D as shown below(like always on top option). The difficulty in this matter, I couldn't put Panel-I in Panel-D, because we can't intervene the drawing functions on Panel-D.
I tried using different techniques with various types of wxSizers and wxSizerFlags, but couldn't get the desired orientation/placement. I would be grateful to any suggestion.
You should have no trouble with this if you create Panel-I as a child of Panel-D. You can then position it in any way you want: either manually (e.g. if its position is fixed), or using sizers.
Related
I have a vtkboxWidget2, all I want to do is to hide the handles of two opposite sides (any 2 circles of the same color in the attached photo).
I've looked but didn't find a way to do so, I can either hide or show all handles without the ability of specifying a certain one.
is there a way to do so ?
Thanks.
Set this
vtkBoxRepresentation::SafeDownCast(boxWidget->GetRepresentation())->HandlesOff();
I'm a little bit confused about how the IDs work in wxWidgets, do I have to ensure that all ids across all windows that I create are unique to each of their own functions? Like if I have two wxID_OK's for two different dialog boxes are they going to start firing off events in other windows just because they share the same id?
Currently I've been maintaining a huge enum to grab my IDs from, this seems a bit silly though, and was wondering if I just had a misunderstanding of what is actually going on.
I nerver use id's nowadays. I use wxID_ANY for all widgets and use the widget pointer for identification. This works just as well and so there is no reason for two id's for the same widget. There might be some corner cases where real id's are required but i have not found any.
It's a good idea to use unique IDs inside each top level window (i.e. a wxFrame or a wxDialog) because the controls include their ID in the wxCommandEvents they generate and as command events are propagated upwards the window hierarchy until they reach the first top level window, it could be confusing to have 2 controls with the same ID as any handler defined in their common parent window would need to be careful to distinguish between them.
There are no restrictions on the reuse of IDs in different dialog boxes however.
And an even better idea is to not use any non standard IDs at all but just let wxWidgets generate them for you by specifying wxID_ANY when creating controls and using Bind() to connect your event handlers instead of the IDs in the event tables.
I've recently started lerning Qt and I'm facing the following problem:
I want to create sth like a chessboard (empty, doesn't have to do anything for now) - I've drawn a simple interface, but in the middle I need to make a chessboard itself (let's say it will be made out of small QTextBrowsers).
The problem is that the size of chessboard must be specified by user. So, drawing 16 fields and giving them unique objectNames is easy, but I have no idea how to:
generate those fields 'dynamically'
generate unique names for them, so I will be able to refer to them later in code eg. field_1_1, field_1_2, field_1_3
Thans in advance,
So what I think you want is a two-dimensional array of fields. That way you can reference the correct field without knowing the name.
More specifically Qt provides QLayoutGrid which, although not a two dimensional array, will give you grid access to widgets by using the itemAtPosition method
I am making a new graphical menu interface for a project I am making. I don't want to use the menu system provided by windows APIs and want to make one from scratch.
My question is, what is the best method for setting up the structure?
I'm thinking I will need a menu item object, each of which will have to have their own item array list, etc...
Is it considered sloppy to have recursive coding like that? (Ie an object which contains objects of itself, which contains objects of itself, etc...)
I'm thinking I can give the item object a draw interface which checks itself to see if it has an item array that is not null. If it does, it executes the draw command all the way down, thereby giving me a menu with (for my purposes) unlimited submenu level
In my opinion your approach is fine. In nearly all UI frameworks, views contain views as subviews after all.
But the thing is that writing drawing code is too much work for small projects I think. I would consider using a UI framework such as QT and use its view mechanism as a starting point. You can write your own Menu class which will be a subclass of generic View class in the framework.
I have a hierarchy of categories, where a category can have a single parent (and you can have multiple levels of children.)
I'm investigating ways to display this information to the user and it seems like a basic vanilla tree layout is the most intuitive way to go. But I'm wondering if anyone can suggest other approaches.
The requirements would be,
1) clearly demonstrate to the user the list's parent / child relationships
2) allow the user to easily move items around (whether by drag and drop or some other method)
3) Assuming you had hierarchal data that had multiple parents, how would that change your choice?
Thanks everyone! - Kevin
Your basic tree control has been a great success for showing hierarchical relations. It’s relatively easy to learn for novices and is now the de facto standard for hierarchies. It is very suitable for editing relations, especially with drag and drop. It is perhaps the only viable choice when the hierarchical depth varies arbitrarily by object (i.e., for any object on the tree, there can be children, grandchildren, great-grand-children, and so on to an indefinite number of “generations.”).
The primary alternative to tree is a window with master-detail panes. In this design, one pane contains parent objects and another contains child objects. Selecting a parent object populates the child pane with its children. You can have grand-child panes and great-grand-child panes as necessary, but master-details generally work best when there is a small fixed number of layers to the hierarchy. Users edit the parent-child relations by drag-and-drop and cut/copy & paste of child objects either within or between windows, similar to using a tree control.
Master-details are usually better than trees for the following cases:
You need to show multiple properties or attributes with each object. For example, for a given Project object, you want to list not only the Employee Number for each Team Member, but also their respective Names, Roles, Titles, Divisions, and photographs. With a master-detail, each pane can be laid out as a table or form allowing you to show a lot about each object. Tree controls often resort to inefficient and confusing Properties dialogs to accomplish this.
You need to subdivide children. For example, for a given Project object, you want to keep its Team Members separate from its Project Stages. With a master-detail, you can have two or more child panes for a single parent pane, with one pane listing the Team Members and one listing the Stages. It’s awkward to keep unrelated child objects separate with a tree control.
You have many-to-many relations, where each child may have multiple parents as well as each parent having multiple children. For example say each Project has multiple Employees (as Team Members) but each Employee may work on multiple Projects. You can have a window with Projects in the parent pane and Team Members in the child pane, or Employees in the parent pane and Project Assignments in the child pane, or you can have both windows. Tree controls may confuse users when there are many-to-many relations because users don’t expect the same child to be under more than one parent.
TreeGX is a sweet way to display hierarchical data in a different fashion from the standard tree - link is here.
I use the component to present search results and while it is NOT free it is worth the money if you want to present something unique.
You can put some visual flow chart style design to make it more engaging. How far you want to go is totally up to you. This will help you with multiple parents.
Your question treats your design problem as if it is an abstract thing. Unfortunately, it's not that simple - if only there was one perfect solution!
UI Design is highly contextualised. You have to think about the user group (i.e. their needs, goals and expectations) and the type of activity you are trying to support (i.e. what exactly is the user doing when they browse this tree? What's their goal? Are they going to use your app daily or once a year? etc). What works in your context may not work well elsewhere.
People are always disappointed when told "go build a quick prototype and test it on a sample of your end users". It involves further work and it outside a typcial developer's comfort zone. However, it is the only way to be sure that your UI is right for your given context.