snapshot links are subject to the OnFirstWindowOpen triggers of the file, and taking apart a snapshot's format, there is nothing saving the window size to be processed after the layout loads.
Here's a simple look at a .fmpsl structure
<Rows type="" rowCount="" baseTableId=""><![CDATA]></Rows>
<SelectedRow type="" id=""></SelectedRow>
<SortList Maintain="True" value="False"></SortList>
So given that, you would have to set the get(windowcontentheight), get(windowcontentwidth) and get(windowzoomlevel) in a record corresponding to your state each time those parameters are updated per-user, then reload those as part of the open script.
Of course that's theory, there may be a better way to save and reload those settings.
Easy ugly solution using filename.
This use Char(65518) as delimiter that never be used in window name and allowed in filename.
Is there better char ?
Set Variable [$path; Value:Get ( DesktopPath ) & Substitute ( List ( Get ( WindowName ) ; Get ( WindowHeight ) ; Get ( WindowWidth ) ; Get ( WindowTop ) ; Get ( WindowLeft ) ) ; ¶ ; Char(65518) ) & ".fmpsl"]
Save Records as Snapshot Link [“$path”; Records being browsed]
Set Variable [$params; Value:Substitute ( Get ( WindowName ) ; Char(65518) ; ¶ )]
If [ValueCount ( $params ) = 5]
Set Window Title [Current Window; New Title: GetValue( $params ; 1 )]
Move/Resize Window [Current Window; Height: GetValue ( $params ; 2 ); Width: GetValue ( $params ; 3 ); Top: GetValue ( $params ; 4 ); Left: GetValue ( $params ; 5 )]
This script doesn't restore maximization.
You know, I was thinking about something like this as a workaround.
But my question is: is this a bug in Fm or am I missing something here.
agnes b. riley
filemaker and web development
TWO-TIME MAD DOG AWARD WINNER
FileMaker Certified in 10 and 11 • Member, FileMaker Business Alliance
T: 877 917-9079 . C: 917-660-7221
Store | Blog | Facebook | Twitter | LinkedIn
You are brilliant. This gets my vote for clever idea/workaround for the day.
A couple of comments/questions:
1) How did you decide upon 65518? Did you just pick some aribitrary char that seemed unlikely that it would be used?
2) The one thing I might suggest, would be to include a simple escaping/unescaping routine to handle the case where there are illegal file path chars in the window title.
On OSX, the two chars that come to mind are: / and :
I don't know what the Windows equivalent(s) would be.
In any event, patching these up would allow for window titles such as: "Sales: Current" or "Shipping/Receiving"
Most of all, I really like how you were thinking on this one. I can see why you might call it ugly, but it does seem to get the job done.
I would not think that it was a bug as I never recall it being an advertised feature of the snapshot link.
1) Yes, I saw unicode table and pick it from about most bottom. The chars in the area (HALF WIDTH) may be used only in Japanese.
2) That should be done. Windows has more chars like \ + * ? " < > |
Including separator char to escape list, any char can be used.
So, I just had to face the same issue again. I just added the aforementioned character to my script name and trapped for it in the window renaming script my client has. Mission accomplished.