Unacceptable File Size Increase

[Kay C Lan]

Ah, I seem to have interpreted Blair's email completely differently and
although I'm probably wrong it still begs the question.

Firstly I think Jacque is closer to the problem, not the displaying of data
and the benefits of external dbs, but the possible creation of 'extra'
controls that are adding bloat to the app.

May I suggest that you use the Application Browser, found under the Tools
menu, to inspect your App. When you poke around with this you should be able
to confirm that you have the right number of substacks and cards in each
substack. More importantly, you should be able to compare the number of
controls on each card against the number of controls on your 'master card'.
You should be able to quickly determine if you have 10 fields all called
'Name' sitting one on top of the other!

So the 'begged question' as I see it is; how do you automatically update a
stack GUI against a master GUI.

Try this 'poor' example:

You have a Contact App that simply stores name and contact details. Unlike
all the others that show the details in single card rolodex style, you
create 15 substacks so that you can look at 16 contacts at once.

10 years ago you had to add an extra field for email address + label field.
5 year ago you had to add a 5th 'phone' field for mobile number + label
field.
Last year you had to make the 'card' bigger so you could add a 'photo'
field.
And today, because someone realised that you only typically store 3 phone
numbers, you need to change the 5 'label' fields (Home Phone, Home Fax, Work
Phone, Work Fax, Mobile) to 3 Option buttons with the 5 mentioned options
and reduce the number of phone number fields to 3.

Making those changes to the 'master' is no great hassle, but repeating it 15
times is boring. Whilst it is easy to:
set the rectangle of field "Name" of stack "Substack 1" to the rectangle of
field "Name" of stack "MasterGUI"
The advantage of this method is that you can basically do anything without
risk of altering the data stored in the field. The problem is that there
must be about 90 odd properties for a field and running through everyone
seems a little tedious. Of course if you copy and paste the field all the
properties come correctly set, but you must make sure you don't loose the
data currently stored!

Blair wrote:

> That is, each relevant substack has its version of card X. (I have
> forgotten why. Most of the scripting work was done two years ago.)
>

I imagine the reason why is data security. My impression is that you don't
use 'Backgrounds' which I thought was a problem. But then I realised that if
you remove a control from a background, you instantaneously remove it from
every card that contains that background. To me going from card to card
moving data from say field phone number 5 to field phone number 3 is a lot
easier than collecting all that data and storing it somewhere concrete - so
it's not lost if the power goes out half way through - then moving it into
the appropriate place after the modification is done.

'set the backgroundBehavior to false' before deleting controls, and then
setting it back to true might be one option to help prevent lost data but
still retain the advantages of backgroundBehavior.

Enough of my random thoughts, I was more interested in how others would
approach this problem?