Jump to content

summary (but not number)


Sam W
 Share

This topic is 5756 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 5756 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.