Note: I tried posting this as an "idea", but it seems I'm doing it wrong. If I'm doing it wrong now, and just created a duplicate thread, I apologize and request assistance.
I've been doing some creative things with snapshot links, and though I'd share, to see what refinements or other creative ideas you FM geniuses might have. Plus, I thought it might be fun on this forum to discuss something fun and new, rather than just problems to be solved. :-)
In the future, I might blog about this, but it's a topic for a pretty narrow audience anyway. For now, I'd like to share my raw findings and see if anyone here would like to "riff" on them.
The original thing that caught my attention was that snapshot links include sort information. As is periodically noted, we don't currently have a way in FM scripts to change a sort without creating a Sort script step for any combination/permutation of sort criteria we want. So I started wondering whether I can create a snapshot link, alter the sort order, then open that snapshot link with the new sort order. That works (I'll outline some techniques and gotchas in a minute) but there are other things in the .fmpsl file, as well. Go ahead and save a snapshot link (you may first want to find a few records and sort them, just to give your snapshot some decent content) then open that up with a text editor, and you can follow along.
Path to the file - this is the fmnet address, and if the file is local it's both the fmnet address of your machine and the path to the file on disk
The count of the rows - the found count
The base table id - this is, frankly, a bit mysterious to me, although that's not an issue for me currently. It doesn't seem to correspond to the number you get using the TableIDs function.
"CDATA" - this is a ranged list of record id's. ( " get ( recordID ) " ) (For various reasons, I'd like to be able to create a fmpsl from scratch, and this is the item that seems to make it easiest to just have FM create one and then modify it. I can write a custom function that'll create this cdata, but it won't perform as fast as (or at least, not any faster than) just creating an fmpsl and reading it.)
LayoutID - you can get this with the layoutIDs function. (Of course, you'll also use the layoutNames function to find which id in the list goes with which layout.)
View Type - list, form, table
The id of the selected row - get ( recordID )
Status of the toolbar - pretty obvious
Mode - browse, find, preview... haven't tested if this works for layout, for fa users
Sort parameters - finally, the sort parameters. I won't break these down further here, since you can save a few fmpsl files and get the gist pretty quickly. I will point out that, for the field table ID and the field ID, you might consider using executeSQL as described here: http://www.databuzz.com.au/using-executesql-to-query-the-virtual-schemasystem-tables/ . I only found out about this recently (don't know how I missed it) but it rocks!
(Although this worked out not to be useful for my purposes, I should also note that anything below and outside the <FPSL> tag will be ignored by FM when the file is opened. If you end up wanting to keep a bunch of these, for example, in a temp folder, you could use that to stash some extra details, like fronted panels and such.)
OK, so first off, how could we create, read and update these files? At first, I went with 360Works ScriptMaster (the swiss army knife), but thanks to some help from Brian Sanchez at aAce, I now have a way to work with the text file without a plugin.
To create it, I use the Save Records as Snapshot Link script step, and save the the temporaryPath
To read it, put the .fmpsl into a container field (it can be a global), and then calculate Base64Decode ( Base64Encode ( ContainerField ) )
To update it, I parse and alter the text (I'm not going to go through the details of that unless asked, since we all have our own parsing methods)
Now I've got an updated snapshot link as text, and I need to open it. This turned out to be trickier than expected. If you try using export field contents, you get the wrong format. The formats you get from exporting a single record and single field get you closer, but they mess with the line feeds. Either of these cause FM to throw error saying that FM didn't create the file (busted!).
However, if you use a virtual list, and export a record for each "paragraph" (other than those generated by the return-separated cdata, there aren't a lot, although cdata could require plenty), and then export with the utf-8 format, you'll get a usable .fmpsl, which you can then open.
So, now we can create a snapshot link, bring the text from that link into FM and manipulate it, then create a new, updated snapshot link that we can open. What now?
Well, first, an important caveats:
First, a snapshot link always opens in a new window. If anyone finds a way around this, please let me know post haste!
Also, if you run a script to create and open the updated snapshot link, the snapshot link will open after your script(s) are completely finished. This means that, for example, if you want the newly opened window to replace the user's existing window, you'll need that part to run as a new script after the snapshot opens. One way is simply to put some parameters in a global field that are fetched by a script trigger when the new window opens.
So, finally, what can we do with this?
I'm sure others can add to this list, but here are some areas where I'm using it and/or experimenting:
Dynamic sorting - this was, as mentioned, my initial reasoning for going down this path. The thing about opening after scripts are finished is a bit of a headache, but I think (given that we use parameter-driven, layout-independent scripts for just about everything) that I can work around this by caching my script parameters in a global, ending the script, letting the snapshot open and then having the script trigger find the rest of the parameters and continue.
Back and Forward Navigation - I have this working, since I don't want users moving back and forward while another script is running, anyway. Whenever I have a found set I want to cache in the back (or forward) history, I create a .fmpsl to get that pesky cdata and stuff, then capture the text. If the user does anything that would alter the file, like switching to a list layout of the same table, or omitting a record, deleting a record, creating a new record, etc., I update the stored text. If they hit back, I can export that new .fmpsl and open it. I originally had this working with ScriptMaster, but the reading and writing to the file were prohibitively slowing things down. It's pretty smooth, now.
Passing found sets between TO's and Files - I'm still ramping this one up, but in theory, I could pass a found set, sort order, etc. from one interface file to another interface file. My reasons for wanting this are probably a bit arcane, but in brief, my big hairy goal right now is to separate customizations from standard modules, so if I can have, for instance, Contacts in our base interface file and Contacts in a custom interface file, and move smoothly between them, that'll be a big step.
Anyone else have any ideas about this? Things I've overlooked? (I'm sure there's plenty!) Other possible uses?