>Back in 93' I was consulting for a national CS firm in ceder rapids, IA. We were developing a VB3 app that contained a *lot* of controls and a big pageframe. When the number of controls reached around 300, various controls would randomly stop working, usually following a compile. These were controls on parts fo the app that had been developed weeks prior and debugged. Strangely, merely replacing the control with a new one, with the exact same PEMs, fixed it. I researched this problem at that time and found that it was a known 'bug' in VB caused by the app reaching the limits of the GUID memory space.
>
>About two years ago, I was assigned an app that is presently the largest VFP app in the dept. As the app reached about 500 controls, I started experiencing the same phenomena, and using the same fix. Rather than repeat that prior experience, however, I decided to break the app apart. It now consists of 19 separate executables (project files), even though many use the same tables in various ways. The problem of spontaneously corrupting controls vanished and hasn't reappeared.
>
>I am alone in this experience, or have any of you folks experienced the same phenomena of controls that worked well since installation suddenly begins misbehaving, only to be repaired by an identical (but fresh) control with the same PEMs?
Jerry,
Thanks for sharing this knowledge, I am wondering whether I have run across the same beast in one of my applications.
In my case there are lots of forms, with controls that don't amount to much on an individual basis, but putting it all together the number does mount up.
Did you conclude that it was the total number of controls in the application or was the problem because of one huge pageframe.
I find my users like Pageframes and it is tempting to make them BIG, rather than use a large amount of Forms with lots of Menu selections to get to them.
So do you think that the "limit" that you discovered way back then is still biting because of the Pageframe's.
Regards.