[AccessD] Form corruption?

[Jim Dettman]

The number given has always been 754,  but that has drifted upwards to over 1,000 in later versions.   I posted all the counts a few years back.

Jim

Sent from my iPhone

> On Mar 3, 2015, at 6:45 PM, Charlotte Foust <charlotte.foust at gmail.com> wrote:
> 
> It used to be in the documentation, but I haven't looked it up recently
> because it became moot after they introduced tab controls.
> 
> Charlotte
> 
>> On Tue, Mar 3, 2015 at 3:42 PM, Janet Erbach <jerbach.db at gmail.com> wrote:
>> 
>> Charlotte -I think I read 700+ somewhere else too.
>> 
>> Dan - thank you for the offer of the 'Decorruptor' application!!
>> 
>>> On Tue, Mar 3, 2015 at 5:26 PM, Dan Waters <df.waters at outlook.com> wrote:
>>> 
>>> Hi Janet,
>>> 
>>> Your co-worker was 'experimenting'.  Too bad it didn't work.  As Dave
>> said
>>> there is a limited number of controls on a form - then you need a new
>>> form.  The 'experiment' did not work.
>>> 
>>> I made something that might be similar for one of my customers.  Their
>>> shop has about 25 different die casting machines - they are each bought
>> for
>>> different capabilities.  As such, they each have a different set of
>>> settings, requiring a different set of controls for each machine.  What I
>>> did was set up a main form with a tab control.  There are 8 tabs.  The
>>> first 2 are the same for every machine.  The next 6 contain a subform
>>> control that is filled with the subforms I designed for the specific
>>> machine, which is selected by a combobox on the main form.  The number of
>>> subforms per machine ranges from 2 to 6.  I swap out the subforms in code
>>> after the combobox is selected.
>>> 
>>> Each machine has its own table, which populates the main form controls
>> and
>>> all the controls on the subforms.  I'll change the main form's
>> recordsource
>>> in code when the machine number combobox is selected.
>>> 
>>> I did something very similar for reports.  When a job is set up, someone
>>> selects the machine and the part number (each part gets different
>>> settings), and they print out a report that is given to the folks who
>>> actually set up the die cast machine for that part.
>>> 
>>> This worked out to be a good approach - no errors for many years.
>>> 
>>> Also, I will send you off-line a copy of my 'Decorrupter' application.
>>> This will write all objects to text and then import them back as objects
>> -
>>> doing this resets the historical number of controls back to zero.
>>> 
>>> Good Luck!
>>> Dan
>>> 
>>> -----Original Message-----
>>> From: accessd-bounces at databaseadvisors.com [mailto:
>>> accessd-bounces at databaseadvisors.com] On Behalf Of Janet Erbach
>>> Sent: Tuesday, March 03, 2015 14:46 PM
>>> To: Database Advisors
>>> Subject: [AccessD] Form corruption?
>>> 
>>> Hello All -
>>> 
>>> My Productivity App from WIFI hell has another component to it that I
>> need
>>> to ask about.  This portion of the app was written by my co-worker using
>> a
>>> methodology I did NOT want to employ.  He designed the main form so that
>>> 90% of the form objects are *drawn on the form at load time.* Existing
>>> objects are deleted first, and then new ones created using
>> 'CreateControl'.
>>> 
>>> 
>>> This is a 2 page form - page 1 with command buttons and page 2 with what
>>> are basically 'hand drawn' charts.  I've attached 2 screen shots to give
>> an
>>> idea of the number of objects that are being created.
>>> 
>>> He designed it this way so that there would be, in his mind, the ultimate
>>> amount of flexibility in terms of drawing a form with 1 group of machines
>>> or 10 groups of machines.  No objects to hide/activate - just create them
>>> all from scratch each time.
>>> 
>>> It works pretty well out on the production floor for the most part.  But
>>> when I'm working in the app, making changes to the code behind the form
>> (or
>>> even just making changes to stand-alone modules) it will be very subject
>> to:
>>> 
>>> Error 29054:  Access can't add, rename, or delete the control(s) you
>>> requested.
>>> 
>>> It's as if form corruption creeps in behind my back.  I can run the form
>>> repeatedly during development with no issues.  And then out of the blue
>> the
>>> error crops up.  Sometimes re-deleting all of the controls is enough to
>>> correct it;  other times I have to pull a 'clean' form from back up in
>>> order to get un-stuck.
>>> 
>>> Does anyone know what's behind this error?  Is there are way to keep his
>>> 'draw on load' code intact and keep this error from recurring?  Or do I
>>> need to re-create the form with hard-coded objects the way I wanted to in
>>> the first place?
>>> 
>>> Thank you.
>>> 
>>> Janet Erbach
>>> 
>>> 
>>> --
>>> AccessD mailing list
>>> AccessD at databaseadvisors.com
>>> http://databaseadvisors.com/mailman/listinfo/accessd
>>> Website: http://www.databaseadvisors.com
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com