I am making a c# windows app that has one MainForm and many User Controls (LoginPage, HomePage, MyListPage, etc.) embedded inside it. I am using Visual Studio 2005 to design the GUI.
In MainForm's constructor I do:
Controls.Add(new LoginPage());
Controls.Add(new HomePage());
Controls.Add(new MyListPage());
...
LoginPage.show();
But I have over 30 pages that I add to MainForm's constructor and I think this is the culprit of my app's lag at its runtime. Does anybody know a more standardized way of using User Controls for a one-form navigation app?
I'm assuming you have a way of navigating between pages - your user controls aren't all shown at once?
If that's the case, you should be able to do the following:
Create one of the user controls on construction to use as the initial page.
When the user performs an action which means your app should move to another page, remove the current user control from the form, dispose of it, create a new one of the required type, and add it to the form.
If you only want to create each user control once, you can use a caching mechanism so that each one is only created once (and don't dispose of the controls as you remove them).
If you use this approach, it should get rid of some of the initial lag, and trade it for multiple smaller lags as the user navigates to each user control for the first time.
Related
I've got a WinForms app that uses a ChromiumWebBrowser control. The control will display content for a specific web page depending on what the application is being used for at the time, and after the user is finished with the site, it should close.
However, the user could currently use the back/forward buttons (or the context menu) to go back to a page in the browser that they shouldn't have access to any more. I need a way of wiping the history from the browser to prevent this.
I can't find any methods or properties within the control itself that can edit the history, and the best solution I've found so far is the OnLoadingStateChanged event (in which the back/forward buttons can be enabled or disabled). I can't figure out a sensible way of using this to track whether the user can go back or not though.
Is there a simple way to access the browsing history of the control?
I'm starting a project which will contain multiple pages tabs style. I.e. you have a footer of the application and it's header. Header contains buttons that load different User Controls in the center of the app. I know how to swap user controls and show one or another, but, what concerns me are events from hidden controls and UI updates.
I was thinking about creating UserControls to represent each page. One would contain list of files available for download, another would contain UI of the download manager that would show end user progress of download.
In order for some page/control, that is not currently showing, to throw events, its instance need to be present. What would happen with UI updates in this case? Consider user selected files to download and added them to the download manager. Download manager is currently in the "background", basically, it's UI doesn't exist (instance of the UserControl exists though). I presume that every attempt to update the UI will end up with an error?
Or, am I over-thinking this? Now, that's all a theory at the moment, I didn't yet code a single line of code for this project because I wanted to consult with someone and start from the right foot.
Thank you in advance.
P.S. Or may be use tab control...
If I understand you correctly, you are not loading/unloading the usercontrols, but merely showing/hiding the usercontrols. Updating the UI should not cause an error in this case. What you need to the design and implement is a number of events that the container will subscribe to. The container should then trigger funtion calls to the correct usercontrol that needs to be updated. But, as you state I would prefer to use a tab control. But, the event part is still the same.
I am working on a project that simulates a company's program for performing various functions within a GUI (using C# on VS2010). Currently there are about 10 or so different forms, one for each function (serving as a menu, filling out assorted forms, management of said forms, ect). So far we've been using things along the line of:
Form1 myForm1 = new Form1();
myForm1.Show();
to open new screens and
this.Hide();
when finished with the currently active form. (this.Close() just seems to close the entire program)
This causes some issues in that the process has an issue of continuing to run after the X at the top right of the form is clicked (I think that this is due to hidden forms not being closed properly). I also suspect that if a user uses in-program navigation without killing the process long enough, the constant generation and hiding of forms will end up hogging up all the memory.
In the wild, I rarely see programs that rely on opening new windows/forms constantly to enable user navigation. Programs, such as an installer, typically use an event of some sort to cause the current displayed content to disappear and new content to appear without changing to a new form/window. How can I go about doing this? Is it a matter of having buttons/textboxes/labels all stacked on each other in the one screen, but hidden or is there something more intuitive that I am missing?
Have you looked in to using some kind of MDI setup: http://www.codeproject.com/Articles/7571/Creating-MDI-application-using-C-Walkthrough
The way you can do this (but isn't always feasible) is to make a UserControl for each screen. When its time to move on to the next screen, you simply hide the current user control and show the next one. So if you have 8 screens for example, you make each one into a user control.
Then on your MainForm's Load event, you initially hide all except the first one. When its time to move onto the second screen, you hide the first control and show the second, etc etc
I'm developing a windows form application with controls on the main form that retreive their values from a mySQL database. When the database gets updated I need the form to repaint and refresh the controls. Can anyone reccommend a solution to this? On sub forms I've instantiated a new instance of the form and dispose of the old one, but I can't do that with the main form. Thank-You for considering my question.
I'm not sure if correctly understood your question, but you could put your controls inside of a user control and use-it in the main form. Then, you could do the same you did with the forms: dispose and create a new one.
This should solve your problem, however, you may have some problems with scrollbars and the resizing of your form.
If it were me, I wouldn't dispose of a UI with another, that is in focus for the user. That would kind of irritate the user especially if the update is automatic.
Suppose you have view-only controls like gridview or labels updating with live values, then you can put a time interval and display a seconds ticker clearly telling the user when an update is going to happen.
You should consider having an update method on all your controls (or one usercontrol having all the controls) which you can trigger to update the controls at timed intervals.
So I would consider myself a .Net and ASP.NET pro but I am a bit new to Windows Mobile (I am targeting .net 3.5 CF and Windows Mobile 6).
I am creating a data driven application that will have 3-4 tables. I have created a form for each table that allows the user to search through the table.
Each form inheretes from the Main form so that they each have the same Menu.
My question is how do I make sure that only one Window is open. I want to allow the user to go to the menu and choose a table which will open a new form. What I don't want is for the user to open say each form and then when they are done to have to close 3 or 4 windows. Is this possible? If so how do I do it? On a side note is there a better way to do this. I don't want all my logic on one form. So I don't just want to hide and show and panels.
I keep something I call an application hub that everything goes though.
So each menu click will call the applciation hub, and each form will reference it.
Then, when switching form, the application hub needs to keep track of the current form, close it, then load the requested form.
This isn't much code to write, and performs well.
Or...performance wise, keep the application hub idea, and keep the dialogs open. It will perform better that way, rather than having to reload the forms all the time.
Then on shut down, the application hub can check which forms are open (it should have a reference to each running form) and close them for the user.
Instead of having multiple Forms (inherited form mainForm) you could put the table stuff on UserControls and have total control about their Creation/Destruction/Visibility much easier.
Use an Interface or a BaseUserControl to implement common functionality.
This article, while not exactly what you are asking, was very helpful when I was redesigning a .NET CF application: Creating a Multiple Form Application Framework for the .NET Compact Framework
My application required a bit of both worlds - I wanted to have a single form open, but also sometimes wanted to stack a secondary form on top of the first (eg. if they go to a Prefs page or some other type of form where they should only ever dismiss it after a moment).
(Pseudo-coding after this)
I created a ViewManager and implemented it as a singleton. When the app first launches, I call ViewManager.GotoForm(frm). This sets the current form to be whatever form I need.
Then I immediately call ViewManager.CurrentForm.ShowDialog() - I'm sure there's a better way, but I found I had to call ShowDialog() at SOME point just to get a form to appear.
Subsequent calls to ViewManager can take the form .ReplaceForm or .StackForm. The differences should be fairly intuitive.
What you can also do in a view manager like this is cache forms that aren't being displayed, but probably will be again and have expensive setup costs (for instance, in a data-driven app you might have to query the database to determine the fields or tables to display on a form, and this won't change at runtime).
The trick here is that you never call .Show() or .ShowDialog() anywhere in your application - you route all form navigation through the view manager which handles loading the next instance of your form, disposing of old forms (if not being cached), and dispatching any sort of populate logic if you want to pass new data to a form's UI before it loads.