0 Replies Latest reply on Oct 3, 2012 11:54 PM by Vincent_L

    New or to modify Script Steps




      Here's some new script steps or scrip step modifications we're sorely missing and which would allow clener code, and offer new possibilities. Of course if some modifications would break code, just introduce a new script step.


      - Perform script by name (database, scriptname, parameters). This would be so amazing. Yes fmp://url exists on go and on FMP 12 with hosted files, but that's more complicated, and the fmp url is a different matter. Here we are in the this database. Much more easy to newbies, much more coherent, cleaner and perhaps faster.

      This one is my absolute top one. Plugins exist that kind of do this but with severe limtations. So we need a good way.


      - Perform script by id (database, id, parameters). Same as above but with script id = more robust code


      - Empty table script step : this would be the equivalent of the Truncate function, it will empty all the record of the current table instantly (if you think that cascading deletes may make it difficult, just fall back to delete all if cascading deletes exists if you can't make them faster, but most table are without cascading delete and we need to be able to empty a table as fast as we can make a clone of it). Daily, in all my scripts, deleting all table takes a cumultaive of 2 hours time


      - Save current foundset and restore saved foundset scrip steps. It coud be vey simple with no parameters like go to layout, and then go to original layout. Or it could be much more powerfull if it'd allow to record the foundset to a destination $variable or $$variable. Those variable would receive a list of record_ids in the proper order, and then the restore saved foundset would restore the foundset from the variable / calc. That will save a tons of perform finds, and hence will lead to better performance. This will save a lot a relationship with go to related fileds. Plus it's much more newbie friendly.


      - All script steps that can be ran by an object name should be also be abe to be ran with the objet internal id. To avoid a go to layout name script step fail because the name of that layout was changed, she thing for field value from filename, same thing for value-list all should be ask referenced by their internal FMP object  ID


      - Replace by field name. We need to be able to specify the target field name or / field id by a calculation


      - UPDATE like function = a replace that can cahnge multiples fields in one loop respecting record locking, and allowing multiple fields to be updated at one, to complement the replace function.



      MODIFICATIONS of existing scrip steps (Of course if some modifications would break code, just introduce a new script step)


      -  a Copy to clipboard script step that works without needing field's presence on the layout, of course with a specify calculation, so we coudl put fileds, calcs, or $variable or a $$variable in the clipboard. Yes, I know, I'm not trying to reproduce relationship via clipboard like in FMP 3. The purpose is to actually populate the clipboard of teh user who needs to get data from Filemaker in his clipaboard.


      - All in one Perform find, constrain or extend script step with settable outcome. They should be the same script step but with a behavior flag depending on parameters. Today it's terribly annoying to tranform find queries in contraint one. So we would just create the search query, and then a flag would indicate if the foundset would be constrained, extended, or if it would be a new foundset. Of course the outcome must be programatically setable with a calc field, and hence a variable, so we could chose at run tie what to do with the resulting foundset. It would decrease the need search scripts by as much as 3 times !


      - Fully settable Sort script step with settable direction : We should be able to programatically set the sort criteerias and sort order


      - With import or exports that ask the user to choose the file (no specified files), there should be a way to have the file's filepath. Maybe that's a get last exported / imported filepath custom function


      - Ability to specify the excel worksheet when importing excel files http://forums.filemaker.com/posts/24964e9632. Also we need the excel ilmport to retunr us the list of the worksheet, so we can create scripts that would loop to import all the worksheets of an excel file without requiring the user to choose again and again the worksheet.


      - Better erreor reporting when doing replaces or imports and whne skipped records update occurs. Now, when you a do replace or an import, if some records are skipped due to record locking, you have a dialog that tells you some records where skipped. But you don't know which one, so you can retry to import / replace them, leading to potential not updated data. Very bad for data integrity. We would need to get a list of recordID of those skipped records