I am converting a Visual Basic project whose screen has a great many controls on it. There are buttons, text boxes, and labels. These are necessary to manage the display of a graph plot and summarize certain details of the data. There may be 40 or 50 all told. This means that the control list in the IDE is very long, and every time there’s a program break, all of the controls are expanded and I have to scroll through a long list to find what I need. I don’t seem to be able to insert a Folder within the Controls section, so I could (for example) group and conceal all the Labels.
Is this correct? Is there any way to compartmentalize a big list of Controls into subsections?
Convert them to CONTROL SETS (where appropriate), then the IDE will automatically group those
This will require you code to be altered… but it is probably best to refactor it this way if you have so many controls.
Each Control Set would contain those controls that are “similar” in function.
FYI… This was a concept that VB supported as well, I just don’t recall what they called it.
We tend to use Container Controls. Generally controls are grouped into logical function so it makes sense, to us at least, to do it this way. So each container has it’s own load/save/validate methods.
That way the parent window/container doesn’t really need to know about the individual controls. We find this results in much cleaner code and the IDE Navigator doesn’t get clogged with a bajillion (the technical term) controls that you generally don’t need to deal with on a regular basis.
To each their own, but control sets, or control arrays if you will, tend to cause issues from our experience. You spend more time worried about their index then you do about their function. My other beef with them is that unless you use constants for the index you can’t tell what the function of the control is by looking at the name in code.
Control sets can be useful where you have many of the “same” controls. Imagine for example a sales order screen. You will have many item lines, each with a quantity field, a material number field, a description field, a price field, etc. Control sets could be used here, where the index corresponds to the item line. Control sets should not be used to group controls that have different purposes. (as Bob’s example shows)
Yes, certainly more readable, but in VB6 there control sets used less resources, and that was a big deal under earlier versions of Windows (where many VB6 programs got there start). Some of my screens in Xojo have control sets for the simple reason, that is how it was in the original VB6 program I converted. Is naming them their own individual name not a resource issue that you have to think about in Xojo?
There probably is some upper limit but I’ve never come across it. The more controls you have onscreen the slower the layout editor is and I don’t think that control sets change that much (but I am willing to be wrong on that one).
I worked on one project (in Real Studio not Xojo) that was a VB6 conversion. It was a one window app that had something in the neighborhood of 1200 controls between all the various tabs and page panels. It was a nightmare in VB6 and I doubt the damn thing ever really worked right. In Real Studio, those 1200 controls got split out to 20 or so major containers and perhaps another 10-15 smaller containers and the layout editor didn’t even blink.
The parent window never had to load/save from the individual controls since the containers handled that. It encapsulated the UI beautifully by function and, when adding ActiveRecord into the mix, the project took no time at all. And the code was very readable and simple to update. The hardest part was reading the VB6 code to convert it to RB. They used control arrays with no constants, and they used default control names. I probably spent more time fixing the VB6 code so it was readable than I did in Real Studio.
Just my two cents worth. I’ve converted a lot of VB6 projects.
I have nothing along that order of magnitude, so I think I will change the names. It does get old trying to remember which field CustomerDetail(4).Text is.
I’ve been encapsulating controls on a canvas because the canvas attaches to a window splitter so easily, and this setup really smoothes out the redrawing of a screen. It doesn’t help with the flicker much when moving/resizing windows, but it does help the whole screen redraw at once making it appear a smoother transition when switching from screen to screen, much more like it does on the Mac. Without them, I’m always having issues with different ListBoxes popping up at slightly different speeds depending on what was loaded from the DB. I’ll have a look at the container controls again and see if it is a better solution. Thanks for the tip.
Logically group your on-screen controls into different containers and place them on the main window. These will attach nicely to splitter controls and they are much easier to handle and maintain than canvas controls.
I concur that Container Controls are the way to go here.
Each to their own, but I wouldn’t use Control Sets for the sole intention of cleaning up the Navigator, unless I had lots of labels that I was never going to reference in code.
[quote=89796:@Merv Pate]I have nothing along that order of magnitude, so I think I will change the names. It does get old trying to remember which field CustomerDetail(4).Text is.
[/quote]
Hence Bob’s other recommendation IF you DO use controls sets define constants so you get
CustomerDetail(kLastName).Text
so you don’t have to remember that CustomerDetail(4).Text is the last name
Thanks. I think I am just going to remove the control sets on some of the screens. Really no reason for it other than it was that way in VB when I converted the program 4 years ago.