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:\\");
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.
How does one go about reading another applications listview and sub-listviews? This program has a main listview with a few other mini listviews once an item is clicked on the main view.
I want to create an application that can read the all of the listviews, how do I go about doing that? What is the best way to achieve this?
There are a number of ways to do this.
The supported way is to use an automation API like UIAutomation which is very simple to program. If the other application is using the standard Windows list view control then it should be accessible through UIAutomation. If the other application is using non-windowed controls (e.g. WPF, Qt) then you are dependent on the application implementing support for UIAutomation.
The other commonly attempted approach is to send windows messages to the list view control. This first of all involves enumerating the child windows of the application's main window in order to find the list view window. You can then send the control messages to obtain its contents. This sounds easy, but is actually rather tricky. The reason is that the messages require you to supply pointers to structures that are meaningful in the other process address space. This involves calls to OpenProcess, VirtualAlloc, WriteProcessMemory, ReadProcessMemory etc. It's quite tricky to get it right.
In my view, you should choose the automation API.
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'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.
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.