summary (but not number)

[Sam W]

Thank you for reading my query. My database has two tables, one holds a string for each record and its attributes (font, pt size, etc). The other is "component" which holds all the parts in a reformatted function.

Say I have 25 records that say "Helvetica" and 10 that say "Times New Roman", etc.

In the component, I want to know what fonts are used in the text parts table. I don't want to know how many of each. If there are 35 records, then I want some way to know what fonts are needed for this component.

I thought a summary would be good, but they all assume numbers and not strings. (all the string values are standardized, so no chance of "helvetika" and "helvetica" skewing my results.

I thought a "many to one" relationship, but my ignorance in this is probably making you laugh.

I want a list of the fonts used so I can call them into my text script "if "helvetica" then "" or something like that. I'm not sure how that last part will work but the first part needs to work so I can figure out the last part.

thanx, for your time, sam

[sbg2]

I think what you are looking for is a value list, example attached, sign in using Guest Account.

ValueList.zip

[Sam W]

Thank you for your time to provide this. I've spent some time studying your example. I never would have thought of a value list.

I guess what's throwing me is your use of a separate field to trigger the 'font list" calculation. I was able to mimic the ValueListItems in my file and it pulls in all the fonts used, but I'm having trouble populating that calculation.

I'm not sure why it's important to use that trigger, but it must be, because even when I use a text field in the portal and paste in a value from "text parts" I get all the records. And no change in my "font list" calculation.

So there's something I'm missing. I'm hoping I can have "font list" automatically populated as records pore in, without me having to trigger anything in the component layout.

Thanks for your time, sam

[Søren Dyhr]

I'm not sure why it's important to use that trigger, but it must be, because even when I use a text field in the portal and paste in a value from "text parts" I get all the records. And no change in my "font list" calculation.

Neither am I - I'm considered a devotee to metaphoric interfaces, and can't really get why a spread sheet'ish freshing of data that more or less is a summary should be needed. The template sbg2 supplied hangs when you alter something a relation away ...which however easily can be freshened either by flushing cache or flipping to the next record and back again.

What I've made is that I'm not shying away from using a button to establish these summaries on demand and not wasting processing powers on getting the information as live as posible.

It's indeed a more mac'ish feel and touch to it than a lot of Linux'ers and Windows users seems to tolerate ...however does it what the tread originally was about a Summary!

--sd

Summaries.zip

[Søren Dyhr]

Oh blast! I used $variables wich you can't under fm7 ...I did it of purely speed considerations, please await a more feature humble version.

--sd

Edited December 18, 2005 by Guest

[Sam W]

I've reviewed it and would like to see more when you are able. Thank you for looking at my problem, sam

[Søren Dyhr]

Alright I've now made the needed changes as well as making the summary a dialog!!

Enjoy

--sd

Summaries2.zip

[sbg2]

As usual, I'm not quite sure why you do things the way you do. Do we really need to clutter up the realionship window with yet another TO and add a subscript?

I have attached another example with a layout like the one you provided. Works fine for me but I'm sure you will find something wrong with it.

ValueList.zip

[Sam W]

Thank you both for considering this problem.

It appears that both of these files seem to require another data entry, or to execute a script.

Based on this, it appears that there is no way for the "font fields" to be automatically populate, such as adding a new text parts record with the font "sigLisa" and have it show up on the component page?

Also, Søren how are the records populated in the "text parts" table? I may be blind (wouldn't be surprised) but I see no records in that layout.

thanx, sam

[Søren Dyhr]

Do we really need to clutter up the realionship window with yet another TO and add a subscript?

No unstored calcfields are fine, but your approach becomes trickier if the specifications suddently changes and the number of occurences are wanted as well.

I have a priciple not to make redundant occurences of the same data and move as little as posible from the location where it resides. But I agree with the present spec's does your approach deliver - due to the existence of unstored calc'fields

Also, Søren how are the records populated in the "text parts" table?

They aren't populated at all!!! - every first occurence is singled out to be shown in the new relations portal - so basicly is it already existing records. The reason you don't see any records is that the algorithm omits them in sets with similar font. What I've made is the process that goes on when you export summaries ...here just kept inside the solution, so what goes on is only slicing and dicing already existing data in another way.

Based on this, it appears that there is no way for the "font fields" to be automatically populate, such as adding a new text parts record with the font "sigLisa" and have it show up on the component page?

There is! But it's taking filemaker as tool out of the database realm, and especially is the denormalization a camel to digest. You have to consider if really is a database task you wish to perform.

A thing or two can be learned in that direction by studying these templates:

http://www.kevinfrank.com/download/repeating-lookups.zip

But building every solution at hand by these unique and engenious ways are dangerous, since it's a decision tough to fit in ordinary database theory.

Think of these techniques as decorations on the tree. They can be wonderful and dazzling, but too many of them may bring down the whole tree.

--sd

[comment]

It appears that both of these files seem to require another data entry, or to execute a script.

That is not entirely correct. In the first file by sbg2, the "summary" field populates automatically. The problem - if it is a problem - is that changing the portal data does not cause the window to refresh. The data is already there, you just don't see it yet. But if you need to use the data for anything (e.g. printing), you will always get the correct, updated data, with no additional step required.

[Søren Dyhr]

As usual, I'm not quite sure why you do things the way you do.

Well I have one for you as well : could you explain why you do all this:

Go to Related Record [ From table: “Component”; Using layout: “Fonts Used” (Component) ] [ New window ] 

Move/Resize Window [ Current Window; Height: 600; Width: 350; Top: 50; Left: 300 ] 

Allow User Abort [ Off ] 

Enter Find Mode [  ] 

Set Field [ Component::ID_Component; Get(ScriptParameter) ] 

Perform Find [  ] 

Show/Hide Status Area [ Hide ] 

Pause/Resume Script [ Indefinitely ] 

Close Window [ Current Window ] 

...when this does the same:

New Window [ Name: "plingeling"; Height: 600; Width: 350; Top: 50; Left: 350 ] 

Go to Layout [ “Fonts Used” (Component) ] 

--sd

[Søren Dyhr]

It appears that both of these files seem to require another data entry, or to execute a script.

Well it seems like you actually can have it your way ...on the fly:

http://www.nightwing.com.au/FileMaker/demos8/demo803.html

...unfortunatly do you have to upgrade to FM8 Adv. when you develope it - but deploying it makes every version of fm8 a choise!

--sd

[sbg2]

It obviously doesn't do the same thing.

I use the find to limit the pop-up to only the current Components font list, this way Administrative Amy can't accidently scroll onto the wrong record. Perhaps you prefer your users to be able to view unrelated information in a pop-up window? The user is looking for a list of fonts used for this component not all components.

The Allow User Abort and Pause steps are so Administrative Amy doesn't end up with 500 Fonts Used windows open.

[Søren Dyhr]

I use the find to limit the pop-up to only the current Components font list, this way Administrative Amy can't accidently scroll onto the wrong record. Perhaps you prefer your users to be able to view unrelated information in a pop-up window? The user is looking for a list of fonts used for this component not all components.

Point taken, but you have to explain what the GTRR is needed for - When this scripting does what you want to keep Administrative Amy away from, even Counterstrike Clive lacks hidden features to get his way with it!

New Window [ Name: "Fonts used"; Height: 600; Width: 350; Top: 50; Left: 300 ] 

Allow User Abort [ Off ] 

Show/Hide Status Area [ Hide ] 

Omit Record 

Show Omitted Only 

Go to Layout [ “Fonts Used” (Component) ] 

Pause/Resume Script [ Indefinitely ] 

Close Window [ Current Window ] 

--sd

[sbg2]

GTRR is not needed, New Window works fine. Originally I had planned to use GTRR to reduce the shown record to only the one component. When I realized this would not constrain the records to the one component I used the Find to perform the task, never went back and changed the GTRR step because it worked how I wanted.