[AccessD] Form corruption?

Dan Waters df.waters at outlook.com
Tue Mar 3 17:26:43 CST 2015


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




More information about the AccessD mailing list