Question:
Is there some effective way to hide some portions of the WinForm/WPF desktop program based on user settings/permissions?
Why I need this?
I'm starting a big accounting project which will contain hundreds of forms/dialogs.
The program is going to launch a main window which shows 1 to 4 divisions. The user selects each of those and it will then launch the a window which contains a sidebar with a bunch of buttons on sidebar (something like Microsoft Outlook). Now, when the user clicks on each of these buttons, it will open that section of the program and the user will work with that part. Based on the user permissions/settings, there's a need to sometimes hide some of these buttons though. For instance suppose I have 4 main divisions A, B, C and D. When you launch A, you'll get a sidebar containing A1, A2, ..., A100. A user might opt to see only A1 & A50!
Our initial approach was to use WinForms for this because the team was very familiar with it. I suspect that for doing so, we have to build some sort of model which contains information about user preferences and write lines of code like btnA1.Visible = false; a lot.
Frankly just thinking about doing that disgusts me. That's why I'm looking for a better way to achieve such result. I've searched around and found PRISM.
I'm not sure just yet but I think to use PRISM I need to make each of those buttons or their dialog a module and load them after I decide which of them is needed for the user.
It seems like a nice way to do this but considering the fact that this project is very urgent and we don't need to load different modules for different users (we just need to load them - ideally on demand - and sometimes hide some), I have some concerns:
My team might need some time to learn WPF
All of us don't know much about Unity and PRISM.
This might be overly complex, i.e. there might be a more simple way to achieve this without going into such lengths.
Also, I'm watching Prism & Silverlight Series and PRISM5 for WPF from Channel9.
a window which contains a sidebar with a bunch of buttons on sidebar (something like Microsoft Outlook). Now, when the user clicks on each of these buttons, it will open that section of the program and the user will work with that part.
That sounds to me like a TabControl. You'd rather not try to reinvent the wheel as it's already been invented.
The only difference between that example and your requirement is that instead of hard coding the tabs you're going to bind to a collection of ViewModels, like this, and then have each instance of TabViewModel toggle it's own IsVisible property depending on user permissions / user selections.
Simple as that. No need for complex MVVM frameworks. No need for silly obsolete useless winforms stuff.
Related
Intro:
I am quite new to C#.
It is my job to create a certain simulation program.
I can't ask other programers, I'm an intern with a nonprogramer adviser and should not nother them. (I'm doing more of a fun project.)
So before spending a week or two to get really into WPF, I wanted to make sure it fits my needs.
If not, I want to use something else.
What I need:
Show the user a range of radio buttons to decide wether a simulation/plot/opening_of_svg should be done or not. (Can be done.)
A button "Add Task" where the user can choose one. (Can be done.)
Depending on the choice, add a certain form into the existing one, where parameters can be set. (Not found.)
Some of them radio buttons. (Can be done.)
Some of them text box, for integers and doubles only. (Can be done.)
All of them with default values. (Can be done.)
After adding a task, another "Add Task" button should be created, for adding more of them. (Not found.)
If for example a second simulation is added, it should take the values of the first one as default. (Can be done.)
Save the choices and data to a text file in a certain syntax like "Gnuplot Add Restriction = Time" which is used by the rest of the program. (Can probably be done.)
Question:
The biggest uncertainty is the one with adding forms into the forms.
Can this be done in WPF?
If there is any other framework (if this is the right name) specially made for this, feel free to comment.
I can't add many links due to my reputation. I might do it later. Just in case someone will find this later and wants to know about how.
Rather than creating Forms, consider creating UserControls and arranging them within a single Window. This is the same pattern you might use when creating composite windows in WinForms. I'd recommend the Grid or DockPanel layout panels.
In this respect, WPF is quite similar.
In addition, it sounds to me like you are doing a feasibility study for a new requirement. Are you sure it is not appropriate to speak to more senior staff? If I was them, I'd want to know your findings!
On reflection...
It seems like you are trying to create a branching Wizard workflow, like an installer might give you, i.e. Next, Next, I Agree, Next, Finish. WPF Can absolutely do this and some open source solutions already exist. For example, Avalon Wizard.
I just inherited a C# windows application codebase. It's a relatively large application with lots and lots of UI "elements" that I believe may have been added by the previous developer with little to no interaction with the actual clients. This application is a robotics control system, it runs at a manufacturing facility, and it has some of the most complex UIs I have ever seen (forms inside of forms inside of tabbed elements inside of etc...)
One of the first things I want to do, is learn about how the actual plant floor associates interact with this application. I have already sent out a survey to the different supervisors, but I would like some empirical data as well.
What I would like to do:
I would like to somehow, capture every time a user presses a button, control, etc... and record it to a file. Something simple like:
timestamp,name of control,any other cool data I can capture (program run state, for example.)
The difficulty is that I'm not really a C# expert at this point, and I can't figure out the appropriate way to add some sort of global behavior to my application which does this, and doesn't impact existing functionality. Any advice would be greatly appreciated.
Global keyboard and mouse hooks would be the way to go. Unless someone knows the design thoroughly and can comment how to extend existing functionality. it is going to be bit difficult.
I've been designing a pretty complicated avionics application. The thing is, it has many menu buttons to be clicked (12 to be exact) and each one of them perform a different action. For instance, one could be a login panel and the other one a PDF reader. How could I organize this programmatically?
Currently, I've been setting each item in a panel and setting it to visible or invisible, according to the active or clicked item.
How would you guys do this?
Thanks in advance!
You might consider a FlowLayoutPanel, although I'm not sure how flexible it would be in meeting your requirements. If you set your panels up with docking properties, you should be able to manage.
I would also recommend using a UserControl to separate code and functionality. If panels need to communicate, implement the observer/observable pattern instead of subscribing to events between user controls.
Like IAbstract says, you should consider separating the different UI elements as UserControls. You can then do things like use a factory to construct them and add them to your window as required.
I've found this sort of approach, used with a Model-View-Presenter type pattern, works really well for WinForms apps with dynamic user interfaces.
I was wondering if anyone knows of an existing sample or an approach to achieve the desired functionality.
Basically, what I'm looking for is a web browser like skeleton. The idea is that the main screen of my application is shown in the left tab. This tab can never be closed. On this screen is an overview of various application components such as activities, events, contacts, etc.
When the user clicks on a specific contact/event/activity a new tab is created and auto-focused. The user can view and edit the information. When they are done they can close the tab.
The ability to have multiple tabs open is important.
Also, keyboard shortcuts to easily navigate between tabs would be great, but not absolutely essential at this point.
Note: I don't need to access any web content.
Really what I'm looking for, at least what I think I'm looking for, is a shell of a modern web browser. Does something like this exist? Is there a good approach to building such an application?
Note: I'm new to Windows GUI development, so I apologize if this is a rudimentary question. I was unable to find anything meaningful while searching MSDN and other resources.
Thanks!
What it sounds like is not really a Web Browser shell at all, simply the relative appearance of one functionality-wise.
What you can do is use a TabControl control. This can be altered to suit your needs quite perfectly in my view.
An example of a modified TabControl is as follows: [ From here ]
There are a number of things that can be done with a TabControl (as with any other component) to make it suit what you need.
Here are some links that you may find helpful:
Flat Tab Control - As per the picture
MSDN
Video on using a Tab Control
C# Corner
I'm writing a WinForms based application for Windows Mobile, targeting the CompactFramework 2.0 and coding in C#.
My application has a menu which the user can select severeral job functions from.
My question is this:
For the job specific screens, should I load a UserControl into a panel in the main form, or is it better to open a new form on top of the main form?
They both seem to meet my needs, and I don't know if there is a "right" answer here.
Is one method more correct than the other?
Forms are Controls (just look at the inheritance chain), and a Form itself doesn't have a whole lot of overhead in and of itself. It creates a native Window, but that's about it.
What should drive your decision is how you use and display your UI elements in your solution. Forms are conducive to many UI architectures, and they're what most developers are familiar with. The designer supports them well, and creating, showing, hiding and closing Forms is a well documented, often used paradigm that works just fine. Yes, you have the load penalty whenever a Form is created as it creates all of its contained controls, but you're going to pay that even if it's a UserControl. The child controls have to be created in either case.
One might argue that Forms require that you recreate them every time, but that's not true. If you use ShowDialog or Hide instead of Close, you can reuse your Forms and pay the price once. The advantage here is that the Form holds your Controls in teh collection and manages all of that for you, so you have little to worry about with the GC and remembering what roots you have alive.
The UserControl paradigm is more complex - you have to manage loading and unloading controls yourself to keep memory pressure low. Complexity also increases cost - cost to maintain, cost to support, and likely cost to develop. However there are some clear advantages to UserControls in some scenarios too. If you use an MVC/MVP pattern and some form of framework that handlesyour Views, a USerControl makes a really good View with the Form becoming the Workspace (the SCSF for the desktop is a classic example of this, and so is the OpenNETCF.IoC framework for the CF).
So which is "better"? It depends on how and where you're using the elements, how your team is already doing development, and how you've architected the solution you're plugging in to. In short, the is no one right answer.
In my experience, depending on your hardware, loading controls far outperforms launching distinct forms. Our devices (Motorola WT4090 with 32meg) have no hardware acceleration, and drawing complete forms seems to really tax them. There is as much as 4-6 second delay any time a form is launched; controls, however, are almost instantaneous.
Maybe the best answer is to create a series of user controls and experiment with loading them onto the main form. It should be a fairly easy matter to then try to create a series of forms that have just the user control to see if you can improve performance.
If you don't see any performance benefit either way, it seems that it would just be a matter of preference.
Use Forms. It's the way the other applications behave. It's the way the user expexts your application to work.
Look at the pre-installed "Contacts" application: On startup you get a contact list. Once you select a contact, a new form is being opened on top of the current window. It's showing all the contact's details. Selecting "edit" from the menu will open yet another form, allowing you to edit the contact. The "Tasks" applicatoin behaves just the same way.
So the user knows: Clicking somewhere will open up a new form, and closing that form will get me back to the last form. You should work with that knowlegde rather than against it. When you use a single form, the user might repeatedly close it while he actually wanted to get back to tha last form.
From a performance point of view I find that forms open fast enough (<1 sec) on my WM 5 and my WM 6 devices.
And while it's possible to achieve form-like behaviour with UserControls, it seems more straitforward to use forms when you need form-like behavior.
So my bottom-line is: Use Forms!
P.S.: There's a good article on CodeProject on : How to create MDI Application in Compact framework
Depends on the complexity of the form/Control. Going the UserControl route will provide better performance as you will not have all of the form create functionality to also deal with.
My advice is to create a new Windows Form for every different logical action. If you need a form that is logically independent, then is better to have a separate Windows Form for it.
To speed things up you could construct all your forms in application's start up. This way you will have a delay when your application is launching (most users will be OK with this), but afterwards everything will run faster.