Yeah, I understand - wading through never-ending error messages is a monumental pain in the fundament. I'm not sure why it's misbehaving like that, although I suspect it's a language problem - it works flawlessly on all machines here, but they are all running a Czech OS and Czech Office package. The non-Latin characters used in the Czech language have a tendency to wreak havoc in English-only machines. It also may be something in the ribbon - that is full of Czech characters, and sometimes XML parsers are very fussy about that.
The red background is obnoxious on purpose - if I leave it tolerable, the user has a tendency to keep on using it, even after it throws an error, which can be bad. It may have lost some global references, which may mess up displayed results - it could show some results, but maybe the wrong ones, since a global variable may have been reset, or a class reference cleared and re-initialized, without the display properly reflecting the current status. You know how it is when code wanders off on its own - no telling what condition it's in, or what it's likely to do. This is irritating enough to keep her from doing that.
The proc names are for my entertainment, when developing. Easy to find and identify when testing. I dress it up before shipping, though.
In any case, I think I have a plan of action. I'm going to run a few more tests for various limits, but mostly just to get a general idea of what I can get away with. I'll post the limits here as I encounter them, just to keep the information in one place, in case someone else runs across this and is curious. I'll take a look at tweaking some of the settings you mentioned, but I don't want to go into that as a permanent strategy - I want this to work, in any standard configuration it's likely to be run on, without having to tweak obscure settings in every machine, especially since such tweaks may have an unintended impact on something else.
The limits I've run into so far are plenty generous enough for my needs anyway; I don't really need to push them back any more. I will have around 5,000 total RC menu items on the entire form, if I activate absolutely every RC menu that I would like to, so I'm nowhere near any of the limits I've hit so far.
As for the crashing on rebuild, I think that will be fixed by not doing complete rebuilds, which are actually not necessary anyway. I will automatically populate the menus initially, when a new version is delivered, and do a C & R afterwards. I have code in there so that when I have a new version to deliver, I can send the user an empty database with all the new code in it. She runs that, and it looks around at itself and its surroundings. When it sees that it has no data in its own tables, it pops up a dialog asking for where to import the current data from. The user points the dialog to her current database, and this code reads everything in from there, checking sums and doing adjustments as necessary, if the table structure has changed in the new version. Once all records have been read in, and the totals read in correspond to the totals in the old database, the old database is closed, renamed to an archive name, with date included, the new database writes out a script that will rename it and restart it under the new name, then delete itself. The new database sets the C & R on close flag, then closes itself. The script watches for the database to close, then starts its work. When the new database reopens under the standard name, it clears the C & R flag, and the user is ready to go again, all her current data imported into the new version. I've been using this method for years, on a number of apps, and it works extremely well - users do not have to stop their work, ship me their data to import or anything of the sort. I set up everything to work with whatever new functions or repairs are necessary, while the users continue to do their normal work in the app. When I ship the new one, all they need to do is copy the new, empty database into the proper folder and start it - everything else is automatic. It even knows the default import database name, so when the file import dialog opens, usually all they have to do is hit Enter once.
So I will add code to rebuild the RC menus after this initial import. After that, in normal use, I will only add or delete the controls necessary, and only IF necessary - if an aux table value changes, for instance, it may be enough to just change the caption on the control. If the value changes enough to require a repositioning of the control (alphabetical order, mostly), I will delete just that one control and add a new one in the proper place. I will add a global counter for every control deleted or added, probably stored in a custom document variable, and when that reaches some reasonable number, maybe 100, maybe 1000 – whatever my additional testing seems to indicate, I will again set the C & R on close flag.
That seems to me should give me the functionality I want, boost the speed considerably and eliminate the error caused by too many adds, all at the same time.
