Go To Record/Request/Page Calculation

[S. Hander]

I am trying to create a script that will jump to the first record that has today's date in it. I thought I could use the Go to Record/Request/Page with a calculation, but I can figure out how to calculate for the row number. I think what I want to do is this:

Row Number = 1st Record with field DateRequired contains get(currentdate)

But I am not sure of the syntax to get this result. Is this even possible?

[David Jondreau]

"Go to" refers to the placement of the record in the found set. You can use that to pull data from the record itself.

How about:

Enter Find Mode

Set Field [date Get(CurrentDate)]

Perform Find

Show All

[Raybaudi]

Enter Find Mode [ ]

Set field [yourDateField; Get(CurrentDate)]

Perform Find [ ]

Go to Record/Request/Page [first]

[S. Hander]

Sorry, I guess I left out the whole story. The function is part of a script I create to display all records, then sort by required date. Since that includes past records, I wanted it to scroll to the first record with the current date. From there a user can scroll backwards or forwards.

Does that make sense?

Edited April 11, 2007 by Guest

[mr_vodka]

I think that the easier way to do it is to have a global date field that is set with the current date. Then create a relationship from this global field to your Date field. You can now show all records, sort it by date, and use Go To Related Record script step. You may not need the sort, if the creation of the records can be used as the sequence of the entry date.

[Raybaudi]

...or you can add these steps to your existing script:

Go to Record/Request/Page [ First ]

Loop

Exit Loop If [ YourDateField = Get ( CurrentDate ) ]

Go to Record/Request/Page [ Next ; Exit after last ]

End Loop

[S. Hander]

That works perfectly. Thanks Daniele!

[Raybaudi]

This is another way using $ variable and the Scroll step, so to have always the found record at the top of the screen.

Set Variable [ $record ; Value: 1 ]

Loop

Exit Loop If [ GetNthRecord ( yourDateField ; $record ) = Get ( CurrentDate ) or $record = Get ( FoundCount ) ]

Set Variable [ $record ; Value: $record + 1 ]

End Loop

Go to Record/Request/Page [ No dialog ; $record - 1 ]

Scroll Window [ Page Down ]

Go to Record/Request/Page [ No dialog ; $record ]

[mr_vodka]

Yes but why go through the whole process of running a loop script when it can be so easily done with GTRR??

[Søren Dyhr]

Yes but why go through the whole process of running a loop script when it can be so easily done with GTRR??

Indeed, as long as the tables are in the same file - with migrated solutions is it another thing, if the tables havn't been joined in one file - (yet??).

--sd

[Ender]

Huh? This would likely be a self-join. Those are usually within the same file. But even for relationships to tables in other files, the Go to Related Records[] step still works.

[Søren Dyhr]

Yes that was the missing part in you reply!

the Go to Related Records[] step still works

No only as non-script caller buttons - I'm afraid. I have often kicked tubleweeds here. I would always for starters merge all tables into a single file, and then perhaps the separation model.

Well it might somethig I gladly have ignored here - since I usually make the relational stuff in one file only.

--sd

[Ender]

No only as non-script caller buttons - I'm afraid. I have often kicked tubleweeds here.

I have no idea what your talking about.

I would always for starters merge all tables into a single file, and then perhaps the separation model.

These are mainly maintenance choices. The behavior of GTRR and other scripts can be accommodated in however many files are used.

[Ender]

Happy 3000, BTW! You get a dancing banana for that:

:yay:

[Søren Dyhr]

Alright take a look at this template! Poke into test.fp7 and press each of the buttons - what am I missing here?? They're seemingly identical - but not quite?

--sd

ToEnder.zip

[Ender]

But it does work. It just doesn't bring the other window to the foreground automatically. You need to add a Select Window in the calling script or the sub script. In converted solutions, this is automatically added, but sometimes has to be tweeked, like when there is multiple hops involved.

This is covered in the Migration Foundations & Methodologies tech brief.

[mr_vodka]

Hmmm understandable that a select window would have to be used to bring it to the foreground but it is indeed strange that a direct call from a button doesnt require one.

[Søren Dyhr]

You need to add a Select Window in the calling script or the sub script.

Ah! A part in migration foundations I've scated over swiftly... apparently. I usually solve it by a request made in the arrival file ...if a table merger isn't more obvious move. I'm fully with Kaschel when he writes:

Don’t fall into this silly trap. FileMaker developers have been begging for single file FMP databases for years. They are wonderful, and a great boon to development. Don’t let yourself be bullied into doing things the old-fashioned way for nothing. If you can at all avoid using the multiple file approach, do so.

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

Happy 3000, BTW! You get a dancing banana for that

Cheers, if it weren't for the wopping number of post containing a fair share of misinterpretation on my behalf, and similar cryptic answers which wears very little in common with proper english!

--sd

[comment]

strange that a direct call from a button doesnt require one

A direct call from a button would be pretty useless otherwise.

[Søren Dyhr]

but it is indeed strange that a direct call from a button doesnt require one

So I'm not the only one feeling it's a little counter intutive - Thanks it gives comforting feeling, John.

A direct call from a button would be pretty useless otherwise

It is indeed, but do you often use to assing oneliners to your script, I follow ...again Kachels advice to make a script for each, in case something else will turn up to be included.

--sd

[mr_vodka]

A direct call from a button would be pretty useless otherwise.

Hi Michael,

Could you elaborate? I always thought a direct call from a button was just so that it was easier for a developer to develop and not have to create scripts for every function call.

From a practical sense, I have always used buttons to call scripts. To be honest, I always thought the direct call was kind of useless for my purposes. I dont see where this behavior is documented. I always thought that whether you did a direct call or a call via a script it would behave the same.

[Ender]

...if a table merger isn't more obvious move. I'm fully with Kaschel when he writes:

This is one of the reasons I don't care for David's treatise (sorry Mr. Vodka, I know you're a fan). I don't particularly like the unsupported assertion that there's something inherently wrong with multiple files. But worse to me is the attitude that HE knows better than everyone else. Unfortunately, it's hard to debate a document.

I've written many times (without bullying, mind you) about the trade-offs between multiple files vs. single file. To me this is more valuable than simply discarding opposing views with no reasoning to support it.

[mr_vodka]

Hi Mike,

Well I am not necessarily a huge fan. I simply have a link to his whitepaper because I think it is a good read in general and it answers many questions that newbies have (the biggest reason). Another benefit is that there really isnt anything else like it that I know of. It seems to be a good bridge for newbies between the junk they call FM documentation and larger books which usually deal with other details. Much like anything it is an opinion and as I have stated in the past, I do not agree with all of his methods, nor do I practice all his methods.

It would be wise for others to make their own conclusions and solutions based off various techniques and not solely one. In the end an opinion is an opinion and can vary depending on the source as well as the outcome.

Your previous posts regarding the pluses and minuses of multiple vs. single files hold a lot of merit and I am sure that many have benefitted from them, including me.

Now regarding the topic of direct calls from buttons, even before Kachel wrote his whitepaper, I never used direct calls from buttons. I guess that was was own development standard that I used because it was easier manaagement for me. Again, I was under the impression that it would act the same as going through a script call as well. Had I known that the behavior would be different, I might have done things differently. Do you know where these differences are documented?

[mr_vodka]

Hmmmm... Maybe its time to put in a disclaimer in the signature file...

Don't want to give the wrong impresssion that I live and die by the whitepaper...

[Ender]

Now regarding the topic of direct calls from buttons, even before Kachel wrote his whitepaper, I never used direct calls from buttons. I guess that was was own development standard that I used because it was easier manaagement for me.

I don't know where David has weighed in on this, but I'm with you. It's easier if the buttons are attached to scripts right off the bat. Inevitably, additional steps get added to navigation scripts.

Again, I was under the impression that it would act the same as going through a script call as well. Had I known that the behavior would be different, I might have done things differently. Do you know where these differences are documented?

If you know to use Select Window[] after a GTRR, then there's no problem.

I seem to recall discussing this a couple years back, but I can't find anything on it now. To me the differences make sense. I think it's always desirable to have a GTRR button switch to the target window, but it is not always desirable for a script to do so.

[comment]

Could you elaborate?

I can only repeat what I said here.

[Ender]

Thanks comment, I looked all over for that thread. ;)

[mr_vodka]

Excellent. Are there other ones that we should be aware of?

[comment]

If by 'other ones' you mean undocumented quirks, then I'd say yes - quite a few.

[mr_vodka]

Lol. Well not really. I know that there are tons of undocumented quirks but I meant more specifically, quirks with direct function calls from a button rather than via a script.

[comment]

Oh. The only thing I can think of right now is Go to Field[], when the entry to the field is disabled.