Placing a Script Name in a Layout Header and Title Header

[fmwannabe]

I might be in over my head on this, and maybe headed in the wrong direction:

 

My solution will include about a dozen or more nearly identical reports. These are all simple lists with the same title header, header, body, sub-summary, title footer, and footer. The only thing different is the found set.

 

So, rather than create and support (and update when needed) a dozen or more layouts, I had the idea of using the same layout for each report. So far, so good. But the reports needed to be printed both to screen and to paper. How would I be able describe the found set? How would I know what I was seeing?

 

I started looking around at functions and script steps, looking for a way forward, and came across Get(ScriptName). This seemed perfect: the script name would be descriptive anyway because users would select it from a menu. So, the scripts would be named All Black Widgets, or All Red Widgets. Sweet.

 

At first I just used SetField, which worked in the header but not the title header. But more seriously it won't work because when a user invokes a simple script that we use to move around in the found set ['next record' or previous record'], the 'get' grabs the currently running script. Funny, I thought. I didn't know why the script would do that, so I put an Exit step in the script. Same result. 

 

This seemed simple enough. I tried creating a global that auto entered the 'get' into a text field. I tried simply using the get and then in the same script using a Go To Field step to copy/paste and isolate the value. I tried…well, several other directions, none of which worked, and several of which gave very unpredictable results.

 

I am doing something wrong. The Problem Statement is this: How do I place the name of the calling script into the title header and header of a layout? Is it even possible?

[comment]

At first I just used SetField, which worked in the header but not the title header.

 

This part is not clear. If you used a global field (as you well should) there's no reason why it wouldn't work in any part, including title header. Another option is to use a global variable merged on the layout - but a global field is better for troubleshooting.

 

BTW, since each script sets the field to something that is unique to the script, you are not limited to the script name; you could simply include a literal text label as part of each script. It would be different if you used a single script with a different script parameter for each variation (something you might want to explore in the future).

 

 

 

I tried creating a global that auto entered the 'get' into a text field.

 

That cannot work because there's nothing that would trigger the field to recalculate.

[fmwannabe]

I  managed to make it work (Thanks) with one exception. This script step, which is the heart of the idea

 

Set Field [List::gName;Get(ScriptName)]

 

evaluates perfectly on the List layout Title Header but not Header! Argh. Tomorrow's another day. Has to be a reason…

 

Also, you wrote something that confused me:

 

 

BTW, since each script sets the field to something that is unique to the script, you are not limited to the script name; you could simply include a literal text label as part of each script. It would be different if you used a single script with a different script parameter for each variation (something you might want to explore in the future).

 

Two things: where would I inset literal text? This has real possibilities I hadn't considered. My sense was that the script name would be called and nothing else?

Secondly: Yes, I was planning to use the exact same script, changing only the name of the script. I would generate each script by first performing the find so the Perform Find [Restore] step would capture the criteria, making the whole process pretty simple.

[comment]

where would I inset literal text?

 

You could do it right there in the Set Field [] step:

Set Field [ List::gName ; "Any text you want goes here" ]

The step is stored as part of the script, so you can rename the script without changing the text and vice versa.However, you do need to change the text if you duplicate the script and use it for another report.

 

 

 

Yes, I was planning to use the exact same script, changing only the name of the script. I

 

That's not quite what I meant. You could (probably) use one script for all the reports, something like:

If [ Get ( ScriptParameter ) = "Big Report" ]
  # FIND CRITERIA FOR BIG REPORT
  Perform Find [Restore ]
Else If [ Get ( ScriptParameter ) = "Small Report" ]
  # FIND CRITERIA FOR SMALL REPORT
  Perform Find [Restore ]
End If
Set Field [ List::gName ; "This is a " & Get ( ScriptParameter ) ]
...

[fmwannabe]

You have over-estimated my ability. Passing script parameters for me is like passing under a 12" limbo bar.

 

My simplistic thinking won't work:

 

Go to Layout ["Master Data" (Data)]

Perform Find [Restore]

Go to Layout ["List by Type" (List)]

SetField [List::gName; "Get(ScriptName)"]

 

The global would be in the Header and Title Header. Simple, painless, easy to debug. Except it does not work.

 

Argh. But thanks much.

[comment]

Passing script parameters for me is like passing under a 12" limbo bar.

 

Well, one  step at a time. Although I assure you it's well worth the effort. I mean the script parameter - I don't know about the limbo.

 

 

I am puzzled by your script: you perform the find in the "Data" table, yet the layout is based on the "List" table? This may be unrelated to the issue, but it is puzzling. Incidentally, "Data" and "List" are not good choices for naming a table. All tables are lists of data. Name each table by what does a record in it represent, e.g. Invoices, Customers, Assets etc.

 

 

The global would be in the Header and Title Header. Simple, painless, easy to debug. Except it does not work.

 

Are you sure the field is really defined to have a global storage, not just named with a "g "prefix?

[fmwannabe]

global: got me there. Opps. That explains a few things…

 

Once I moved the report back to Data and fixed the script steps all was sweet. But there was a reason I was headed in that direction. I was trying to make that simple report, yes, but also need a report that would show widgets by client. I wrongly figured I could simplify. Now that I have the report working (thank you very much).

 

And now it works! It satisfies my original goal of using a single layout to show many different find requests. Since it is a single layout, updating the 'look' will be simple.

 

The need to show widgets by client is set up like this: adding a table called List (and I take your point about names). It is related to Data by SYM (widget symbol) and to Contracts by Project Number (and incidentally to Addresses and Proposals. Many of these tables are legacy having started from very early editions of flat FileMaker Pro.

 

So, if you are still with me, I figured that the need for a simple widgets by color could be combined with widgets by client. Wrong. Once those were separated everything worked (well, so far; still have to make the widgets by client work).

 

Given all of this are parameters as you suggested still something I should be thinking about?

[comment]

So, if you are still with me, I figured that the need for a simple widgets by color could be combined with widgets by client. Wrong.

 

I don't see why not, provided the layout requirements are not too different. You just need to add a sub-summary part [when sorted by client] and have the script sort by client. Note that sub-summary parts do not show if "their" field is not in the sort order - so you can make different sub-summary parts show or hide just by applying a different sort order.

[fmwannabe]

Thanks so much for help. Filemaker lets a wannabe like me blunder into a solution that works, most of the time, but building a really professional solution is left to the pros. I'm now taking the info into my solution.

 

I didn't think about your idea for not adding another table but it's much easier. Not working in DBs regularly I don't have a sensibility about how the data looks globally.

 

Too bad it's fun :-) It is, though. When I was in grad school and had to pay undergrads to prepare punch cards (not kidding), getting a program to actually do what I wanted was a hell of an accomplishment. With FileMaker Pro, every time I dig into scripting I find something new and useful. This time it was GetScriptName. 

 

I'm bowing out for now as I slug this out.   No doubt I will be back.

[fmwannabe]

He's back. There has been progress.

 

My simple scripts are creating many instances of the same report/ window name. And figuring out if a window instance exists is creating too much complexity.

 

So I went back to your suggestion of passing a ScriptParameter, which I have come to understand is a type of global that only exists inside a script and when the script is running. It's a handy way to identify which script is running.

 

If [ Get ( ScriptParameter ) = "Big Report" ]
# FIND CRITERIA FOR BIG REPORT
Perform Find [Restore ]
...
 
The ScriptParameter concept is sinking in (always wondered what that was). I don't visualize a user interface, though. Maybe it is a layout with buttons, each scripted to a different find. That would actually work since eventually this will be used on FileMaker Pro Go. Need to experiment.

 
[Do I need some sort of elevated status to use the color/font and other options in the tool bar, I wonder?]