I am learning multi threading in Win Forms using C# and according to sources the best way to achieve this is by invoking the main method from worker threads.
Now this all works good when heavy processing must be done and THEN the GUI is updated.
However I have a scenario where I need to programmatically add lots of controls inside a panel. This may go up to thousands (panel will be scrollable). Hence, since the controls are ultimately being added by the main thread, the program still hangs until this has been completed.
Is there any way around this? Or should I try and use some other control which doesn't require me to instantiate lots of controls simultaneously (as this is obviously a bit heavy).
Basically this panel contains a list together with an icon (depending on the state). Hence I am creating a label for every entry which I do not know if it the ideal way.
By the way I come from the web applications development department... Is there a control similar to a div in .NET? I looked at a rich text box but it doesn't seem to let you add an image in a straightforward way.
Thanks in advance.
You shouldn't have a good reason to add hundreds of controls, let alone thousands. It sounds like you need a custom control and you need to add items to it.
The ListBox or ListView control will work for a basic item but if you want lots of customizability you will have to reinvent the wheel yourself and draw everything manually. It's a lot of work if you need to handle multiselect, scrolling, keyboard shortcuts, etc.
This is the strength of using WPF instead of Winforms since you can easily use the existing ListBox logic and have free range to customize the appearance of the items and even how they are arranged.
WPF has the concept of a virtualizing panel which can perform well even with thousands of items since it doesn't create the UI objects until an item is scrolled to.
Related
What I need can probably be described as "reverse-anchor", "reverse-dock" or something like that (I have chosen to mention this just because "reverse-anchor" happened to be the first thing to come into my mind as a keyword candidate when searching for questions and answers that might already have been submitted discussing this subject, perhaps this will help people thinking a similar way to find this one in future). WinForms controls implement the Anchor property to set up adaptive resizing on containing control/form size change but I need the opposite - the form to resize adaptively to the controls.
A thing adding a minor bit of complexity to the task is that the controls meant to be added/removed/shown/hidden/enabled/disabled (and resized perhaps - this functionality is not really needed directly so far but I suspect it can turn to be required for compatibility with non-default Windows visual styles and themes that have potential to affect controls sizes unpredictably and can change at any moment of the app running) are not going to be the last ones on the form - a row of buttons will always be in between of the last control of the volatile group and the window lower border.
The actual task is to design a form that will display a collection of objects with a row of controls (a label, a text box and 0-2 buttons) corresponding each of them and it is strongly preferable to use just the very basic "common controls" avoiding grids, lists and stuff like that in this case (wrapping them in an additional container controls like panels is perfectly acceptable though, abstracting them in a separate "user control" can be considered too if this can really make the solution easier, more reliable or otherwise better, using hand-written code manipulating controls and form sizes is perfectly acceptable too (I can hardly expect a "set a magic property and it's done" kind of solution to exist for this task) but I haven't found a reliable algorithm so far (when to change what properties and what formulae to calculate new values with)).
The maximum capacity can be safely limited to something near 10 (or 20, perhaps, but not more - more would be just absolutely unreasonable to display on one form (provided scrolling is not an option)) so both ways are acceptable: to add/remove the controls in runtime or to put them on the form in the designer and just manipulate Visible and/or Enabled properties in the code. By the way I have found a problem with Visible - it gets switched off and back on by the framework internals before the form is rendered and other controls Anchor properties come in the game but I don't think it's a good idea to rely on this to happen always and the same way so just adjusting the form Size property on a control Visible property change does not feel really convenient).
What might be some good ideas relevant to implementing this behaviour?
PS: As far as I know this is a natural feature of WPF but I am to use WinForms to make the app runnable on Macs and, perhaps, other non-Windows platforms with help of Mono.
I'll tell you about some clues may help you:
1- correct to build your own Procedure for manipulating all the matter.
2- i advice to use a Wizard methodology (Next / Back buttons) so if the plate form is small like tablet or smart phone, so the mentioned procedure will decide how many Controls combinations (Label, text box, option button...) will be in each frame of that wizard and keep the remaining for Next button.
3- By the way if you will hide some controls use the original event fires to run the mentioned Procedure. (like a basic button to start the form so don't depend on visible / resize events).
4- Resize the size of each form of the wizard in the last part of the mentioned procedure.
If still a problem exists tell me and i hope i can help :-)
So my problem is this. I have a form with a panel in it. This panel serves as the container for multple different usercontrols, of which only one is visible at a time. Some of said usercontrols display a lot of data from the DB, so loading them takes a little bit of time (the data is shown in a bound datagridview). I tried creating a LoadData-method for these controls that I then launch in separate threads and once they've done their work, they enable the actual buttons on the main form for displaying them.
There were, however, many different problems. First, I can't call this.Invoke on the usercontrol until its handle is created, which seems quite hard to force, especially if I want to show a splash screen during the initialization (the main form's handle isnt created yet).
I did manage to force this by setting the form.Visible = true and then calling form.CreateControl followed by form.visible = false. This does, however, show the form blinking on the screen which doesn't look nice.
I also tried not using Invoke if the handle is not yet created, but this brings me to the problem of my data object being created in a different thread and then not being accessible for the control's "normal" thread.
So as is probably quite obvious, I'm quite lost when it comes to multithreading, especially so with winforms, and even more so at the launch of the application. My explanation might also be rather confusing, but I'll try and clarify if it's needed.
So what is the correct way of doing this?
Hard to know where to start with this.
Can't figure out whether your problems are premature optimistion, or trying to retro fit multi-threading.
If I had say a six buttons and one panel and the buttons flipped a usercontrol in the panel to visible, My thread would return a user control, which I'd then add to the panel and then enable it's related button.
Takes all the synchronisation stuff right out of the equation, and gives you maximum scope for optimistion the getting and setting up of the controls.
Or you could setup all the user controls but not bind them and get your threads to bind on completion, I prefer the former way though, a bit more abstraction and you could get to define a view, mark it up with some useful attribute and just get you main form to kick off a process which would "just do it".
I am working in a Windows Forms application, it needs a lot (and I mean a lot) of controls. Using tab controls to organize them (sometimes nested tab controls).
I was reading how to load the App faster and a lot of people said to think twice if the controls are really needed. Well, to be honest I think that it's possible to reduce the number of controls used BUT the client requested it that way, so there's almost nothing I can do about it.
I was reading that I should use multithreading tactics but there's a hardware limitation: the application MUST run on an average neetbook. It's really a pain because I'm limited in terms of load time and how much space I can use to put the controls.
I was wondering if I can just load one or two tabs before the form is shown and then load the others, would that be possible/correct/efficient? If it is, how could I achieve it? I also was planning to use MDI childs but I need to retrieve all the information in all the controls at some point (from absolutely all the tabs and nested tabs).
Can you please give me some tips? Do you have any experience working on something similar?
One strategy is creating your main page with a TabControl holding empty TabPages.
Then you can design several auxiliary forms (one for each TabPage you require) each containing a single Panel control with Public visibility (change the Panel's Modifiers property to Public) holding the real UI elements that you would have placed on the TabPage.
When the empty TabPage is clicked by the user, then you create the auxiliary Form (you don't show it, just create it), and then access the Panel control in the auxiliary Form, then you can reparent it to your empty tab Page, like this
AuxForm1 frm = new AuxForm1();
frm.MainPanel.Parent = this.tabControl1.TabPages[0];
This will delay the TabPage's control creation until the panel is clicked by the user :)
Hope this helps!
I was wondering if I can just load one or two tabs before the form is shown and then load the others
You could make each "tab" contain a UserControl, and load that UserControl on demand, when the tab is activated. That would, at least, prevent you from having to initialize everything on startup.
"lots of controls" is not a requirement anyone can answer. A dropdown list with tens of millions of rows is a very different problem than a wizard UI with thousands of steps and require different answers.
Why has the client "requested it that way"? We need to know the actual deliverable requirements to answer your question. Have you shown them alternatives?
First, post some of your mockups. If you don't have mockups yet, make some and perform paper testing with them, then post them.
Who's "a lot of people"? Testers? Customers? Anonymous forum posters? Post your mockups to https://ux.stackexchange.com/ and ask for comments.
"I can just load one or two tabs before the form is shown"? Of course you can do that, but why are you presupposing that your UI will be "one or two tabs" before you have shown us any requirements at all? Get requirements, make mockups, then ask specific, answerable questions.
Facing an issue where in the user objects goes more that 10000 in windows app and the app crashes.
After much analysis we realized that we need to get rid of the panels that we use to align the controls and may be reduce the possibility of user objects reaching 10000.
Our App UI is dynamically generated driven by a configuration and it can vary. So all the UI generation is happening dynamically.
Any help would be much appreciated
This is an unfounded suggestion, but remember to make sure that unneeded Controls always detach themselves from events they are be subscribed to. A Control that's still subscribed to an event of an "active" (what's the right term?) object can't be cleaned up.
Just as a note, the Chrome development team hit this problem too, and the scroll bar arrows (among other things) weren't drawing anymore when some internal gdi limit was hit. It is quite possible to hit this limit in a complex enough gdi app.
You might want to do some research and see how they fixed it.
As an alternative, you could consider using a different platform, either gtk or wpf would do fine and they don't use gdi handles to draw.
from here,
If your program runs haywire, you will
find that it manages to create about
10,000 window manager objects and then
the system won't let it have any more.
Why stop at 10,000?
The first answer is "If you have to
ask, you're probably doing something
wrong." Programs shouldn't be creating
anywhere near ten thousands window
manager objects in the first place.
There is no need for that many handles. I think you need a new solution.
I'm guessing this from your question, but you're probably putting this large number of controls on a scrollable panel or a tab control with multiple tab pages, which means that most of these controls aren't actually visible to the user at any given point in time (because they couldn't possibly all be visible at once).
If you have all of these controls on a scrollable panel, one possible solution is to only load and display the controls that are on the visible portion as the user scrolls around in the panel. As the user scrolls, you would unload and dispose the controls that are no longer visible.
If you have all of these controls in a multi-page tab control, you can use a similar strategy and only load the controls on a tab page when that page is made visible (and unload the controls from the previous top-most tab page at the same time).
Another general strategy is to break up your one monster form into a large number of UserControls, and only show one of these UserControls at a time.
I'm writing an application that needs a log-like view, (similar to how an IM client displays messages in the conversation), with potentially many updates per second. Speed is an issue here; the application locking up due to a large number of incoming events is a possible problem. I need selection and basic text formatting, so manual rendering could get quite complex, I'd like to avoid it if possible. I'd also like to bottom-anchor the scroll bar, that is, if it's at the bottom, stay at the bottom when the new item is added. What would be a good way to implement this?
You can implement it very easily in WPF.
Create an ObservableCollection of Log entities and bind to a ListBox.
Give a DataTemplate for the ListBox.ItemTemplate.
*When running in real time you need either UI side or Data side virtualization
Check out my PaginatedObservableCollection so that the DataVirtualization will automatically function.
I think you should have a look at ListView/ListBox controls, they support UI virtualization and provide functionality you're looking for. Also you can improve performance by data virtualization/lazy loading - i.e. don't hold invisible items in memory and load required data on demand