Backgrounds - again

[PiedPiper]

I've been working on this problem for months. I've posted twice and (not because the answers I received weren't good) but because Im having trouble GETTING it. Things have ben explained generally and I need specifics. Please help me guys, because this is important and for some reason I seem to have a block of some sort understanding it.

Networked Server 5.5, Win XP, FM 6. I want people to switch to a form and see 20 small boxes of color. When they click a color, the background on every db they view switches to that color. I assume global so each person is different. I've read an INVALID global can be used but don't know what that means. I've heard use regular Container and use Global Container. I don't know which to use.

I thought I'd set up a Preferences file with 1 record? What goes in that one record? No post has ever explained it so I can see what they mean. I set up a file with one record (blank) and constant calc indexed 1. I set up field - global container with 20 reps. But I couldn't get that to display on a form in each file! So after I posted two times ago, I changed it to regular container with 20 reps - same problem.

Also when using reps it nnly displays the colors in a long horizontal or vertical stupid bar. So I think Okay, a different field for each color - pasted on form - prson is switched to that form (in Preferences) to select their color. But I'm back to 1) global or standard container? 2) Joined to each db on what? Global on left I assume that I fill with script when clicked?. But how is the number put in their to make it a relation - or do I care because I want it invalid any way.

I read must be global because otherwise it'd disappear (and buttons kept there too) in find mode. Then read, no it's okay to use regular containers. Then I read that containers take more space than globals and globals are more efficient. I think I'm losing my mind here.

Right now, I have regular container in each file and a global container also. They have three colors only because I'm tired. Script sets global to regular container when they click one of three buttons. have script for each repeition - 20!? And they want 40!. Must be an easier way in another file using a relationship, be less stress on network and save me writing 40 scripts and inserting 80 container fields in each file.

please please please Im willing to do the work but I need some seriious direction here.Things like 'Use an invalid relationship' I don't understand. I need to know how they connect also. Can someone provide a simple clean demo of a good preference file or write out in easy terms. I'd like buttons in it also but since I can't even get backgrounds figured out, I haven't even attempted buttons. And do I store each persons preferred 'color' in their staff file or does it stay in the global all the time? I see no preference files demo'd anywhere. Is it because it's so simple and I'm the only nutcase that doesn't understand it?

BTW, it's kinda cool that regular container background turns white in find. That sorta designates it as find which is helpful. I'd prefer pale yellow/grey but it's nice. Globals don't change in find - good and bad, I guess.

Pete

[CobaltSky]

Hi Pete,

Yes, there is a lot of conflicting information flying around, as you say.

The reference to 'invalid' is to a kind of relationship which can be used to source values from global fields. It's useful because it doesn't require that the index for the related key field be retrieved (which can be slow, especially over a network) before the relationship can be established and the value can be passed bettween the files. In this context, an invalid relationship is essentially one on which the right-side key is not indexable. Typically a global field is used as the right side key. When creating such a relationship you will be presented with an error dialog saying that the relationship will not work because the field cannot be indexed, but you have the option to proceed anyway. When you do, the relationship will only allow you to retrieve global field values from the related file - and will do so considerably more efficiently than a conventional (valid) relationship.

As to the globals vs regular containers, it is true that global field contents will still apear in find mode and that regular fields (including containers) will not. It is NOT true that regular fields, in and of themselves, use more resources than global fields.

A global field will store only one value regardless of the number of records in the file. A regular field which stores only one value (ie only one record has a value on it) will use the same resources as a global field, regardless of the number of records in the file. It is only when a regular field is used to store additional instances (ie more than one record in the file has an data in the field) that additional resources are used accordingly. This is true for container fields as well as other data types.

As regards your 'long horizontal or vertical stupid bar' problem, it sounds as though you are not setting your background fields to appropriate graphic format settings. The graphic coloor swatches stored in your containers in the preference file should be no more than 1px x 1px and the graphic format scaling on the display fields should be used to expand them to to the appropriate vertical and horizontal dimensions to fill the required rectangular area. If you store bitmap graphics that are full display size then this will be many times slower (potentially by a factor of thousands).

Finally, you mention preferring pale yellow/grey for your default backgrounds. Perhaps you are not aware that if you select a body part in layout mode you can apply color fill characteristics to it directly. This does not use any additional resources - the attributes for the RGB values for the particular layout part are originally stored in hex as ffffff and you are merely replacing this six digit hex code with another six digit code of your own choosing, which is file size (and otherwise) resource neutral. By doing this you can have whatever 'find' background color you choose.

[PiedPiper]

Global for right side - go figure. Global for left and right? Makes no sense but that's okay - I"ll try it.

I wasn't clear enough Ray about the horizontal, vertical thing. When I put the colors in repetitions and then display it for people to select from, I can resize it except to make it smaller or larger. If I had 40 colors it only goes one way - up or across. And I can't attach script to each repetition, atleast i couldn't and I tried. so Ill need to have 40 graphics records and I didn't want that.

Uh no I didn't know i could color the background silly huh.

So I'll try a preference file with one record. Global on left in main file and global on right. What goes in these fields - a 1 in the preference global and a 1 in main file global? would it be different for each person? And how to I; well, I'm still lost on how to do it. Reps don't allow display as a box like I saw in demo Web Palette. It used a different field for each color. I guess I'll have to do that after all - still only one record, right - but different fields for each color so I can put them easily on a form and attach a script?

Sorry Ray I'm really trying to figure this out as quickly as possible and not waste anyones timebut this prefernce file is still only partially formed in my mind.

Pete

[CobaltSky]

Attached is a simple demo which you might find useful.

PrefSystem.zip

[EddyB]

Hi all, sorry to go off the track of this thread but Ray...

I was wondering if you could answer a couple of questions for me about your demo, not to do with the functionality of the preference file though.

1) How have you changed the scriptmenu to say Nightwing?

2) Which application do you use for your graphics in this demo.

I am working on and trying to improve my look of databases I'm creating, the funtionalities all work OK but my GUI design have a lot of improving to be done!

Many thanks

Ed

[PiedPiper]

I've been trying to download Ray's file but I keep getting 94796-PrefSystem.zip from www.fmforums.com can't be accessed. Has anyone else been able to open it? Drives me crazy - wanna see it but can't get it. Am I the only one with a problem downloading it?

P

[CobaltSky]

EddyB said:I was wondering if you could answer a couple of questions for me about your demo...

Sure, Ed.

The ability to specify a custom name for the scripts menu is a feature of the Developer Tool which ships with FileMaker Developer.

As regards graphics I'm somewhat eclectic. The demo includes bits and pieces that came from Photoshop 7, Canvas 9 and SuperPaint 3.5 - and of course, FileMaker itself.

[CobaltSky]

PiedPiper said:

...I keep getting 94796-PrefSystem.zip from www.fmforums.com can't be accessed. Has anyone else been able to open it?

Pete,

I've just tried downloading a copy from here and it downloaded and unzipped without any error messages - and opened up fine into FileMaker.

I suggest that you try again, but in case you're still having trouble, I've posted a copy online that can be downloaded from our web site at: http://www.nightwing.com.au/FileMaker/demos/PrefSystem.zip

[EddyB]

Hi Ray,

Many thanks for this.

I have developer but have not really explored it. I realised that I could add these features to a runtime, but not to a normal FMPro DB. I thought that maybe this needed a plugin - but no! You learn something new everyday here!

Thanks again

Ed

[PiedPiper]

Well I couldn't download from work so came home early - had to see it. Portal!! it'll take a bit to understand what you did. i'm a bit slow on understanding this stuff but you even put buttons for me.

I'm sure you've heard this before but YOU ROCK! and its okay to have more than one record in pref? and buttons are globals so they don't disappear in find. YOu accounted for everything. Thank you and I'm sure forum thanks you for getting me off their backs about this. I'm a happy camper.

When each person opens their file, it'll keep this background color for them all the time until they change it again? Oh never mind, I don't want to take more of your time, I'll figure it out.

Again, thanks Ray. If you're ever in Salt Lake City, I'm buy you dinner anywhere you want.

Pete

[Ugo DI LUCA]

Just one small add-on to Ray's demo.

When switching to Find mode, it would revert to what is the original Layout Background color.

So if you'd like it to stay with that User's preference color, you'd have to script it and set the background as a local global container.

Otherwise, it sure Rocks as usual.

[PiedPiper]

well i see that Ray has the Background field itself set to fill with yellow in Main. Not the one in Preferences!! And it displays yellow in Find. That solves my 'find thing' also. Ray! YAY!!! I want EVERONE's find to be yellow so they know. So I can set the container on each layout to yellow background (fill color) and it works. That way, I don't have to color the layout itself, right? Wonderful - Script (only ONE) does it all - this will save me writing 20 scripts too.

I'm stimied on one thing... I placed another copy of the Preference::Background next to Ray's container on the SAME FORM and it's a different color than his container - it doesn't change but there's no script attached to his container - I did Insert field.!! When I copied his container and pasted it on the same form, it was the right color. Why would the same container placed on the same view in Main display a different color? I tried all three preference relationships - all purple but Ray's is blue. Hmm, this is tricky indeed.

Pete

[PiedPiper]

I found the invalid relationship! Neither gPrefKey or Constantkey have a value in main!!?? No value = invalid relationship! Am I right? No relationship works??? With globals, I mean. I like this!

Pete

[PiedPiper]

Ok. You set gPrefKey in startup. When i run script Set Preference, I should have it write the 'record number' from Preference::Container to Staff database on their record. Then when each db opens, the startup will set gPrefKey to Staff::Background (based upon relation from Solution:UserName to Staff::UserName. This way the global will always open filled with that person's background choice, right? Sorry everyone, just really want to get this --- and get it right. Thanks.

Pete

[CobaltSky]

Hi Ugo,

If you read the earlier part of the thread, you'll find that Pete was asking for a way to have a background that disappears in find mode to reveal a yellow/gray color, but buttons which don't disappear. So the purpose of the demo was to show a way to do that. There are of course a number of ways to go about it, so this is just one possibility which seemed to suit what he was trying to do.

Pete,

For this purpose, a relationship which is invalid only in the sense that there are no values in one or both key fields is not ideal. the reason for using an invalid relationship is to prevent FileMaker from sending the index across the network to the client for the client computer to interrogate (looking for matching records). With a relationship that merely fails because there are no values or no values that match, FileMaker doesn't establish this fact until it has already done all the work of trying to make a match. The idea behind using an invalid relationship in this circumstance is to prevent the transfer of data and so speed up the process - and for that, a relationship which has an unindexable field as its right key is appropriate because if there is no index, then it takes zero time to send it across the network and zero time to interrogate it and FileMaker can get on with the next task, which is retrieving the global value.

So much for the theory - now to your practical question. Rather than scripting the setting of globals as the user moves around the database, I suggest that you either:

A) Set a gPrefKey field in each file as part of the login script, or

: create an unstored calculation field in each file called cPrefKey and specify its formula as Staff::Background, then use it as the left key for the relationship from each file to the preference file.

Either way, the preferences will be dealt with once, as part of the login procedure,- and you won't need to worry about remembering to include a preference setting procedure in every script by which a user can possibly end up in a different database.

[PiedPiper]

Okay, I have this set up. Do you have patience with a, okay ... lower than intermediate level person? It all works perfectly. Please tell me if this is right:

Whether I use your suggested A) or :, I'll still need to modify the script in the portal so that when someone clicks it, it resets Staff::Background to their new selection, right? I added Set Field Staff::Background, PreferenceAll::PrefID to your Set Preference script attached inthe portal.

I then changed StartUp script to: Set Field gPref_Key, Staff::Background and would repeat for every file. Is this what you mean by A? Ops I said B but I mean A.

A) seemed easier because I have a Startup script in every file any way. But it would still require a gPref_Key field. Whereas : would update the key automatically without being set.

But I read that if a file is opened because of a relationship it doesn't run its startup script. Is this incorrect? And if the Startup script isn't ran when the person switches to another db, how can it update if I use A? Am I supposed to script an Open for each db to prevent this or should I just use B? Probably a dumb question ...or am i still missing something here? Ive spent hours on it.

I just added this ... I don't have a logon db yet. I created a global in Main to pretend with and joined it to staff. So when staff logs on (supposedly) and fills in their 'whatever' it will make the connection to Staff and grab their background. Geez.

Pete

[CobaltSky]

PiedPiper said:

...Please tell me if this is right:

Whether I use your suggested A) or :, I'll still need to modify the script in the portal so that when someone clicks it, it resets Staff::Background to their new selection, right? I added Set Field Staff::Background, PreferenceAll::PrefID to your Set Preference script attached in the portal...

This question relates as much to your login procedure than to your preferences system - and we've not talked about. However assuming that at the point when this occurs, the Staff relationship is correctly pointing to the record where the prefences for the person who is logging in are stored, then yes, this is correct.

PiedPiper said:

...I then changed StartUp script to: Set Field gPref_Key, Staff::Background and would repeat for every file. Is this what you mean by A? Ops I said B but I mean A...

Not necessarily. It's preferable that you have a 'master' start-up script in one file only and set all the other start-up scripts to call that one script. That way the same start-up script runs regardless of which file opens first. The 'master' start-up script can then set the globals in all the files (preferably via invalid relationships to those files). This will ensure that the gPrefKey values are always set, even if some of the files are opened in such a way that their start-up script does not run.

PiedPiper said:...A) seemed easier because I have a Startup script in every file any way. But it would still require a gPref_Key field. Whereas : would update the key automatically without being set...

True, but bear in mind that the 'A' method is more efficient than the 'B' method because it sets the preference for each file only once per login session, whereas the unstored calc in 'B' must retrieve the value from Staff::Background afresh with every layout change.

PiedPiper said:

...But I read that if a file is opened because of a relationship it doesn't run its startup script. Is this incorrect? And if the Startup script isn't ran when the person switches to another db, how can it update if I use A? Am I supposed to script an Open for each db to prevent this or should I just use B? Probably a dumb question ...or am i still missing something here? Ive spent hours on it...

You could script an opening sequence for each file, but fully scripted interfaces can be onerous. The 'Master script' approach I outlined above would be a way around this.

PiedPiper said:...I just added this ... I don't have a logon db yet. I created a global in Main to pretend with and joined it to staff. So when staff logs on (supposedly) and fills in their 'whatever' it will make the connection to Staff and grab their background. Geez...

The user preferences should be invoked as part of the login procedure, which need not necessarily be part of the start-up script.

If the login procedure is not tied to the start-up script, then you should consider having an inverse procedure (eg reinstatement of default preference values) incorporated into a logout procedure. This allows multiple login sessions within a single application/solution session (ie users do not need to quit and re-start FileMaker in order to log in using a different user account).

But now we're getting into access control, which is a whole subject in itself.

[PiedPiper]

Uh wow. Thanks Ray. Access control right. Well, I think I'd better get that figured out so I can finish my Prefences file.

You said "It's preferable that you have a 'master' start-up script in one file only and set all the other start-up scripts to call that one script. That way the same start-up script runs regardless of which file opens first. The 'master' start-up script can then set the globals in all the files (preferably via invalid relationships to those files)."

Uh. Right. Okay I don't know what to use for master file/script. I guess I'd better get a real logon file in place and try to figure this out. I won't mix topics on this post. I may be posting on this subject elsewhere. Hope not. Hope Ive learned enough to figure it out. But my backgrounds are perfect. Can't wait to get this all tied together so each person has their own background when they log in. Appreciate all the time you've taken with me.

Pete

[bruceR]

The point of using a preference file is to NOT use globals. Globals are not persistent. You want a prefs file to hold persistent data that everybody uses, and the only kind of data that meets this requirement is a "real" record, standard data field, not a global. Company name, address, web URL, etc. Even color choice options.

USING this data is the second issue, and here global fields may be involved as in Ray's example. User A selects one of the color options and place it in the background graphic global field. User B selects a different option, and that's what he sees. But the only reason they could both select this data is because it is in a standard field. The common way of doing this is a single record file. For color choice options, a repeating field is often used to hold the options. Because there is only one record, any relationships pull in the correct data. For the color choice example, a multi-record pref file worked OK. But for other data, like company name, phone number, you don't want a second record that is empty or that holds different data than the first record.

[PiedPiper]

Well now this set my mind to skiddering again. If I use reps how can a person change backgrounds by clicking their color and not have it displayed in one long ugly line - besides I couldn't get a script to attach to each repeition.

Yes, I want to store company info. But where do I store info on each staff preference and selection - like their background color so itll change when they change it? Makes sense on the staff record because its a one to one (as I thought I understood the theory, but I'm pretty weak in this stuff). As login info should be stored in staff - because each login info pertains to each staff (?). See, I'm a dummy.

I feel ike I now have the cart but no horse yet. I don't even know how to make a logon that works with preferences or windows computer login name and Access privileges. Thanks for the thoughts Bruce but, although what you say makes sense, I can't see the big connection picture here at all and wouldn't have a clue how else to do it but what Ray said and trust that I can figure out how to connect it together into something that works right. Ray wouldn't steer me wrong.

But lawns are sure looking better all the time.

Pete

[CobaltSky]

BruceR said:Globals are not persistent...

Hello Bruce,

Evidently, it will surprise you to learn that global field values can indeed be 'persistent' if they are used appropriately.

Global field values that are edited on a client workstation are lost at the conclusion of the client session, but those which are made either on the host - or on the file in single-user mode - are saved and are available after the solution is closed and re-opened. Since these latter global values are available to all clients at login and cannot be overwritten or deleted by a client workstation, they are indeed persistent - very persistent, one might say . As such they are absolutely ideal for storing resources such as graphics or text which are to be accessed universally - or conditionally according to user preferences.

There has been no suggestion on this thread that the preference selections of individuals be permanently stored in global fields. Pete has indicated that he proposes to store that information in data fields within the relevant records in his Staff file, where it will be available at next login.

However the use of global fields for the permanent storage of solution-wide resources - especially those which are required to be available for display in find mode as well as browse mode, is entirely consistent with the established practice of many professional developers, myself included.

[bruceR]

PiedPiper said:

Well now this set my mind to skiddering again. If I use reps how can a person change backgrounds by clicking their color and not have it displayed in one long ugly line - besides I couldn't get a script to attach to each repeition. [/quoteThis is a non-sequiter. I have no idea where this strange-line comment is coming from.

As far as choosing from a repeating field, you use the getRepetition function. So the background would be getRepetition(BackgroundRepeat, gPref). So your script would be,

set field [gBackground, getRepetition(Prefs::BackgroundRepeat, 1]

Script for selection of rep 2 would be

set field [gBackground, getRepetition(Prefs::BackgroundRepeat, 2] etc.

[bruceR]

CobaltSky said:

Hello Bruce,

Evidently, it will surprise you to learn that global field values can indeed be 'persistent' if they are used appropriately.

I understand how globals work. I know that's why you chose, in your color preference demo, to put all the color pref choices in standard data fields and not globals. If preference choices are stored only in globals, and the system is live, on line, multi-user, how do the new preferences get entered? They don't.

[PiedPiper]

Thanks Bruce. Well, I tried that I think or maybe just something similar. Ive been working on this for quite some time, please see Global Background for each person.

Ok. And I'd still need to store the persons preference in a regular field, right? So I'd have to have a record for each person in Preferences (and not just one). That's why I was thinking of just using the Staff file for their preferences. Oh.andt login stuff too. And then each time they click the color portal it'd have to update each global gPref field in each open file and write to Staff::Background also?

Geez, I just want to use a fluid, efficient structure over the network but still take advantage of some graphics resource-costs (a few pretty buttons) thanks Ray without bloating file size and network resources but still allow someone to change their background if they get bored with it. But I want their background choice to always be uniform throughout the files so it is a consistent looking program when they jump around. I think I need a Valium. My head hurts on this one - has for months. I want to become a master on globals and invalid (and valid relationships) so I never get this headache again. This ... and logon database.

I want to understand all of this however i end up doing it. This post is teaching me a great deal (I think I hope) but I remain confused on how using the reps (as you are suggesting) - I mean I don't understand how that would all attach and work for relationship and where to write staff preference? Can you help me understand it like: Your relationship would be (fill in), and their fields would be (fill in)? And reps only display in one silly line up or across - I can't 'box' it' into like 10 rows of 5 can I? Do you have the time to help me understand further?

What Ray gave me is working great once I get the login thing and master script thingy figured out. Hey Ray are you there?! Can I store the buttons as Reference Only and pass that through? Would that decrease file size as well??? Oh i like this idea! Maybe even store my background color options there? This should make for a speeedier system, right?

Pete

[bruceR]

PiedPiper said:

Ok. And I'd still need to store the persons preference in a regular field, right? So I'd have to have a record for each person in Preferences

Preferences? No. If you want a record for each user then you create a table of users. Users.fp5 or somesuch.

If you have a very small user list, there are some other ways you could handle it, even with the dreaded repeating fields in the preference file. But as soon as you decide, well, I'll just hold TEN users, that will do it. Somebody will add number 11 and you're out of luck. So what you really want is a true Users database. That's generally how it's done.

Also recognize that you are talking about completely different data types. A USER record would have some field like UserID and a name, minimally, plus the graphics choice, plus (in fancier solutions) maybe some access privileges, a password, etc.

A PREFERENCES record has the color choice options - with a repeating field being one way to store them; plus perhaps a company logo field, button graphics, text fields for company name, company address field, company fax, etc. These values get displayed on report layouts, invoice layouts, etc. Company moves? Changes names? You deploy the solution for a different company? Edit the company prefs and you're in business.

[PiedPiper]

Thanks. Yes sorry. Im getting confused on all of this. I meant Staff file for their stuff. Yes. Preferences would be for the graphics but you didn't say how you would join them all or how I could display the repetitions other than one long line. Reps aren't very nice this way. I appreciate the ideas tho and will continue to bang my head against the wall on this until it all sinks in and I understand it.

Pete

[bruceR]

How is the display of graphic background choice different in any way at all from Ray's example? Portal, repeating field. The appearance is exactly the same. You are really leaving something out here. I even gave you a script for selecting the graphic.

[PiedPiper]

Hi Bruce Not leaving anything out. I think I'm just tired. Sunday night and still haven't finished all the things i need for Monday. I was so excited with Ray's demo that I forgot that I wanted a square to display the 40 choices - actually started out as 50. I originally wanted like Web Pallets 10 across 5 down but yesterday I decided on 20 instead because of the length of the portal. IDisplay for selection isn't as important as the rest of it. I just tought it would be easier for people than scrolling a long list. Doing it right is more important. 20 portal rows or 20 reps will work just as well. Sorry I got confused on it.

I need to play with your ideas because I still don't see how to attach each script to each repetition and I'll need 20 scripts? Rays way needs only one script. I think I'll go shoot some pool and grumble in my beer for a few hours. no wonder you guys get paid big bucks for this stuff. its hard work.

[bruceR]

Yes, the portal approach is simpler. Also, I'm trying to describe the more general and complete case of a preference file, where other data is involved and where there must be only one instance of the data. You don't want people to enter company address in 3 different records and enter it differently each time.

But that's not what you're trying to do at the moment. However, there is a way to do both.

Let's suppose you DO want a general preference file, with company address, company phone, company fax included, for instance. Then you could set things up so that the ID of record 1 is 1. For general pref data entry, you would ensure that it ONLY goes in record 1. (Company name, etc.) Then your other files would have a ConstantCalc = 1, and have a relation PrefsByConstant which relates to the record ID in Prefs. Thus they would only "see" the data from record 1. For the graphics prefs, you could use the portal as described by Ray.