[AccessD] Form corruption?

Bill Benson bensonforums at gmail.com
Thu Mar 5 20:10:15 CST 2015


bummer, thought had a workaround! Thanks for the benefit of your experience
John, I would have hated to mislead.

On Thu, Mar 5, 2015 at 7:25 PM, John W. Colby <jwcolby at gmail.com> wrote:

> I don't believe it does.  It seems that one should be able to dynamically
> create a form on-the-fly and use that to populate. Usually we have pieces
> and parts we really want to keep and just dynamically create controls in
> the main body.
>
>
> John W. Colby
>
>
> On 3/5/2015 5:59 PM, Bill Benson wrote:
>
>> Does that marvelous code that exports forms and controls using SaveAsText
>> and LoadFromText not clear out the control limits? Perhaps this is an
>> avenue to use while forms are not open... a way of refreshing the
>> database.
>>
>>
>> http://www.access-programmers.co.uk/forums/showthread.php?t=99179
>>
>>
>> On Tue, Mar 3, 2015 at 6: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
>


More information about the AccessD mailing list