Storing interface graphics into globals

[Paolo]

In my solutions, most graphical elements occur many times across all the layouts.

I mean, buttons, backgrounds, arrows, etc...

This increases file size but, more important, increases network traffic.

Every graphic element can be substituted by a global container field, containing the image of the element, properly placed on the layout.

When the file is loaded, the startup script takes care of loading all the graphic elements from a graphic-elements-table into the globals.

Of course this requires more work when developing the solution and the layout design is more complicated. But there are several advantages:

1)Since globals reside on the client side, after the first loading non further network traffic is generated for the interface.

2)Files are smaller

3)You can edit every occurrence of a single graphic elements just by editing the "master" stored on the graphic-elements-table.

You can also design your solution to let the user choose between different sets of graphics elements, every set representing a different "theme" or "appearance".

The question is: have anyone applied this technique? Does the advantages pays for the additional work involved?

Thank you

Paolo

[Ender]

I have seen this idea taken to the theme level.

The problem I have seen is that container graphics seem to flash as you go from record to record.

[awcase3rd]

Ender,

I have seen where that can be avoided by putting an object from filemaker like a box, oval, or circle behind the global container. I have used this in my solution at work and seems to do the job.

-Al

[Paolo]

Does the container flash with filemaker 7 too?

[kevh72]

I miminize the flash effect by arranging those container fields to the back of the layout. When I upgraded to patch v.3, the flash effect is even more pronounced so I reverted back to v.2.

[PeterHW]

This is a technique that can surely reduce the time required maintaining the solution and ensures UI consistence. It would be great if it was also possible to attach a standard script (such as "GoToLayout") to such a global graphic. If that was the case, I would immediately change all my current solutions to this setup. Right now, I often find it's not worth the extra trouble.

Peter

[Brian C]

You make an interesting point.

I have always been working under the premise that a global field, once placed into a server enviornment, is nothing more than a variable in memory with a default value for the first time it is referenced. I believed that as long as the file remained open, it would (IN THEORY) make no difference in speed because it would have no need to refer to the stored default content after the first access. If what you say is true, it does have the potential to increase speed by eliminating netowork requests to the server as well as additional processor and disk I/O at the server.

Does FM by nature of how it references data via a relationship cause it to constantly attempt a lookup of the data even if the result is ignored because it is a global field? Is the mechanism which keeps the global field content from being replaced in a server enviornment, triggered before or after the relationship lookup occurs?

Going one step further, is the global content lost (reverted to default) in a server enviornment, if the file containing the global data is closed? Or is it maintained in memory as long as the global exists on a layout in a related file? Or is it maintained until the application is quit? Or is it maintained in memory until it reaches a low enough priority at which point it is purged because it has become and orphaned resource?

[Brian C]

You make an interesting point.

I have always been working under the premise that a global field, once placed into a server enviornment, is nothing more than a variable in memory with a default value for the first time it is referenced. I believed that as long as the file remained open, it would (IN THEORY) make no difference in speed because it would have no need to refer to the stored default content after the first access. If what you say is true, it does have the potential to increase speed by eliminating netowork requests to the server as well as additional processor and disk I/O at the server.

Does FM by nature of how it references data via a relationship cause it to constantly attempt a lookup of the data even if the result is ignored because it is a global field? Is the mechanism which keeps the global field content from being replaced in a server enviornment, triggered before or after the relationship lookup occurs?

Going one step further, is the global content lost (reverted to default) in a server enviornment, if the file containing the global data is closed? Or is it maintained in memory as long as the global exists on a layout in a related file? Or is it maintained until the application is quit? Or is it maintained in memory until it reaches a low enough priority at which point it is purged because it has become and orphaned resource?

[Brian C]

You make an interesting point.

I have always been working under the premise that a global field, once placed into a server enviornment, is nothing more than a variable in memory with a default value for the first time it is referenced. I believed that as long as the file remained open, it would (IN THEORY) make no difference in speed because it would have no need to refer to the stored default content after the first access. If what you say is true, it does have the potential to increase speed by eliminating netowork requests to the server as well as additional processor and disk I/O at the server.

Does FM by nature of how it references data via a relationship cause it to constantly attempt a lookup of the data even if the result is ignored because it is a global field? Is the mechanism which keeps the global field content from being replaced in a server enviornment, triggered before or after the relationship lookup occurs?

Going one step further, is the global content lost (reverted to default) in a server enviornment, if the file containing the global data is closed? Or is it maintained in memory as long as the global exists on a layout in a related file? Or is it maintained until the application is quit? Or is it maintained in memory until it reaches a low enough priority at which point it is purged because it has become and orphaned resource?

[CoZiMan]

Thank you, thank you, thank you. This should be on the tips forum, FOR SURE ! ! !

Ender,

I have seen where that can be avoided by putting an object from filemaker like a box, oval, or circle behind the global container. I have used this in my solution at work and seems to do the job.

-Al

[CoZiMan]

I have done exactly this, and use it regularly in my development. Talk about a custom UI, this is awesome.

Now if we could just edit the button shapes (ala 'graphic objects') life in the GUI world would be soooo good

I have seen this idea taken to the theme level.

The problem I have seen is that container graphics seem to flash as you go from record to record.

[RWX]

I haven't used this for interface elements (ie: buttons, etc) yet, but will probably makes use of the technique on my 1.1 update. I do, however, use this technique for icons and highlight colors and it works great!

-Rob

[PaulS]

You can get rid of the flash associated with global UI fields by making the field have a background colour..i.e don't make the field transparent.