Relying on Perform Find using its configuration panel for the query and variables instead of switching to find mode and set field and new request scriptsteps - as mentioned in the FileMaker Talk Podcast about Cloud 2.0 of Nov 7th 2019. I experienced this bug once using FMP14 client searching with find data hosted by FMS13. Any thoughts?
I listened to the excerpt.
Iāve never experienced unexpected or buggy behavior with using the Perform Find step with configuration.
Of course, that doesnāt mean that no such bugs exist (or did exist). Obviously it just means that either I never encountered them, or was not aware if I did. While I have no reason to doubt the speaker who asserted that the step is unreliable, in the brief excerpt that I listened to, he didnāt seem to provide any specifics that one could pursue to attempt to find a reproducible case.
Attention in the recording then seemed to turn to the more common complaint that I hear from other developers which is that they donāt like the step because they feel that it is difficult to understand, read, and debug.
In the greater context, the understanding and debugging point of view has always seemed like a matter of personal taste to me.
As for unreliability:
This would definitely be something to take seriously. If it were just about anybody else, I might wonder if a developer who does not fully understand how to configure complex sequences of find and omit requests were truly the cause of the error. But, @FileKraft, I know you to have one of the sharpest and most exacting minds that I have ever met, and so if you tell me that you encountered a bug with this, I throw any and all such suspicions aside.
It would have been nice if the podcast presenter had been able to include a few more details.
Thanks for sharing the excerpt and bringing the added dimension of podcast listening to the forum.
Sincerely,
-steve
1 Like
Hi @FileKraft
The Perform Find step with its panel is the thing that never let me down since FM v10.
It has is one catch: one has to be careful to select the relevant TO for the layout the find is acting on.
Did you encounter that issue with a recent version v17, 18?
Iāll yet have to listen to the podcast.
Cheers
David:
My opinion? The script action is reliable. I did not listen to the audio program. I can not comment on its content. I remember, however, that more rigor was needed with FileMaker 14 by using this script action with variables. The variable should contain a result of the same type as the type of topic in the query. It was hairy in the case, for example, of a range in a number field.
The script step has since been modified. We can now have a text variable for a number field without a hitch, assuming that the result is valid for the search.
2 Likes
Thank you very much for reviewing this topic brilliant @steve_ssh and your evaluation and mostly backing up the sanity of my mind (in this matter)!
The case where I came across this anomaly was only once as said FMS13 and FMP14 doing a fully specified Request Find [ Criteria specified within ]. And the workaround to that time was checking if the clientās Get ( ApplicationVersion ) > 13 and Get ( FoundCount ) = 0 (<1) then just repeating the same Perform Find again and that worked. It seamed like the perform find was out of sync therefor the second run fixed it. I reported it years ago when 14 was out. IIRC it was around FMP14v4 assuming it was pretty safe to switch to 64 bit after fourth revisionā¦
Anyway - that podcast comment made me wonder and glad for you chiming in as others who also had no issues - so far I never had any other issues with it myself. Would be great if the podcasters would elaborate though.
Thank you!
Came across another podcast with some Find Duplicate anomaly. The wonderful podcast called āContextā as of today Nov 26th 2019 with Kevin Frank as a guest discuss a workaround to fix an issue with Constrain Found Set using Duplicate search as far as I understood. And the workaround for a fix is to create an unstored calculation of same field and search for the duplicate ā!ā there which works.
I listened to that podcast episode as well and tweeted about it. I prefer the more visible version of Perform Find. Perhaps that is why I have not had the issue that was reported.
3 Likes
I hate to be a curmudgeon, but Iām pretty suspicious of Mattās claim. I feel it is more likely an issue of corruption or (forgive me) developer error. I really needed some specifics and reproducibility (reliability) on that. Iāve never seen bug reports or anything that demonstrate the issue.
Again, I have immense respect for both Matts in that podcast, but even great developers make mistakes and sometimes itās easy to think youāre testing one thing but encountering a confounding factor that pollutes your results. I would love to look into this more if I had any specifics to go on.
I suppose itās possible I just havenāt seen it since Iām an Enter Find Mode guy, but idk.
2 Likes
I did hear the podcast but havenāt had time to read all posts here.
However, there are a number of users of a certain age that got burnt some years ago when FileMaker released their annual (I believe it was annual back then, but maybe not) upgrade and if for instance you entered:
Perform Find on āNameā field using a variable of ā$findNameā
and $findName was empty, FileMaker carried out a search on $findName (I.e. the equivalent to entering in the destination field ā$findNameā.
This caused havoc with scripts and, ever since then, we use Find, Set Field, Perform Find (without any find request information) for fear of a future repeat.
3 Likes
exactly what happenend to me and I moved (back) to Tonys version B
appart from getting burned it makes code way more readable when working in a team
2 Likes
That is the experience I had also. This is, for me, a case of not being willing to rely on FileMakerās black-box-y behavior. So I have always used the Find Mode-Set Field approach.
I am also very verbose in how I script. When a calc is complex, I may, more often than not write each āstepā of the calc out to its own variable. So I can see without any dialog hoping, exactly what is being calculated. If it is something that does a lot of looping on a large dataset, I may build in a debug mode, but consolidate the multiple steps down to a single step to avoid the extra overhead of generating the additional variables. Very use-case dependent.
3 Likes
Configuration of the find within one Perforn Find non-modale is preferable (assumed reliable) and complies to Jeff Raskinās humane interface guidelines if scripting would be considered an HUI (human user interface) IMHO. Borrowing Jeff Raskinās argument the Set Field would be risky if dependent on window modeā¦ I think FMI / CII already fighting this danger people entering data in find mode and warn if multiple new request occur because of users loosing data assuming the wrong state/window mode. This easily applies to failing mode switches now also trigger sensitive and jeopardized ā¦ within scripting as discussed.
I bet this has been silently fixed and using the old fashioned way as a safety measure is not that safe as I m trying to argue here. Thanks!
2 Likes
I am glad to see that you brought up the concept of modal vs non-modal dialogs.
The āSpecify Find Requestā dialog that lives behind the āPerform Findā is modal.
Modal dialogs are a bit harder to work with as they lock you out of other areas of FileMaker where you might go to pick up strings to populate your code.
I am often in no mood for modal!
2 Likes
Controlling the window mode is just part of the game. It has to be done any way, along with checking the found set to make sure it's not showing you All Records.
Now throw into the mix, users on different versions... Which version(s) were fixed, which version(s) are broken? I'm also not sure I agree HUI should be applied to scripting.
That comes back to Simplicity vs Complexity. The complexity lives somewhere. It depends on where you are willing to pay for it. Now that I fully acknowledge is different for every person. For example, me, I don't like the complexity of having to open additional dialogs when I'm debugging to see what something is doing. So I pay for the complexity when building the code. And maybe a little bit when running the code. Others, may prefer to write code faster, and pay for the complexity during the debugging process.
2 Likes
There are indeed some steps that play "double duty" depending on the window mode. Arguably, the set field step does what it claims, only in a record or in a request. (like pretty much every step for the Editing and Fields categories). I'm not sure I would be a fan of a "set request field" script step, but my mind is not quite set on this.
I'm more concerned by the steps from the Records category, all of the ones ending by "Record/Requests":
- Commit
- Copy All
- Copy
- Delete
- Duplicate
- New
- Open
- Revert
I feel like those are way riskier should they run in the wrong context, and it is almost impossible a dev would write a script that uses the same script step to delete/duplicate/create a find request than to do the same for an actual record (unless the script only use is to mimic the native menu item).
That said, a dedicated "delete request" step in browse mode would probably throwback what I feel like is too often a FileMaker "catch-all" error:
3 - Command is unavailable
I say "catch-all" because when this error arises I feel like they could have been more explicit as to what is causing the problem.
Splitting those or the set field and similar would mean backward compatibility would be an issue, the only implementation that I can think of would be to add checkboxes to limit what modes these can act on, something that is harder to read than most other settings. I already see myself copy-pasting content from a browse script to a search script trying to figure why the step fails only to realize after 45 minutes of debug that I forgot all about the checkboxes that were nested 2 levels down subdialog windows. Claris would then need to make a "show compatible script steps" button in the script workspace not just for products (go, WD, win/mac, server,...) but also for window modes!
There are some things that are hard to fix/change (depending if you consider this design as broken or not) once you started doing things one way.
2 Likes
Depending on the larger context:
-
In some cases I consider a Enter Find Mode, Set Field approach to be most readable.
-
In other cases, I consider a single Perform Find step with a preceding single-line comment to be more readable and easier to debug and maintain than using the approach of entering Find Mode and setting fields.
Over the years Iāve seen more than a handful of discussions on the above topic, and I would say that pretty much every point I have seen in any such discussions holds up well within certain specific contexts. But I have yet to walk away from one of these discussions feeling convinced that there is a one-size-fits-all-situations-best approach to this.
Rather than attempting to post examples to illustrate how Iāve reached my above conclusions/opinions, Iāll draw attention to this instead:
The fuel that seems to be behind nearly all of the points that come up in these conversations is that we all want our code to be reliable, trustworthy, readable, and maintainable.
2 Likes
Completely agree. I was think about cases where I do use the Perform Script [Restore]. I didn't think of a use-case where I use it all the time. That is forcing a zero found set. A comment and Perform Script is all I use.
Most of our finds involve several Perform Find...Constrain Find...Extend Find... along with dozens of other complex business rules about what to show to who, it's clearer to have it all spelled out. That's obviously a very personal experience that affects my view.
I also don't get angry when I see a Perform Script step all by itself, unless it doesn't give me the expected result. LOL
The only thing that make me pull my hair out more is when I get the expected result without being able to explain why it works. 
2 Likes
lol ā¦ there are days like that for me too. Iāve landed a lot more in a place where, if it worksā¦ on to something else.