Start-up script loads graphical elements into globals...How?

[moonunit]

Whilst browsing the forum I came across a posting from Paolo entitled "Storing interface graphics into globals", which caught my eye.

Post#148593

I've only recently started adding graphics to layouts via container fields, as a result of which it's been a new experience to discover globals dropping their values when a file is cloned, and finding a cure has been on my list of things to do ever since. Which is why Paolo's comment "When the file is loaded, the startup script takes care of loading all the graphic elements from a graphic-elements-table into the globals."

How do I set about doing this myself?

To my mind, graphics get stored in container fields and containers don't survive cloning - or strictly speaking, don't survive because a cloned copy is record-free?

Any hints and pointers on how I should do this will be gratefully received.

Tim

[CobaltSky]

Hello moonunit,

Whether your graphics are in global container fields or in regular containers in a graphic elements table in your solution, they are going to have to be restored (eg re-imported) after any time the solution file is cloned. So I don't think that the approach Paolo mentioned was intended to be a solution to that particular dilemma.

However you may nonetheless find that there are benefits in storing system resources - including graphics - in a data table and loading them at start-up.

The loading procedure essentially involves accessing the relevant record(s) of the resources table - either by relationship or by navigating to a layout based on the resources table and locating the desired record - and then performing a series of Set Field [ ] operations to transfer the relevant images to the global fields from which the solution will source them. One example of a script that would do this is:

Enter Browse Mode [ ]

Freeze Window

Go to Layout ["GraphicResources" (SystemImages)]

Go to Record/Request/Page [First]

Set Field [MainTable::gFirstImage; GraphicResources::zPic01]

Set Field [MainTable::gSecondImage; GraphicResources::zPic02]

Set Field [MainTable::gThirdImage; GraphicResources::zPic03]

Set Field [MainTable::gFourthImage; GraphicResources::zPic04]

Go to Layout ["Menu" (MainTable)]

Refresh Window[ ]

There are a variety of other approaches (and variations on a theme) that can be used to script this, but the above may give you a place to start. The sequence of commands ccould either be within a script which is defined (via the File Options... dialog) to run when opening the file, or in a script which is called as a sub-script from within an existing on-open script. :

[moonunit]

Many thanks for that, CobaltSky...I've yet to try and put it together but your instructions are clear... I do have a couple of other questions arising...

1) So there is no way that a cloned copy will ever retain globals?

Could you for instance create a 'clone' script which creates a new file with, say, a single graphic-element record retained - and trigger this from within the db you want to clone?

2) Given that an FMP solution resides on a server, the way you have outlined using the resources table, is the way to ensure that everything loads properly client-side every time it's opened - yes?

Thanks again

Tim

[CobaltSky]

Hi Tim,

Some answers to your questions:

1) a cloned file is essentially an empty shell - it is the database structure without any content. Graphics within global fields are one type of content and since all content is lost during cloning, global container contents will always be lost.

At best you might script a process which clones the file and the subsequently restores some of the contents (eg sets values into some of the fields in the cloned file. This might save you from having to re-populate the global fields manually each time you clone the file, but would only be worth doing if you expect to be cloning the file frequently and have a lot of globals to populate..

2) That's correct. Populating globals from a resources table is a way to ensure that the desired global field contents are present for each user session, without having to take the file down and open it as host each time one of the resources is to be changed. :

[David McQueen]

2) That's correct. Populating globals from a resources table is a way to ensure that the desired global field contents are present for each user session, without having to take the file down and open it as host each time one of the resources is to be changed. :

Further on this, this technique also allows you to set individual user parameters on start up. Example, have them log in with a name, then have the name match stored parameter names in a preferences table to get a confirmation and then have the startup script set various global fields with parameters for that particular person in that session.

Globals set from a parameters table or set by a startup script in multi user solutions give great oportunities to the programmer to give each user a semi custom experience.

HTH

Dave McQueen

[moonunit]

Thank you both for your considered views.

I am now building a resource table into everything.

I'm even strangely pleased with the news that Cloning is a relatively final exercise - I have a lot of one-time mini solutions which require re-populating each time. Until recently I would always clone, but once I'd got into FMP 7.0 and my dbs were growing globals, the loss of nav graphics and layout headers was a little unsettling. Now, with the resource table, I can delete existing records and everything else will tie in again.

I have experienced one minor problem - I have a global layout header which is a (text) calculation concatenating text and a date field - but I have found a workaround.

Thank you both again.

Tim