In 12 and before you can use the "Delete Portal Row" script step, no need to capture keys and all that.
As to your point: when someone uses the new functionality in 12, it will delete the parent record. Not a big issue: as soon as you start using any FM13 functionality you have to branch your code or use the toggle that you mention to prevent FM12 from opening your file. I think that's very much understood.
You know how every now and then, you're hitting a nail with a wrench… (either because you've always used a wrench or never knew the hammer was there), and then someone sees you and says to you, "Hey, why don't you use that hammer instead?"
Anyway… this realization begs the question: If there already was this functionality, why the change? Oh well.
Now, I have some scripts to clean up…
Shawn: already WHICH functionality?
New behavior has been introduced in FileMaker 13.
You can read about it. As they say.
If there was already this functionality - then why were you not using it? Why do you have to change anything?
The functionality that was available and has not changed is to delete a portal row with the specific script step, delete portal row.
Bruce, yes, that is what I was saying…
My wording might not have been clear.
Shawn: already WHICH functionality?
… then why were you not using it?
The functionality to delete a portal row. I wasn't using it because… I don't know. I'm an idiot? I guess I had never noticed it. See my note about the hammer. Feeling a little embarrased about that one.
What I was asking is this: Since there already was the functionality to delete a portal row with the "Delete Portal Row" script step, then why did they change the behavior of the "Delete Record/Reqest" script step to duplicate the function of Delete Portal Row?
Why do you have to change anything?
I don't HAVE TO change anything… just now that I know the hammer is there, I'm going to go through a few scripts and replacing 6 or 7 script steps with 1. An easy efficiency gain, that will probably have less chance of something going wrong, since I won't be setting variables and opening other windows. Again, embarrased that I was doing something the hard way, so trying to delete the evidence!
The "Delete Record/Reqest" script does not duplicate the function of Delete Portal Row.
The Delete Portal Row step does ONLY that.
The Delete Record/Request step has been expanded in functionality to be "smarter" about its context and detect that it is being called from within a portal row.
Speculation on my part, but this change might be to better mimic the manual delete behavior. I don't know about earlier versions, but with FMP11 and FMP12, if you have a portal row active and you do a delete record, it would ask if you wanted to delete the Master record or the Related record. It did sense that you were in a portal row.
When I say manual delete, I am referring to clicking the Delete button in the toolbar, selecting the Delete Record menu item, etc.
No reason to be embarrassed. I've had plenty of conversations that it became clear that I was doing something the hard way. Some really "basic" stuff that I couldn't believe I had never known about. I just laugh, and file it away in my toolbox.
Again, embarrased that I was doing something the hard way, so trying to delete the evidence!
It also points out that it can be helpful to just look at the list of script steps and see if you understand what to do with each and every one of them. It may be easier to do this group by group.
Message was edited by: BruceRobertson Grammatical error corrected.
Agreed. It also lends itself to the importance of reading the documentation for FM and FM Server. So many 'worst practices' can be avoided if people read the documentation. If data is valuable to your business, it's worth the time investment to read.
An experience similar to Shawn's is what made me go digging and reading more. Definitely made me a 'safer' developer. LOL
It also points out that it can be helpful to just look at the list of script steps and see if you understand what to do with each and every one of them.
Couldn't agree more. Same with the list of functions. There are are always some that we had no idea were there and some that we just plainly misunderstood.
I do this in prep for the certification exam.
Reviewing the entire list of script steps is easy to do in the script editor, with its large vertical size.
This is much more difficult in the calculation dialog. We still need a resizeable calculation dialog window with a moveable splitter.
I just use these:
Script step reference
And then try things in FM when the explanation does not make sense to me.
I would also like to see an information button on the calculation dialog box, that you could click the information button and then click on a function from the function list and it would take you directly to the function reference in the help file for that specific function. Or open a large pop up window with the reference for that specific function.
There is an information button, but that only opens the help file. You then have to drill down to the function you are looking for.
Same for Script Editor.