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? _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
