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.
Related
This might just be a small quirk. But I've built a small windows form application with multiple tabs.
I have a feature that allows users to "load" the entries in each of the tabs by opening a json file. This lets them avoid manually inserting the data. At the same time, I have a "check" to make sure that all required fields have been populated.
What I've found is that even if the load process is successfully populating all the right fields, the user still needs to select each tab (even though they are already filled), in order to avoid hitting the flag.
Hopefully, this makes sense. Right now, my work around is to have the program flip through each tab automatically upon "load", but it seems strange that winforms can't detect a text box has been filled unless the tab is viewed.
Any advice?
Some events only fire when the control is visible. This sounds like what you should do is decouple the text entries from the control and store them in another object which fires off the filled events then do data binding to those entries.
This has the nice benefit of decoupling the UI from the data storage (always a nice thing) as well as freeing you from the vagaries of the .net UI system (both winforms and wpf have 'interesting' quirks like the above which assume specific behavior preferences).
This is my current setup:
I have a WPF app that has a copy button which takes a applications directory and copies it to another directory. After this is finished, I have another button that launches the app from the new location. Ideally, I would like to just have 1 button where after the copying is done, the button's text changes to "Launch" and when clicked it would Launch the app. The user will however need to be able to do a re-copy by clicking the button again, but this time, it should say "Copy". Is this possible and even worth it?
The easiest thing would be to store a state in a variable accessible from your code-behind, and have an if statement in the button's OnClick deciding what to do.
It is probably not worth the trouble, as buttons that change their meaning may be confusing to your end users. I would do two separate buttons, but I would conditionally enable or disable them, based on the state of the application. When copying is the only action that makes sense, the [Copy] button would be enabled, and the [Run] button would be disabled. When the state changes, so would the enabled/disabled status of these buttons. This would give clean visual cues to the end users of your application, and make your application easier to test automatically with various UI test automation tools.
It's definitely possible, but it seems far simpler to have two buttons. You could just toggle their visibility depending on your current state, so the "Launch" button is visible when you want to be able to Launch, and the "Copy" button visible when you want to copy.
This would keep your commands simpler (each command does one operation).
One way to do it would be to use a RelayCommand and then have an if statement that calls the appropriate function. The RelayCommand was defined here.
I would create two CommandViewModels which should contain a Command and Header. You then could have a property containing such a model and the Button.Content would then be bound to the Header of the current CommandViewModel and the Button.Command would be bound to the Command. You then just need to change that property to the other CommandViewModel. (This could even be done from within the first Command's Execute.)
I have a TabControl containing Prism regions. I want to trigger some kind of notification (e.g. flashing the tab header) for certain events, and I want to trigger this notification from the components in the Prism regions.
Once the tab containing such a component was open once, this works nicely using VisualTreeUtil.GetParent() and going up until I find my TabControl and can modify it to indicate the notification.
But the problem is that this doesn't work until the tab is opened by the user because VisualTreeUtil.GetParent() returns null; obviously because Prism doesn't hook up the visual tree until then.
Calling UpdateLayout() on the TabItem containing the region doesn't help. I don't want to open the TabItems programmatically, because this would confuse the user.
Is there anything I can do short of implementing a kind of region registry (which would be rather ugly and harder to maintain)?
If you want to look at code, I wrote a minimal solution to demonstrate the issue. The Print Structure button tries to go up the visual tree from the (initially unrendered invisible) hello TextBlock on the second tab. Before you switch to the tab it prints only the TextBlock, afterwards you get to the root of the visual tree. This is what I want to accomplish without switching to the tab.
Adding comment as answer:
This probably isn't exactly the answer you are looking for, but it seems like you're taking a very procedural approach.
Have you considered using an MVVM approach? Each TabItem in the TabControl can have a HeaderTemplate. In the template you can bind to a property in the ViewModel that causes the tab to flash or change appearance
Hm.. IIRC Prism regions are just a configured ContentControl/ContentPresenter. Once they are ready to work, all the bindings and datamodels should be in place, but the trees are left not created because they are invisible. If so, you should be able to call ApplyTemplate() on them to force it. I do not remember, however, if the Prism assigns the contenttemplates/datacontexts upon init, or upon demand - the latter may cause calling ApplyTemplate useless.
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.