Designer.VB Problem {Removing controls}

07-25-2007, 12:41 PM
Good Afternoon,

I have a form with about 150 comboboxes and just as many labels.

When I use the properties list to access my controls i get a list that looks like this


the cbxxxx are the names that I gave the comboboxes AFTER I added them to the form (I changed ALL the names of the comboboxes, there are none left with the combobox name, I verified this by going control by control and clicking, checking the name), ALL of the comboboxes changed thier names and some left the OLD combobox name in the Designer.VB, also the labels "seem" to have replicated also.

The program operates and functions just as normal - and the events fire using the cbxxxx names so it looks like VS2005 didn't process the name change properly...

This is just an annoyance at this time.

Is there a way to "clean" the designer.vb file of those controls that aren't needed? Or do I have to hunt through there and "clean" it myself?

07-25-2007, 01:01 PM
This is unrelated to your question, but I'm curious as to what sort of design requires 150 comboboxes? I understand the need for labels to complement them, but as-is, you're pushing 300 controls on a single form? That's a lot of clutter that may be better off handled programmatically (which would then potentially fix this "cleaning" issue, as it would be moot.)

07-25-2007, 01:19 PM
The controls are spread out over the course of about 8 tabs on a tabcontrol.
I also have some controls that are created programatically. It is a rather large form and I struggled with layout and design (MDI, Seperate forms, etc...) and concluded, for the end user a tabcontrol setup was the best choice.

Also if you have other ideas on how-to "house" 200+ controls feel free to chime in. I tried MDI and it didn't work properly, it felt bulky and I thought that it was not the cleanest way to approach this. I also created some controls at runtime, which is OK but add handlers to EVERY control is time consuming and at times confusing, the tabcontrol was my choice (due partly to time contraints).

This application is for an inspection that has to be performed, then recorded and printed at a later time. There is about roughly 200 inspection criteria (Not including those that replicate) some of which are check boxes, some are comboboxes, some textboxes, and others I created dynamically, any suggestions on how to approach this are also welcome.

Thanks for your quick response.

07-25-2007, 03:09 PM
Having that many controls on a single form is bad news, period. There's a limit to the number of window handles that can be assigned at a time, and though you aren't approaching it each control ties up resources and I imagine the Form is a pig for both performance and maintenance.

If you want to replicate some kind of tabbed view with this many controls and maintain your sanity, you're going to have to take a more dynamic approach. Here's a neat little idea I just thought up. I'd make an example but it's a little too involved for me to justify doing it at work.

First, you make a data structure that is capable of holding all of the information necessary to populate the Form; I'd recommend something like a container class that is made up of several smaller objects that encapsulate the data from a single TabPage.

Next, for each of the current TabPages, create a new class that derives from TabPage and arrange it how you like it. The designer doesn't seem to work with things that derive from TabPage, but you can cheat by designing the TabPage on a Form then copying the stuff from InitializeComponent() that sets it up, it shouldn't take too much modification. Also it's possible you could have each page start its life deriving from UserControl and at the last minute change it to derive from TabPage. Ideally you would do research to decide exactly why UserControls and Forms can be rendered by the designer and copy that functionality; my guess is they implement some interface that TabPage doesn't, but nothing stops you from doing so.

Now the only things you need to add to the new class are the following: A constructor that accepts the data needed to initialize the form; it will call the initialization logic and set the value of each control. A method that checks the value of each control and returns an object that represents their current values.Now, with this framework in place, here's the way the program works:

At startup
Before the form loads, instantiate the first tab page and replace the TabControl's first tab with it.

When the user switches tabs
Call the method to get the state of the current tab and save it. Instantiate the class for the new tab page. Replace the tab's current page with your custom one. Call the previous tab's Dispose method and be sure to replace it with a blank one.This approach is a pain during the design phase and does not handle rearrangement of controls very well. However, the benefit is that at any time, only the controls for the current tab page are consuming resources, and the logic/behavior of each tab page is compartmentalized within a single place. When you need to change a label or add a text box, you can go to a page that has maybe 10 or 15 controls rather than trying to keep up with several hundred.

I haven't ever done this, nor have I even tried a proof-of-concept, but I can guarantee you that pretty much any method that involves dynamic control creation will save you a lot of tears.

07-26-2007, 03:18 PM
if its for an inspection, couldn't you create 1 control of each kind and just change the label to it as each question is answered? have all the questions or inspection points in an array and loop through it and the current one is the one thats being asked for, and then the result is passed into an array which will contain your answers

of course, thats assuming that there is a set order, and you'd have to code into each event to move to the next question when something happens..

i dunno, just a thought

07-26-2007, 06:26 PM
I haven't ever done this, nor have I even tried a proof-of-concept, but I can guarantee you that pretty much any method that involves dynamic control creation will save you a lot of tears.

I am under a time constraint so, at this point, re-doing the entire app with the way you described (which would take some time to do) is not currently an option. I would like to keep this in mind for a later build, (nothing like RE-CODING an entire application after its released!) ha ha... AtmaWeapon - thanks for the in depth explination.

of course, thats assuming that there is a set order, and you'd have to code into each event to move to the next question when something happens..

Thats the problem it isn't in a set order - the inspector could choose any number of starting locations and randomly pick another zone to inspect... Thanks for the suggestion though..

07-26-2007, 08:09 PM
Ouch, yeah I guess you're just going to have to slog your way through it this time; time constraints are a pretty big deal and sometimes getting something that works is the most important.

Sometimes doing a UI redesign can be refreshing though; if you do enough of them you learn solid lessons in putting logic outside of the UI and it can make it a lot easier.

07-26-2007, 08:42 PM
One Idea (If your inspection criteria allows it) would be something like this (This is the way I did an inspection form when I was doing inspections).

Create a main form will buttons for the different inspection areas (or groups)
Then have each button open a form with the data sheet for that area. When they close the area form then they can select another area.

Again this may not be feasable with your inspection areas. But if you have say 20 areas and each area has 20-30 inspectin critera it may be agood way to go.

Just a quick thought.

EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum