I'm trying to build a rather simple Windows Application for the employees that process our payroll (currently it's a vbscript/terminal combination). The logic is mostly worked out, but I'm trying to find out what the best way build a Windows Forms application that has multiple screens (login/etc). I've been using the TabControl container for this, but just wasn't sure if this was correct...or 'common'.
If this is what is normally done are the contents of the tabs generally made up of User Control object or are they just filled with different layouts on the tab?
I doubt I need much in the way of help on the coding side, but more the "how a gui" is normally laid out in the visual designer.
EDIT: Just to provide a basis of the screens that I'm needing to build. I'm currently planning on having a Login Screen and the three screens that guide the user through processing two different types of payroll and then certain accounts receivables work. Primarily I will have two user types. The ones that process payroll and the ones that do accounts receivable work. I'm wanting to make this easily expandable so that as I build in more functionality it's not a major pain to add screens and limit who can see them.
What I ended up doing is removing the "Login Screen" as hinted to in the question. Instead of a Login Screen and the corresponding logic being required I ended up doing integration with our Active Directory Server.
Once this integration was done I simply design the Screens as UserControl elements and then add each one to a tab based on if the user is in a specific group or not.
Doing this solved my main concern of having a heavy main form containing logic. Now the only logic in the main form is whether or not to add a tab based on Active Directory groups.
Related
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.
Rather than have a large collection of small desktop applications, I was wondering if there's a way I can combine them into one 'Master Form' with links to each?
I have many similar applications and the ideal situation would be to have almost like a website hierarchy, where the user can navigate to the application they want.
I have considered a solution that sits on top of the rest and calls the others in some way, but I can't find if this is possible or not, is every separate application effectively stand-alone?
Yes you can directly disign on master form for it.
keep menus for each exe(Application) and,
give command in following way for onclick of that menu in master>>
System.Diagnostics.Process.Start("billing.exe",strCmdText);
Or directly Process.Start("C:\\");
I am planing to develop desktop application that will have multiple logins and according to that login type options/From view will be displayed.
I have done database login part now its turn of view
How can i establish that what i have in my mind that
Drag and drop all required controls and make them visible = false and check which type of login is that and display accordingly
Create separate forms and display one by one as required
You sound like you are new to C# forms programming. I suggest looking at some tutorials or a book like this Windows Forms Programming
For me it depends on numbers.
If u have many diffrent user roles and they share only a few controls then it would be easier to make diffrent form / panel for each user type. This approach is quite dangerous since when you want to change common control u would be forced to do it in all forms / panels.
Thats why i would recommend to group application logic into custom controls and then build GUI from them. For example: if you have two user types ( let's say boss and employee ) then you can build form with shared controls / logic and two user controls (bossControl, employeeControl) with functions for boss and employee. Then after login check you add matching user control to GUI.
You need to make one form and make control visible/invisible or enable/disable control.
Create separate forms and display one
by one as required
it will be very difficult for you to manage and extend in future.
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