List View Script Bug?

[Ninjason]

I'm using a script to navigate to a couple of list view layouts. One layout if for the status area showing, one is for when it is hidden. I copied the script from another database. For some reason, the script works in the other database, but not mine. I have the script attached to a button, but when I click the button or run the script from the menu, nothing happens. I have FMP 8, so I don't have the debugger. Does anybody know of a FM bug that might cause this?

Here is the script:

If [Get ( StatusAreaState ) = 1 or Get (StatusAreaState) = 2]

     Go to Layout [Get ( LayoutTableName ) & "_List1"]

Else

     Go to Layout [Get(LayoutTableName) & "_List2"]

End If

I have checked and double-checked my layout and table names, and everything matches up.

[mr_vodka]

What layout are you running the script from? Does it have the status area open or closed?

Also maybe you should just have the Go to Layout script going to the layout that you want it to rather than relying on using the Get (layouttablename) function.

Have you tried to change it to the layoutname directly to see if it works like that?

[Ninjason]

I am running the script from a layout called "CUSTOMERS_Form" and go to either "CUSTOMERS_List1" or "CUSTOMERS_List2" depending on the status area. The script is supposed to run wether the status area is closed or open. I have tried it on both, and neither of them work. The script works if I change the script to say:

If [Get ( StatusAreaState ) = 1 or Get (StatusAreaState) = 2]

     Go to Layout [("CUSTOMERS_List1" (CUSTOMERS_Storage)]

Else

     Go to Layout [("CUSTOMERS_List2" (CUSTOMERS_Storage)]

End If

However, I wanted the script to be dynamic across multiple tables (so I didn't have to write a script for every table in my database).

[ThatOneGuy]

Hi Ninjason:

Just a shot in the dark here ... try wrapping your calculation inside the Evaluate function, so that it reads like ...

Go to Layout [ Evaluate ( Get ( LayoutTableName ) & "_List1" ) ] )

I wouldn't think that it would be necessary, but it might work. If it is indeed successful, it still wouldn't explain why it worked in the file from which you copied it.

Anyway, just a thought.

[mr_vodka]

Ninjason,

It seems as though the Get (layouttablename) function returns the Table Occurence name instead of the root Table name. so in your case it returns 'CUSTOMERS_Storage' and hence doesnt work.

[Ninjason]

One Guy and John,

Thanks for the replies. John, you were right. I changed my table occurance name to just "CUSTOMERS" and now the script works great. I appreciate the help.

[ThatOneGuy]

It seems as though the Get (layouttablename) function returns the Table Occurence name instead of the root Table name. so in your case it returns 'CUSTOMERS_Storage' and hence doesnt work.

With all due respect, I think you've got this backwards. Get ( LayoutTableName ) does indeed return the name of the underlying Table. On further inspection, Ninjason has his table named CUSTOMERS_Storage ... I should've caught that before.

[Ninjason]

ThatOneGuy,

I believe John is right. Although, FMP Help says Get(LayoutTableName) returns the name of the table, my table was always named, CUSTOMERS. It was the table occurance that was named CUSTOMERS_Storage. Only when I changed the name of the table occurance did it make my script work.

I created a calculation field and placed it on my layout to test it. The field changed when I changed the table occurance name.

[ThatOneGuy]

Hi Ninjason!

Thanks for reporting the results of your experiment. It prompted me to dig deeper if I wanted to defend my premise. I believe we can refine this by restating it as ...

Get ( LayoutTableName ) returns the name of the underlying Table, or similarly the Table Occurrence, upon which the Layout is defined.

Your earlier post included this code ...

If [Get ( StatusAreaState ) = 1 or Get (StatusAreaState) = 2]

     Go to Layout [("CUSTOMERS_List1" (CUSTOMERS_Storage)]

Else

     Go to Layout [("CUSTOMERS_List2" (CUSTOMERS_Storage)]

End If

... which reveals to us that both layouts are defined to Show records from the CUSTOMERS_Storage table occurrence.

Another way to look at it is that, if these layouts are defined upon your CUSTOMERS table (or table occurrence), the calculations in your original script should work.

Thank you for the opportunity to clarify my remarks. We've all probably benefitted from your topic. I know I've learned the significance of the function's name ... I had never had any problems with its use because my layouts are almost always defined upon the base table occurrence.

By the way ...

I changed my table occurance name to just "CUSTOMERS" and now the script works great.

Prior to doing this, was there not already a table occurrence on your graph called "CUSTOMERS?" If so, what happened to that table occurrence when you changed the name of the "CUSTOMERS_Storage" occurrence to "CUSTOMERS?" Just curious.

Edited November 3, 2006 by Guest

[comment]

Get ( LayoutTableName ) returns the name of the underlying Table, or similarly the Table Occurrence, upon which the Layout is defined.

I don't think that is an accurate description. I would say that:

[color:blue]Get(LayoutTableName) returns the name of the table occurence that is defined in the setup of the current layout as the table occurence to show records from.

If the table occurence happens to have the same name as its source table, that's a mere coincidence.

The Help doesn't get it quite right either:

"Returns the name of the table from which the current layout is displaying records."

But if you Go to Related Record [from table: "Child 2"; Using layout: "Child" (Child)], Get(LayoutTableName) is going return "Child", even though the current layout is now displaying records from Child 2.

[ThatOneGuy]

The Help doesn't get it quite right either:

"Returns the name of the table from which the current layout is displaying records."

No, it's a bit vague, isn't it? Perhaps it could be clarified as ... "Returns the name of the table occurrence from which the current layout is defined."

But if you Go to Related Record [from table: "Child 2"; Using layout: "Child" (Child)], Get(LayoutTableName) is going return "Child", even though the current layout is now displaying records from Child 2.

This seems congruent with the way the Get ( LayoutTableName ) function operates ... if not the way it's explained in FM Help. Isn't the layout (with its underlying TO definition) still driving the function?

[comment]

'Vague' seems to be in the eye of the beholder: I don't see a layout as being defined FROM a TO. When you define a layout, there's a 'Show records from (TO)' attribute. It is this attribute that's returned as the result of Get(LayoutTableName).

Perhaps a short way to put it might be:

Returns the name of the table occurence from which the current layout is set to display records.

[ThatOneGuy]

I don't see a layout as being defined FROM a TO. When you define a layout, there's a 'Show records from (TO)' attribute.... [Emphasis added.]

But you wouldn't consider this attribute as part of a layout's definition?

I give up.

[comment]

Deep into semantics... It is precisely because I DO consider this attribute as part of a layout's definition, that the sentence

"Returns the name of the table occurrence from which the current layout is defined."

does not sit well with me. It implies that the layout is an attribute of the TO. The truth is that a table has occurences, and occurences have layouts. I don't consider children as parent's atrributes.

[ThatOneGuy]

Would "upon which" satisfy your parsing routine?

[comment]

No. Let me get serious for a moment. There are some rules for writing technical documentation (or at least there ought to be). It needs to be very exact and literal. The reader is not supposed to make assumptions.

If, in defining the layout, the dialog says "Show records from <>", then that's the exact language you need to use when referring to this. It does not say "Define this layout upon <>", and at least in my mind it takes quite a leap to connect the two.

I am on a soap box, because it seems to me that FM documentation is getting progressively worse. Does anyone understand the help for List() function?

[mr_vodka]

IMHO, I always thought that FM documentation was suffice. ???

[mr_vodka]

Oops forgot the "not"...

I meant that I always thought that the documentation was insufficient.

???