I have been trying lately to have one constant menu for all the screens, but I couldn't find any solution for that! The only solution was to copy the menu code and paste it in every single screen with their click events code. Do you have any ideas about this?
I want one stable / constant menu in my whole project.
Thanks.
Approach 1: You can create a user control that wraps whole menu and its item commands. This seems more proper, flexible and straightforward approach than 2nd one below. Get started on how to create user controls in WPF.
Approach 2: Have a one main window in application with a Menu and a Frame that will host rest of the views of your application. These views will be result of the menu item command. Frame and Page are generally used in application where navigation is desired. For your case I repeat Approach 1 suits and sound logical more.
Related
I've been building my Codename One app for the phone screen format so far. There is a separate Form for the main menu, then a second Form with a list of elements, and then a third Form to edit an element selected from the list. Each Form has an overflow menu and various Titlebar command buttons. And each (Extended) Form has a lot of code that implements the functions in the Form and shares variables etc.
However, to use the tablet (iPad) screen estate, I would like to show the main menu on the left of the screen, the list of elements in the middle and the element edit form on the right. Something similar to the screenshot below. This seems to be a common type of layout on tablets and suits my app usage pattern well.
However, I don't see an elegant way of structuring the code to do this. I can't easily combine the list and edit Forms into one Form, and writing a completely new Form just for the tablet format would be a lot of work. I assume others have faced the same challenge and would love to hear how you achieved this.
PS. I know the side menu can be made permanent but that only solves part of the problem, not how to show a list and edit Forms at the same time.
There is no one answer for this but if you look at apps like Codename One Build you would notice they adapt to this form factor.
We usually just use isTablet() to adapt the UI at key points to the different form factor. One element is the permanent side menu which we turn on in the init method using code like this:
if(Display.getInstance().isTablet()) {
Toolbar.setPermanentSideMenu(true);
}
It makes the side menu stay open all the time. Within the code we try to use Container instead of Form. This allows us to package multiple logical pieces into a single UI for the tablet mode.
I have several Wpf pages in my project, these pages have different forms and ui control indide theme. The image below shows the mainWindow and there are two button.
I want to show a specific page when I click on + or Edit button using the Frame control which is highlighted.
apparenatly this woks:
Page1 me = new Page1();
mainFrame.Content = me;
But it has an IE navigation sound and a toolbar appears after going to page2.
any better way to show diffrent pages and not using a frame?
You may want to convert the Page into a UserControl. You can then put that control inside some other container, such as a Grid. You'll have to manually swap out the pages in the container when navigating, but it looks like you're doing that anyway.
The purpose of the Frame control is to allow navigation. If you don't want navigation, then don't use Frame. You can turn off the navigation toolbar, but that won't actually disable navigation - there are mouse buttons and keyboard shortcuts for navigating back.
If you just want to host a UI element without navigation, use something simpler, like a Border element - put the content in its Child property. You can change the Child as many times as you like at runtime.
I was able to set the frame control's NavigationUIVisibility to Hidden. This solved the problem for me. I am using Visual Studio 2010 though so it might not be applicable to older VS versions.
Ian Griffiths, what you suggest increases the workload on the developer substantially. And you are stepping outside of the underlying paradigm of XAML.
In my case I'm developing a game application and have chosen WPF as the UI platform as much as possible. For me that means a intro screen, character select, etc. The purpose of Pages is to encapsulate the navigational need of such an application.
I suspect your downvote is due to your statement "If you don't want navigation...". Upon re-reading the original posters question I see he does want navigation, he just wants it on his own terms. I would have voted you down too. YotaXP's solution neglects the issues with using a User Control, particularly if it may contain other User Controls. It looks like Chris Calvert came up with an actual solution to the poster's issue within the parameters of the problem.
I would be curios if I could override the navigation hotkeys and such within the existing paragimn but that's properly in its own thread.
In order to make a convenient UI for an .Net 2.0 Winforms application I am working on, I have need for a control that I'm pretty sure goes beyond the "out of the box" behavior of any standard control. A mock-up of what I'm trying to achieve follows:
Mock up http://www.claware.com/images/temp/mockup.png
Essentially, this part of the application attempts to parse words into syllables from tribal languages (no dictionary to refer to; any and all unicode characters are possible.) By the time the user gets this far, he has already defined the vowels / consonants in his language and some other configuration. There is then an iterative process of (1) the application guesses which syllables exist in the language based on some rules, (2) the user refines the guesses, selecting the correct parsings or manually parsing a word, (3) the application "learns" from the user's feedback and makes smarter guesses, (4) repeat until the data is "good enough" to move on.
The control needs to present each word (the grey headers), then all the syllable break guesses (the white areas with dots separating the parts of words.) There is also a way to manually enter a parsing, which will display a text area and save button (at the bottom of the mockup.) When the user hovers over a guess, the background changes and "accept / reject" buttons appear. Clicking on the accept, or entering a manual parsing, removes the entire word from the list. Clicking the reject button removes just that item.
I'm by no means 100% sold on the formatting I have above, but I think you can get a general idea of the types of formatting and functional control I need. The control will also scroll vertically--there may be thousands of words initially.
My question for you experienced WinForms developers is: where to start? I would really, really like to stay within the .Net core framework and extend an existing control as opposed to a third-party control. (At the risk of starting a religious war: yes, I suffer from NIH-syndrome, but it's a conscious decision based on a lot of quick-fix solutions but long-term problems with 3rd party controls.) Where can I get the most "bang for my bucK" and the least reinventing the wheel? ListView? ListBox? ScrollableControl? Do I need to go all the way back to Control and paint everything manually? I appreciate any help that could be provided!
[Edit] Thanks everyone for the ideas. It seems like the most elegant solution for my purposes is to create a custom control consisting of a FlowLayoutPanel and a VScrollBar. The FlowLayoutPanel can contain instances of the custom controls used for each word. But the FlowLayoutPanel is virtual, i.e. it only contains those instances which are visible (and some "just out of scroll"). The VScrollBar events determine what needs to be loaded. A bit of code to write, but isn't too bad and seems to work well.
I would look at the TableLayoutPanel and FlowLayoutPanel controls. These will let you organize a series of controls with moderate ease in a vertical fashion. I would then create a UserControl that consists of a label and 2 buttons. The UserControl will expose properties like Text and events that are exposed for the button clicks.. For each entry in the list, you will create an instance of the UserControl, assign the text value, and handle the click events. The instance will be placed in the Table/Flow panel in the correct order. Both of those layout panels do allow for inserting items between other items so you can add/remove items from the list dynamically.
Edit:
Given the length of what you are trying to render, I would consider using the DataGridView and do some custom rendering to make it perform how you want it to work. Using the rendering events of the DGV you can merge columns, change background colors (like highlighting the dark gray lines), turn on/off the buttons, and handle changing the grid into edit mode for your rows to allow modification or inserting of new values. This method would easily handle large datasets and you could bind directly to them very easily.
Well, this certainly looks like a candidate for a custom component that you should be creating yourself. You can create this using standard .Net drawing commands along with a text-box, and a regular button control.
Now you want to find out where to start.
Create a Windows Forms Control Library project.
Drop in the textbox and the button control.
The panel drawing code should preferably be done by code. This can be done using the regular GDI+ commands.
Edit:
Here's another idea, and one that I've practically used in my own project with great success.
You could use a web-browser control in the app, and show your data as html. You could update the source of the web-browser control based on the input in the textbox, and clicking on the links in the web browser control will give you the event that you can trap to do some action. Your CSS will work.
I used this technique to build the 'desktop' in an app I made called 'Correct Accounting Software'. People loved the desktop so much that it is one of the best loved features of the app.
Here's how I would do it:
Create a custom control. In this custom control, have a ListBox atop a LinkButton, and when the LinkButton is clicked you can make it give way to a TextBox. The ListBoxes will have the top row unselectable... you can probably get the rest from there. When you get your list of words, fill a Scrollable of some kind with one control for each word:
(foreach String word in words){
myScrollable.add(new MyComponent(word));
}
From there, I'm not sure what you want to do with the boxes or the data, but that's my initial idea on the UI setup.
Use the WebBrowser control and generate the HTML markup into it using DocumentStream or DocumentText.
I am currently loading the default file, page.xaml, but in that page, I am loading the content from another xaml file. With each "page" change, I just load the content from a different xaml file, and on and on.
Example: this.Content = new StartPage();
I'm running into some syntax issues, however, because of the way I am changing my content, and was wondering if there is a definitive answer on how to accomplish this?
For example, when trying to capture user's keystrokes, I would normally do:
this.Keydown += new KeyEventHandler(this_KeyDown);
but that event handler doesn't even fire in my situation. So, I'm looking for a new approach to my content-switching approach before revisiting the keystroke problem.
Have you looked at using Silverlight 3. It has a new Page Navigation functionality.Silverlight 3 Navigation
As far as content switching goes, I've always done what you propose in the question. Normally I create a MainPage.xaml which has has the frame of the application (usually a Grid for me). One of the cells in the Grid is considered the content area of the app. When the user takes an action that I would consider to be navigation, I create a new instance of a Page, which for me is a file like MyUserControl.xaml, and then add it to the appropriate content cell in the Grid. MainPage stays around for the life of the application and assists with navigation.
If you want something fancier, and want to take advantage of browser based back/forward buttons, you could look into the SL3 navigation like Correl suggested.
A Big problem with what your're doing is that journalization doesnt take place automatically when you swap out framework elements by creating them and plugging them in the codebehind. This means that you lose the back and forward functionality of the browser. You can manually journalize stuff when you swap out pages, but this is simply a hack to get your navigation approach working.
Take a look at Prism at www.compositewpf.codeplex.com/, specifically the MVVM method of GUI design, it'll save you alot of time later on. And remember, you dont need to go hardcore when you look at MVVM, u could always cut out alot of "dynamic" functionality if you're a one man band
Also swap to silverlight 3 and use the navigation application. If you cant, take a look at helix 0.3, it'll provide a more asp oriented approach to navigation. the link provides a really really good starting point, its a three part article, i suggest you read all three and download the sample application and understand it.
A book could have been written on your question, this has to suffice for now.
What do you think is the best way to present a hierarchical list of functionality to users within your traditional WinForms application? (A menu system - Assume functionality can be split into a small number of modules and sub-modules but with no fixed depth in terms of those sub-modules).
Do you like the traditional drop down menu system, ribbons, docked toolbars, a treeview approach or any other innovative ideas?
An important thing to consider in your design is Usability vs Discoverability.
The best solution depends strongly on who you users are. The UI requirements for a kiosk application for tourists in a city centre are very different to those for a control screen at a power station...
I often have a toolstrip docked on top for those functions that is most used. And all other as drop down menues with hotkeys set.
If I have a list that can contain different types of items I use a bottom docked toolstrip that change its content depending on the selected item in the list. That way I only have buttons/icons that is relevant for the task and not a bunch of disabled buttons irritating the view.
I also add a context menu for the items that automagically fills with the same choises as the bottom toolstrip. That way I give a faster way to get to the "action" without having to move the mouse down to the bottom of the screen.
I really hate the ribbon-thing (as a user) so I dont use it as a programmer in my projects.
In my opinion the best way is to make sure everything can be done in several ways.
Menus
Keyboard shortcuts
Toolboxes ...
So the user can choose it's way around.
What I really like to see in more application is that a menu or option is directly attached to the selected item (control) a user is looking at. And of course the menu is in context with the given content.
I have implemented this in my open source project Monex and I really like using it myself. Just look at this screenshot.
You could always opt for the increasingly ribbon control. Microsoft/Office interfaces have a habit of becoming the user's expectation of norm (eventually).
Menubars, toolbars, and Ribbons are used for commands, where the user selection of an item acts on a data object displayed in the window or the application as a whole. Which one you use depends primarily on the number of commands in your app.
Toolbar alone: About 20 or fewer commands. Provide both icons and text labels for each command button. Represent the hierarchy by separators. Have no more than two levels –flatten your hierarchy accordingly.
Menubar with toolbar: Over about 20 but less than about 1000 commands. Up to twenty menu items on a single menu (using separators) is generally better than cascade menus –flatten your hierarchy accordingly. Common commands should have accelerators. Generally limit your toolbar to no more than 30 of the most commonly used commands, primarily commands otherwise only accessible from within a dialog box. Consider not having toolbar controls for menu items that have accelerators –one good means of expert access is often sufficient.
Ribbon: Over 1000 commands. A Ribbon is little more than putting different menubars-and-toolbars on separate tabs. To work well, the tasks associated with each tab (the top of your function hierarchy) should be non-integrated –users relatively rarely switch from one to the other. The Ribbon is also tends to be more effective for promoting discovery of advanced features at the price of discoverability and efficiency of basic features.
Check if items in your function hierarchy may be better represented as attributes rather than commands. Commands carry out a process, such as Open, Find, and Copy, while attributes change specific characteristics of something, such as Font, Size, and angle of view. Attributes are set by field controls within your window (e.g., text boxes, check boxes, and dropdown lists) rather than menu items, toolbar controls, or Ribbon controls.
A window-full of such field controls (or other representations of data objects) is a content block. Tree controls may be used to control what content block is shown. Like tab controls, they are preferred over multiple windows when the user frequently switches among the content blocks and does not compare content blocks. Trees are preferred over tab controls when the amount of content will not fit in a single row of tabs.
Do not have any empty nodes in your tree. Anything the user clicks on should display a full pane of content –flatten your hierarchy accordingly, even going to the extreme of using a list box rather than a tree.
If users tend to select one content block, complete a task there, then leave your app, then consider a “home” page displaying a full-page menu of all the content blocks, possibly spatially arrange according to your hierarchy, each accessible with a single click.
In my opinion there is no definite answer to your question. It always depends on the menu you are presenting to the user and the users that are expected to use the application
A menu with standard/common functionalities is probably best presented Office style meaning drop down menus or the new Ribbon style.
A menu with custom functionality and, as you state multiple modules and submodules with different depths, is often best presented as a TreeView-like menu.
Looking from the point of the user, a typical user will do just fine with a standard menu whereas a more advanced user won't mind more advanced features like keyboard navigation or possibility to hide/show the menu or dock it to the other side of the window.