I need to develop a winform with a treeview menu, localizable and with different options in case of each user (role and single-user based).
The only solution I can imagine is really unmaintainable:
Everything loaded and watched from database.
A table to define the menu (child-of...).
Every option in the menu should have a Form name to find and open it with reflection.
A table with translations to each language related to each option in the menu.
A table with permissions for each user and option (to show or hide it).
Is there any simpler solution??? I really don't want to do this kind of stuff 8-)
Thanks in advance.
We have actually implemented exactly what you are describing here (with the only difference being that we are using one language) and it works quite well. The fact that the menu can be altered at runtime has been used multiple times where any other implementation would have required a code release.
I am not sure why you say that it is not maintainable - the system has been in use for years now and we hardly ever need to spend time on the code that makes it all work.
A different system that I am involved in we build the menu at design time and then just have a lookup table with all the menu buttons in the database - it actually feels a lot easier to get something wrong there than when everything is in the DB.
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.
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.
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 searching for days about this, but haven't found anything.
I am trying to find out how I can add a context menu item to the windows explorer. I do not want it for specific filetypes, BUT I want it to appear on everything inside a specific path.
For example, I want right-click menus of anything inside "C:\folder" to contain this item, but it shouldn't appear outside this folder...
Is that possible?
Any help will be really appreciated!
Thanks in advance,
John.
The normal way this is achieved is to add it to the Registry under:
HKEY_LOCAL_MACHINE/Software/Classes/Folder/Shell
However in your specific case you want to do some preprocessing before it is displayed (eg is it in the specified directory) which wouldn't work with a simple registry alteration.
I think there is a way to force you way into any operation and add a hook to it. I'm talking about old school knowledge now though and I cannot think what the technology would be called. I think its how you would have, for example, forced your way into the rendering engine to put custom skins on normal explorer windows or inject an extra button into the title bar of apps like you used to see back in the day.
It just occurred to me that adding a button to the windows title bar might have given a search starting point, I found this article which refers to subclassing windows components and injecting your own behaviour. I think that is what I'm talking about above:
http://www.codeproject.com/KB/wtl/titlebar.aspx
Hope this gives you a new direction to search in.
I'm currently developing a WinForms application in C#, and need some input on how to manage toolbar buttons, menus and other context sensitive elements. What is the best practice for this?
I've found the article 'Use Design Patterns to Simplify the Relationship Between Menus and Form Elements in .NET' on MSDN but I'm not sure if there is a better way since the article is pretty old (it's published in 2002).
Grateful for any constructive help.
When developing an event-intensive application (lots of menus, toolbars in lots of forms) it is common to have certain events overlap or repeat, in the sense that there are many ways to do a certain thing, and I see this redundancy as a benefit to the user, but a bane to the developer.
A well planned object-oriented approach will dictate how to manage the actions triggered by events so as to avoid duplicate or overlapping code.
You could of course find a very useful source of inspiration in Microsoft Office, as it is somewhere a standard (THE standard?).
Depending on the kind of form you are using, I guess you could set some basic rules, where for example data entry forms will have a basic menu such as validate\quit\refresh\abandon\print\export to excel\filter\order by\etc. Such menus (let's call them "Standard") will be ideally available under the "File" and\or "Edit" and\or "View" menu controls, sticking to standard Office menus (even Firefox uses this terminology).
I'd advise you to allways display this standard menus, even if some of the actions are not allways available for such or such forms. Just imagine that data contained in one of your forms cannot be updated under certain circumstances: you can still display the disabled version of the "validate" icon instead of making it invisible. This will definitely make things easier to understand for the final user.
Once this standard list of menus/options established, I guess you'll come up identifying 2 other major "menus" families, the "Details" menus and the "Actions" menus:
Details menus allow you to navigate
through forms, accessing/displaying
subforms/subsets of data, such as
Items in a Purchase Order.
Action menus allow you to run specific actions on the data, such as emitting a purchase order.
Your different menus shall be made available through a command bar, and context sensitive shortcuts. Options such as "filter" can be made available at the bound control level, while actions such as "Emit the PO" are only available at the record/form level.
People, or group of people, shall then be allowed or not to open forms and/or to run specific actions on these forms
In order to manage menus and rights, our apps have a default "menu file" on the client side, and both a "userGroup-forms" and "userGroup-actions" tables on the server side.
userGroup-forms table links groups
and forms and list view\modify rights
of each group.
userGroup-actions table contains a true value when a group has the right to perform a specific action
When connecting to the database, the user is identified and its local menu file is updated to give him corresponding view/action rights.
We are clearly here in an object oriented approach, aren't we?
The ToolStripManager class has a Merge Method, so you could have any child Forms/User Controls expose their own ToolStrips that get merged with your main form's tool strip when they have focus.
http://msdn.microsoft.com/en-us/library/5523fet0.aspx
If you are using MDI, you can also merge menu items of parent and child forms.
http://msdn.microsoft.com/en-us/library/ms404319%28VS.80%29.aspx