We Keep Coding

Add controls to GUI in background worker

I have a form with a top and bottom panel.
The user will be making selections in the top panel, and each time they change a value on one key field I destroy the controls in the bottom panel, then make a time-consuming call to another application (via COM) and add a list of new controls being added. This refresh process takes several seconds.
I'd like to be able to disable the bottom panel while it's being refreshed, and allow the user to be able to keep working in the top panel. Of course, this is all one GUI running on one thread.
Illustrated:
I played with BackgroundWorker, but of course it cannot directly create controls on the main thread's GUI.
Is it possible for me to do this, i.e. allow one part of the GUI to be disabled and rebuilt in the background, while the user continues to work in on another part?

Is it possible for me to do this, i.e. allow one part of the GUI to be disabled and rebuilt in the background, while the user continues to work in on another part?
In general, no. GUI elements/controls must all be created and used on the UI thread, and nowhere else.
The best way to create this type of scenario is typically to use a BackgroundWorker or other technique to get the required data on a background thread, then build your UI after the data has been loaded completely.

Enhance UI Responsiveness in c#

I have created an POS application using Dynamic buttons, dynamic table layouts, and other controls in one form. The generated dynamic buttons is based on the number of data queried from the database(using OPEN ACCESS ORM).
My problem is whenever I run the application, the UI responsiveness is slow. For Example when I click on a category button, the sub category buttons appears (These are dynamic generated buttons), for it to appear, it would take few seconds to appear, then there are some little flash on the screen.
What will I do? What strategy should I perform.
Thank you. So much

Make sure the buttons do not have time consuming actions. And if they do:
use a waitcursor (simple solution, but not liked by most users)
use a thread to perform the action (might complicate other actions regarding thread safety).

Multiple forms or one form and add controls

I am creating a windows mobile application that has several different screens. At the bottom of each screen is a menu bar which the user can click on to navigate each screen.
My question is should I use a new form for each screen and clone the menu or use one form and have all the other screens as a control and add them to the main form?
Cheers

I'd vote for controls.
Both mechanisms can achieve the flow you want, and from a fundamental perspective neither is going to really be worse (as in load times, memory consumed, or what have you) so it's largely a personal style decision. Me, I use a UI framework that lends itself heavily to UserControls, so that's what I use.
Generally speaking, when I create an app I have a single parent/host form that has Workspaces where I put my Views. Thos Views are UserControls. Whether I use a tabbed workspace or a desk workspace, they still end up as Controls. The only reason I use more than one full-up Form is if I have a dialog (warnings, inputs, etc) where I will be doing a ShowDialog call.

Per this link, there is no MDI functionality in Windows Mobile.
In our application, we use different forms for each screen.
There are two ways to open up new windows:
formName.ShowDialog(): the new screen will be opened as a child of the other screen. In this case, you won't be able to access your parent form until the child is closed.
formName.Show(): the new screen will NOT be opened as a child of the other screen. Hence, you can access your parent even if the child is not closed.

You can use TabControl in single form with each tab having it's own controls. No need to add controls dynamically. And one single form. The way to achieve this is discussed in more detail in this answer.
Creating Wizards for Windows Forms in C#

Creating a .NET page to embed other .NET pages

I have created certain functionalities for an application. These functionalities include -
ADD USER
EDIT USER
DELETE USER and so on
Now I have written all these in seperate pages. So when I have to delete a user I go to USER_DELETE.aspx page to do that.
My new requirement is that there should be a single page from which all these can be done. Being more specific, I want that there should be separate panels in a page called "USER_MANAGER". Each panel will have the required functionality.
Is there a way I can do this by just creating the new UI of the USER_MANAGER page and calling the other pages (as User Controls or any other easier way) into the UI of USER_MANAGER?
I don't want to do any changes to the existing pages for various functions. I hope the question is clear, I am a bit novice in this technology so I am not really sure.
Thanks and regards

It sounds like you want to turn your pages in to ASP.NET User Controls. User Controls are just as easy to create as pages and can be used in similar fashion as Server Controls. If you want to create controls that can be shared between projects, then you want to write Server Controls but thos cases are probably not so common.

There are many ways to tackle this problem. If you are listing the users in a gridview you could use inline editing and do it within there.
You could retain the pages you wrote and use a modal popup or iframe. Another way would be with a multiview or tabs or panels.
I would design the UI and the then decide what the best solution for your application is then write these elements.

Handling multiple forms in C# app

I'm trying to modify a C# WinForms application that uses multiple forms. At startup, a login window will be shown. If the user logs in with a correct user name and password combo a form with three different tabs will be shown as a sort of administrators view. If no password or user name is supplied, a much simplified GUI will be shown. It will basically consist of two buttons that in turn shows these two forms depending on which button is pressed:
Button 1: Give the user access to a form consisting of a number of textboxes where the user can input information that will be saved to a database. Once the DB-operation has been executed successfully, the first form with the two buttons will be displayed again.
Button 2: A form is shown where the user can input a code that will be written to DB. Once the DB operation is concluded, the user will automatically be taken back to the original form with the two buttons.
Both forms will also have a back button to take the user back to the first form. I have a lot of logic in place, but I am unsure of how to best handle all the forms involved. Where should I instantiate the first (login) form? Once the login validation is done there are two possible ways to go. Either show the tabbed admin form (if user name and password is correct) or the simplified user form with two large buttons. It should also be possible to logout from the admin form so that the simplified GUI is shown instead.
I hope I am making sense here. I just need a good way to handle all the forms and navigation between them. Currently, there aren't really any need for transporting data between them, but it might be an issue in the future so a solution that takes this into account would be excellent.
I'm thinking that what is needed is really a class that handles the displaying and disposing of the forms right from the start, but I'm not quite sure where I should put the instantiation of this handling class.

I just did something similar. I had a set of forms to manage as "pages" as the spec called them. I also had strict page flow that was a bit more complicated than yours. I'll talk you through that.
I designed each "page" of interaction as a UserControl and created an "OuterForm" and a "Controller". The controller had a Navigate(string pageName) method and the outer form contained a panel and had a Display(Control page) method which cleared the children on a panel and added the replacement.
I used Spring.NET to configure the controller and the form and used setter injection to create a two way link between the two. That meant my main method could ask Spring for the form and just display it using Application.Run(form);
I created a convenience method to access the controller from event handlers and would do e.g. Controller.Instance.Navigate(chosenPage); The controller also used Spring.NET to load the correct UserControl for chosenPage and then called on the main form to Display() the instance it loaded. There as no Spring.NET code in any user control, and no new keywords either ;-)
The advantage for me in using Spring.NET is that I had one form class that just monitored some business logic and displayed a progress indication. I was able to implement that once and configure many instances of that form injected with different business logic that it would monitor. Also, I needed to stub out interfaces to domain specific pieces of hardware and web services. Eventually I moved page flow into the configuration as well.

Form management can be a tricky issue. There are some different ways to go:
Just have the forms float around on the screen. Let some static class hold references to the different forms and expose methods to activate them.
Implement the forms as UserControls instead, put them onto the same form, and show and hide the controls as appropriate (this can also be achieved by loading the forms, stripping form borders and such and setting their parent to a panel or something similar; this will almost make them behave like user controls, but only almost)
There are many other methods, of course ;o)
When it comes to managing the login form, I would do that in the Main method; show the login form, check the credentials and then instantiate the UI you want to show and pass that to the Application.Run method.

Have you considered using a Composite UI framework? In your case, you could use WinForms with CAB.
One of the big advantages is the support for role based authentication. An authenticated session could match one role, a non-authenticated session could match another role. Thus you can display different screens depending on the role of the user.
Another advantage is the answer to the problem of who is responsible for instantiating screens. This is managed by the controller, and actions on the screens (eg button click) can send events to this controller.
Last but not least, there are some good samples available and there is definately support for more advanced scenarios.