2 of 2 people found this helpful
Put it in as a Product Idea (or two). I'd upvote both.
3 of 3 people found this helpful
That type of information at the finger tips would be useful.
In the mean time, I have been playing with adding to scripts a commented out "Go to Layout" script step to embed into the script a reference to the layout where the script is called from.
For buttons and script triggers I use a suffix of, for example, "_BTN_ST_oe_ox" to indicate that the script is called by, a button, a script trigger, and specifically, both by OnObjectEnter and OnObjectExit script triggers.
Not perfect. Perhaps useful for where we are.
1 of 1 people found this helpful
I'm always reluctant to throw ideas into FileMaker unless I've heard from other FileMaker developers because sometimes I find out my ideas have problems I hadn't thought of or up come even better ideas on how to solve the problem. Usually I do that at FMPUG meetings (we have a really active group in Dallas), but it is good to have feed back from two well known developer here, you and Tony White. Since neither of you pointed out a weakness in the suggestion, I think I'll pass it on as a Product Idea. Thanks for the feedback!
In the interim you might use the Folder structure to categorise scripts by layout as that is retained following a search for scripts by name. It won't be nearly as good as your suggestion, but is available now!
For Script Triggers, I've followed a convention that Chad Novotny recommended in 2009. Start the script name with OLE: for OnLayoutEnter, OOE: for OnObjectEnter or OnObjectExit etc. Again, not as good as what you are proposing but also available now, useful for searching and similar to Tony's usage.
It's probably a pipe-dream ... but the way Visual Studio highlights misspellings of variables, etc., is awesome.
I don't agree that this is something that should appear in the script workspace. I understand the desire to be able to determine what object dependencies are associated with the script. I want to know where and how a script is being used too.
My main concern with your idea is that it will only answer that question for the current file. It will not work well for split data/UI systems or more complex, multi-file solutions. Scripts can be targeted from other sources. These sources can be other FMP databases or they can be CWP/XML web apps. These external references (would probably) not be accessible to the file and the list of calling objects it displays will only be partial. You will still have to make references to these other sources. In a multi-file solution that may mean going from file to file to check. At that point, the only reference to an external script is going to be a "perform script" script step. So, suddenly we don't just need "is this script being used" we need a corollary "which external scripts are being used". Then, should you miss/forget the one file that actually references the script in question, your effort has been in vain ;-)
I recently posted a DDR tool that tries to deal with the more general job of exploring the DDR. https://community.filemaker.com/thread/165077. One of the jobs it does well is to determine where objects, such as scripts, are being used. It works across the entire list of files within the DDR summary, so it's suitable for multi-file solutions.
If you use Mac and MBS Plugin, you can enable the variable name check.
You call SyntaxColoring.CheckVariableDeclaration.Enable and let the plugin highlight all undeclared variables it sees in the script.
I get your point, Malcolm. You are trying to do is analyze the whole database, all scripts, and or related solutions, etc. That is better handled in a DDR tool like your XML DDR Query Tool, Base Elements, Inspector Pro, or the newest commercial one, FMPerception. And when I want to analyze the whole database, those are all great tools. But when I'm just looking at one particular script to figure out if it is used anywhere in that solution or not, a tool like this in the Script Workspace is the most logical place because it is information about that particular script. There are times when other tools handle the bigger picture you are talking about, but that is not what I was trying to solve.
The reality is I often am opening a legacy database developed by other people and digging around in the scripts and this would help me out a lot quickly when I'm looking at a particular script. Say there is a script I think is no longer used. Do you really want to run a DDR and analyze the whole database to make that one decision? Usually I am just looking for a quick piece of information to know if I really can get rid of the script if it doesn't belong to any layouts or is not a subscript anywhere. For those circumstances, I want to be able to make a quick decision without analyzing the whole database. It is about being able to make quick decisions with minimal effort so I can work faster and more efficiently.
By the way, thanks for the community distribution of the XML DDR Query Tool which you have freely distributed. Have you taken a look at FMPerception? I was really impressed with it at Devcon, but haven't tried it personally. It just reads the XML DDR and is lightning fast because it doesn't go massage the data via an import like some other DDR tools. Granted it doesn't do versioning so well because of that, but it certainly makes it fast. Then again, these other tools cost hundreds of dollars and you are providing yours for no cost. If anyone out there has been holding off on a DDR tool due to finances, yours is a great option to help a developer analyze the whole solution. Thanks.
I've looked at FMPerception and I was impressed by it. It seems to have the sort of speeds that my own tool has, which is a big plus for it. My opinion is that the tool should speed my work, not slow it down. In that respect, not having to leave the script workspace would be a benefit.
I'm often working in the same situation that you described, looking at a legacy database and wondering what I can touch. I certainly don't want to stop work for any length of time to answer that question. One of the motivators for writing my tool was to get those answers quickly. I find that it is fairly easy to dump the DDR. Even a large DDR across the WAN only takes a minute to product, and it is always useful as a record in the long term.
Having a fast DDR query tool, like FMPerception or my XML DDR Query tool, really does enhance the way in which you interact with the system. Importantly, it improves my accuracy, which I think is what you are aiming at with your feature request.
For versioning, I use command-line tools. The result isn't nearly as pretty as BaseElements or InspectorPro, but I have my diff in seconds. Every so often I think that it would be nice to have a bit of UI to support this job. Perhaps I should put it into a web tool too.
You need to apply for a presentation next year at Devcon on your XML DDR Query tool. I certainly would attend.
Just because a script is not called from any place in a file doesn't mean it useless. I have some scripts that are only run when unusual changes have been done i.e. need to change something because of PO changes. and the user should have no access to them. and may need a line or two customized each time it run.
But orphan scripts do make for problems trying to understand what's going on, when maybe they were used only for testing some logic truly no longer needed.
You are correct, Greatgrey, about there being other reasons a script exists. The script could also be in schedule scripts too. And this tool, like any, can be used incorrectly to make bad decisions about a solution and it should not be solely relied upon. And is Malcolm pointed out, there are time to take a big picture look at the solution via DDR analysis. But something like this would just be additional piece of easy information to assist in looking for orphans or, if combining scripts, looking for where they are are called.