Answer of: The 256 controls problem / a Visual Basic 5.0 bug 
Author Message
 Answer of: The 256 controls problem / a Visual Basic 5.0 bug

The 256 controls problem / a Visual Basic bug
------------------------------------------------------------------

Since it seems that many people were interested in this problem, I thought I
should write something about the solutions I was given (you can read the
original message at the end of this one).

First of all I want to thank all the people who tried to help me. I recived
quite a lot of mails, along with the messages posted in the newsgroup.

It seems that many people just couldn't understand why should I create such
a big form. It is not that I want to create it but I must do it, as my
customer wants all the data related to his customers to appear in a single
form.
Knowing this, let's find solutions:

1. The Visual Basic suggestion.

When you have 256 controls in your form (and the form is also a control),
and you want to insert the 257 one, Visual Basic tells you that you have
reached the limit and if you want to add more you must have your controls
joined in control arrays. If you then edit the controls in your form and you
join them in arrays, Visual Basic will allow you to have much more controls.
In fact, having your controls in this way works, but you must be carefull
because it could/should (will???) happend that from one day on every time
you'll try to open the form Visual Basic will crash. Amazing, isn't it?

2. The dirty solution.

I use a tab control, and someone suggested me to remove that control and
create a form with a button for each tab. When you want to change the tab,
you just need to click a button and a form will appear.

3. API forever.

One of the most shocking answers was the one from someone who had worked
with a form which had over 700 controls. He suggested me to use the API. I
agree that must work, but I should probably spend too much time making it in
that way. Thanks, anyway.

4. Eating resources.

Another person was completly sure that I was out of GDI / system resources.
He told me to check that in the My Computer -> Properties. I have done it an
d I am not mistaking if I say that I have never been below the 70% of the
system resources. I work in a P300 with 128 Mb of Ram. That may be the
point.

5. Editing the form manually and removing controls untill you can open it
again.

That may work, I haven't really tried that. This is obviously the solution
to keep at least a part of the work you did.

6. What about the FRX files?

Someone called Steve told me to remove manually all the references in the
form to the frx files. While I was waiting for the solution of the big form,
I started to develop another form, not so big but yet not small. One of the
times I pushed the save button (to save the form), Visual Basic crashed. I
was frieghtened, but I did something simmilar to what Steve suggested me: I
made a copy of the original form and its frx file, and afterwards I removed
the frx file. When I opened the form again in the Visual Basic editor, it
told me there were errors, but it opened it (I think the form lacked one or
two controls, that was all). I just needed to save it to make the editor
create the binary file again. That fixed the form.

However, I haven't still found what's really happening. Amazingly, these
last days I can open it, though Visual Basic crashes from time to time...

     Oriol Quinquill Capdevila,
     E.T. Informtica de Sistemes


The original message was...

I'm trying to create a big form with over 350 controls. The only way to do
that is using control arrays.
The fact is that while there was less than 255 controls everything was all
right, but after the first time I reached that figure, every time I have
tried to open the project Visual Basic just crashes.
Does anyone know why and what can I do?
I'm using Visual Basic 5.0.
                                        Thanks.



Sun, 04 Feb 2001 03:00:00 GMT  
 Answer of: The 256 controls problem / a Visual Basic 5.0 bug

Quote:
>The 256 controls problem / a Visual Basic bug
>------------------------------------------------------------------

-------------- S N I P --------------------
Quote:
>It seems that many people just couldn't understand why should I create such
>a big form. It is not that I want to create it but I must do it, as my
>customer wants all the data related to his customers to appear in a single
>form.

I still don't understand it. How can your customer tell whether it's one form or many? As you say
below, you have tabs. That is MULTIPLE FORMS, in a way. Therefore, I would split my 1,000 controls
across 10 forms without the borders and captions (or with both, but having identical captions) and
just display them in turn.

Quote:
>Knowing this, let's find solutions:

Well, OK... But there's always more than 1 way to skin a cat, as an attempt was made above to
demonstrate.
Quote:

>1. The Visual Basic suggestion.

I doubt the necessity of crashes, if: (a) you load your arrayed controls at run time and position
them in your code (the downside of this approach is a slight performance degrading) and (2) you
chose your controls carefully, making as much use of "non-hWnd" ones as possible (here I mean using
labels instead of textboxes and images vs pictureboxes. Also, get rid of "heavyweight" controls like
SSpanel.

Quote:
>2. The dirty solution.

Another dirty (hmmm...) solution would be using some kind of grid control instead of numerous
textboxes. Sounds a bit *unstandard* (huh?), but in some cases manual insertion of values into cells
may be better than loading, positioning and populating 287 textboxes or so.

Quote:
>3. API forever.

I agree here. Unless you have all the code written in advance, this approach may require lots of
time.
Quote:

>4. Eating resources.

May be quite an issue, since once your client has as much control as to advise you on the number of
internal programming environment objects, it might well be requested that your app runs on a 286.
So, I agree here again.

Quote:
>5. Editing the form manually and removing controls untill you can open it
>again.

This reminds me of an approach of creating a table in a database containing two fields: table name
and record count. Then, a simple SQL statement would let you avoid using SELECT count(*) FROM
<tablename>. But... there's always an ass... I mean, a butt.. (Have I spellt it with two t's again?
Sorry)

Quote:

>6. What about the FRX files?

Yeah, these are a PITA... But I wouldn't advise just randomly or consistently getting rid of those.
Way back, in VB4, I once got rid of a frx for my form with a TrueGrid on it. That was still a
greater pain ... yes, you guessed correctly where.
Quote:

>However, I haven't still found what's really happening. Amazingly, these
>last days I can open it, though Visual Basic crashes from time to time...

If MS says there's limit to a number of something, I'd rather try not to exceed it. In fact, I would
be very cautious even to approach it. Who cares why? I wish, the product works correctly with all
the limitations observed, because you know WHAT we are bound to work with. In every application I
have enough bugs of my own to take care of, let alone those imposed on me. So, I am not interested
in knowing Why in this case. It's like your client. But much worse.

Thanks for going this far with me. And have a good day. :-)



Sun, 04 Feb 2001 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Visual Basic 5.0 Small 256 icons?

2. Looking for differences between Visual Basic 5.0 enterprise and Visual Basic 5.0 Profesional

3. A Visual Basic 5.0 bug

4. Can I use Visual Foxpro 5.0 and Visual Basic 5.0

5. MS Visual Basic 5.0 *BUG*

6. Calling Visual C++ 5.0 DLL Functions From Visual Basic 5.0

7. Visual Basic and 256 Colours, HELP!!

8. Visual Basic 5.0 bug reports.

9. loading visual basic 3.0 applications in visual basic 5.0

10. Visual Basic 5.0 vs. Visual Basic 4.0

11. Problem Using Animation Control in 256 Colour Mode

12. BIG PROBLEM!!! PictureClip control and 256-color mode

 

 
Powered by phpBB® Forum Software