I'm working on a Windows Phone 8 app, which is basically a port of my existing Silverlight app. On one screen in the SL version, I have 10 ComboBox controls that default to nothing selected, forcing the user to make a selection before saving the item. That works great (this is my company's bug tracking application, so I want the users to be forced to make these selections, else they'll leave in a default, which will likely be incorrect).
In WP8, the powers that be seem to want us to use their ListPicker from the WPToolkit (since there is no ComboBox there or in the default controls). However, this is more a ListBox that supports SelectedIndex but not SelectedValue and SelectedValuePath. I've been using an index property in my viewmodel(this is kind of a pain since the model loads async, but I've been working around that..), but I have to default it to an actual option, which negates the business rule of forcing a selection.
I've also tried essentially copying the source code for ListPicker and have it inherit from Selector (the base control just inherits from ItemsControl), but that won't work as the Selector constructor is internal.
It seems like what I want to do is add support for SelectedValue and SelectedValuePath. Is that possible? Or am I going about this the wrong way?
Related
Let's start with a confession: I came from a VB6 background, and I'm accustomed to coding within the events of objects on a form, and as such my code for events ends up in somewhat random order in the code window. With this habit, it's never been very important to remember the names of controls (although I name them well)... I just double click on a button in the design view, which brings me straight to the code for that control's primary event. If I forget the name of a control, I click it and view properties. It's not a habit I've moved away from.
Well, now this is catching up to me. Using VS Express 2013, I have a form that contains a HUGE number of containers-within-containers, labels, buttons, and other doohickeys. I ported my code from VS.NET Express 2008 where this wasn't a problem. But now the act of selecting any control in the design view takes around 10 seconds before I can view its properties. If I drag to resize a control, and another 10 seconds passes before I can select another control. It makes designing this form nearly impractical.
In this particular project, I'm using use a tab control (which is never visible to the user) to design many "screens" which each contain panels full of controls. The panels for each "screen" are moved out of the tabs and docked into the main form as requested by the user changing screens. (I'm using the term "screen" to mean a window full of controls, usually maximized.)
Within the same project, a simple modal password-change form isn't slow to edit controls visually, even if the complex form is still visible in the IDE.
My question is in three parts:
First, what the heck is it spending all that time doing?
Second, is there a setting I can tweak to improve the speed?
Third, should I give up on trying to speed it up as-is, and move each "screen" into its own form for design purposes to avoid this slowness? (It's a lot of work to do that now... see next paragraph.)
Thus far I have avoided separating "screens" onto separate forms because I don't want a new window to come up when users change screens, and because code for the controls in one screen may affect the properties of controls on other screens... In such cases I prefer not to write out
form.doohickey.text = "blah"
..but rather keep it as ...
doohickey.text = "blah"
I'm using VB but I don't think this question is VB-specific.)
First off, I feel your pain. I have a management section of the application that I'm writing and I'm using a TabControl as well. I have 10 tabs so far and I've only added controls to about 4-5 tabs. I just added up the controls I have and there are about 360 controls so far on this one form and the designer file is ~3300 lines long. Currently anytime I change a property value of one of the controls or go to save the Designer, it takes about 3-4 seconds each time. I have a fairly decent machine; i5-3320M, 8GB RAM, intel 330 SSD, and it still takes a bit for it to do things within the tabControl. It also takes FOREVER to open and load the designer on that form...
What I've found is that it is easier to open a new instance of Visual Studio, create a test application, add a TabControl with the same properties, and design a new tab page from there. When I'm done I do a copy-paste into my actual project. This works great except for the few custom controls I've written in my main application project, I just have to sit and wait while adding them.
I'm now answering my own question. This is the approach I've ended up using, and it helps a lot...
My overall goal was to have an interface that didn't present a lot of windows, but still presented many different "screens".
I used to place all the different controls of different "screens" on separate panels, which were each contained in separate tabs of an invisible TabControl. I would then move those panels to my main form as needed by changing their Parent property of each panel as needed. The only problem with this is that the Winforms designer got ridiculously slow as the number of controls on a form increased into the hundreds.
Now, I am now designing each "screen" as a separate form, each of which contains a panel whose Dock property = Fill. Such a panel contains everything else on the form. The form itself never becomes visible.
As needed for to view various screens, I execute:
ScreenForm.Panel1.Parent = Mainform
...or, depending on how I lay it out...
ScreenForm.Panel1.Parent = Mainform.PanelXYZ
...I also either unload or hide any panels which already exist in the panel's new container.
I was GLADLY SURPRISED to find that the code for the various events of the controls contained in the panels would still run, because such code exists in the first form's file, not the displayed form's file. Luckily, it seems I was wrong. Event code follows the control itself. I can copy/paste not only controls, but also their corresponding event code to new forms for easier development and a faster Winforms designer.
All of this is similar to a MDI interface with maximized windows, but no title bar or [X] is displayed.
Essentially I'm doing everything as I did before, except using separate forms with panels instead of separate tabs with panels. The WinForms designer is much quicker because there aren't so many controls on any form.
I think I accidently found a workaround for saving a lot of time when changing the name of a control on a overpopulated container/project. Before you change the name, toggle False/True the "Generate Member" property of the control you want to rename(I believe you can also locate this under the "Name" property). This adds a few more clicks to the procedure but saves a lot of time. My not-yet-finished project has over 4000 controls and multiple forms and some of them are very "heavy" (10 - 20 seconds to normally change the name of a control). This, of course, don't help in anyway with the loading time of the project (about 35 seconds for me) but I can live with it. Let me know if this works for you too.
I am writing a Windows Forms application in VB.NET. I have three forms: the main form, which shows a list of accounts, the account form which allows the user to view/edit the information for a specific account, and the policy form which allows the user to view/edit the information on a specific policy for that account. I want the forms to appear as if they are all the same window. Example: when the application starts, the user clicks an account name in the list box on the main form and clicks "edit". What I want to happen is that the window stays in the exact same place and stays the same exact size, only the content of the main form appears to be replaced with the content of the account form. Same thing if the user then chooses to edit a policy from the account form. When the user finishes and clicks "save", the main form comes back up. Through this entire use case, it would appear to the user as if they were viewing the same window the entire time, with the content of that window changing.
How can I do this? I have tried something like:
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.Show()
Me.Close()
The problem is that if the user moves the original window, the new window appears where the parent form originally appeared, not where it ended up.
I see this is already in the comments, but what I have done in this case in the past is build each "form" in the application as a custom control. Then I have one actual form, and navigation works by changing which custom control is currently loaded on the parent form. To move from one screen/view to another, you remove the current custom control from the form's controls collection and add the new custom control.
I believe this is superior to manually setting the startup position and size, because you can use the form's .SuspendLayout()/.ResumeLayout() methods to hide the interim state, where there is no control loaded, from the user. This is harder to do when you want one form to be completely replaced by another.
This also makes it easy to set certain form properties in one place and have them be consistent for the application. You can even have an area on the form with controls that will now show in every view.
When using this pattern, I typically have each of my custom controls inherit from a common base. You may not have anything specific you will do with that base at the outset, but it almost always comes in handy later.
Finally, switching to use this scheme is easier than you think. Just go to the code for the each of your current forms, and you will find that each class currently inherits from System.Windows.Forms.Form. Most of the time, all you really need to do is change them to inherit from System.Windows.Forms.Panel and you're most of the way there.
As others have said, it may be better to redesign your application using custom controls or panels etc.
However, to answer your question regarding the seemingly random location of your forms, the first thing to check is that each form has it's StartPosition property set to Manual.
If your main form is resizable, then I would also add code to adjust newForm to the same size too.
I hope that helps with your immediate issues; so that you can move on to redesigning the application!
good morning there is another way . set property for second form to (top most) and use also
from2.show();
that make you switch between forms and keep form2 top other
Thanks
try using ShowDialog()
Dim newForm as New AcctForm
newForm.Location = Me.Location
newForm.ShowDialog()
Me.Close() <-- removed this
I am new to Visual Basic and trying to get around in developing a good gui for a chat interface. I can understand the language as i have been using php and java from quite sometime.
Requirement
Basically i am trying to develop a interface which will show a list of users and along with that display a status (online/offline). My users will reside in mysql database. On clicking the user i want some actions to happen.
Question
I see there is datagrid, listview,listbox but not sure which one to use. Also is it a good idea to display the users by directly quering the mysql database or by accessing a php script which runs few queries and gives the data?
The ListBox control would not be a great option since it doesn't easily support multiple columns. The ListView control in Details view is a great option. I think it looks and works nicer than a DataGrid, but it doesn't natively support multi-line items. If you need multi-line items, the DataGrid control may be your best choice. Another option, which would give you more flexibility, would be to use a LayoutPanel control to display a vertical list of your own UserControl. You could design the UserControl anyway you want meaning you could fully control the size, look, and layout of each item in the list without being constrained by the list control.
As far as getting the data, that depends. If the database is always on the LAN and performance is important, then each client should go directly to the database. Otherwise, getting the data from a php script, web service, or WCF service would be a much better choice.
Rather than using the TableLayoutPanel, I would recommend using the FlowLayoutPanel with the FlowDirection property to TopDown and the AutoScroll property set to True. Then, to add a control dynamically, you could do something like this:
Dim item As New MyUserControl()
' Set properties of user control
FlowLayouPanel1.Controls.Add(item)
I use the VisualStateManager-Element to re-locate some XAML-elements on my page based on the current Visual State.
My problem is that I use a gridview which has to become a listview when the window is snapped (because of the small horizontal space left). I bound some other elements to the gridview's selectedItem property. My first approach was to create a listview and show/hide it based on the visual state. I would need to update the binding of my other elements as well though ( from gridView.selectedItem to listView.selectedItem) which is apparently impossible in the visualstatemanager. Another possibility would be to change the binding from code behind.
Are there other solutions (preferably in XAML)?
I think the generally accepted answer would be that you should have a piece of xaml per visual state. You collapse the one that is not currently in use. You would only make changes or create bindings manually if you were going to do something that required a dynamic number of bindings or something similar. In this case you have a fixed set of bindings to a known set of UI elements, so you would simply setup all the bindings in xaml.
Looking for a free spell checking solution, I thought I was so smart in doing this but I guess not.
I have created a windows form based application and I want the form to add a user specified amount of user controls (with textboxes) on to a panel. The user can then click some button and the controls on this panel are cleared and new ones are added. The user does something and the process is repeated. Now, I wanted these textboxes to support spell checking and looked all over for a free solution.
WPF textboxes support spell checking where the ones in regular win forms do not. I thought I would be able to use these WPF textboxes by adding them to an ElementHost object which is, in turn, within a panel. This panel would be a user control.
So, in my application, I would be able to add instances of these user controls onto the form and make use of .NET's spell checking goodness. This actually worked but after using the application for a while, found that the application would eventually freeze on me due to out of memory errors. I have pinpointed the memory errors to these WPF controls since this problem does not happen with normal textboxes.
When the window is opened and the number of controls is specified, this is pretty much how the controls are added:
Dim xOffset As Integer = 0
For i As Integer = 0 To theNumber
Dim myUserControl As New SpecialUserControl()
myPanel.Controls.Add(myUserControl)
myUserControl.Location = New Point(7, 7)
myUserControl.Location = New Point(xOffset, 7)
xOffset = xOffset + 207
Next
Note that:
myPanel is a panel on a form
SpecialUserControl is the user control with WPF textbox (within an ElementHost object)
When the user pressed a button, the panel is cleared:
myUserControl.Controls.Clear()
The user can then repeat the process.
There are a lot of results on the internet when I tried to find a solution and I'm thinking that the problem I am having is due to the fact that the WPF control is not going away even after clearing the panel. Following this conclusion, I have tried different solutions regarding disposing these controls or setting them to nothing but the memory problem keeps occurring. If someone could give me some advice or ideas here, I'd really appreciate it.
I've decided that this may just be due to the fact that these user controls are being created faster than they can be collected. I've changed the program so that it doesn't create any of these special user controls if it isn't necessary. The program works fine with a more manageable number of WPF controls.