Paul Jansen

Josh, Thanks, that is an interesting perspective. I must admit that 20 windows was a worst case scenario and unlikely to happen in general usage; I guess I was trying to emphasise the point . Reflecting on the workflow, most users would need to have 4 windows available but currently only one visible and active. Your point about cache updating is very interesting - I shall definitely be looking into this further in this particular solution (which dates back to year 2000 and fp5 file format)

To address the loss of the bottom toolbar during development, I have created a small toolbar which I am putting on every layout with a hide condition if [ not "Full Access" ]  As a result of reading this thread, I think I will be adding additional buttons/segments to include "Show/Hide menu bar[toggle]" and to access layout Mode

Josh, I would guess that Adduartes issue is similar to my own. Until version 16 I have always run my database windows maximised under Microsoft Windows to avoid the mess that is two sets of window borders and,even worse, the database window half disappearing behind the application window. So the PC users are used to seeing only a single window at a time. Clearly 16 offers a whole new world of options for window management on PCs, but, initially, I would want to reproduce the former behaviour in 16 before assessing how to take best advantage of the new possibilities. One of my clients might end up with close to 20 full screen windows by the end of a day in 16 compared to a single visible window in 15. Hence my script for hiding all but the active window (I will also need to ensure that windows are lo longer maximised but adjusted to fit instead.) When I moved for PC to Mac a few years ago it took some time to get used to having so many more windows to deal with and at first it seemed very 'messy' to have so many windows and more difficult to locate the window I was looking for. My aim is to ensure the migration to FileMaker 16 is a easy as possible for users and then add any additional windows in a considered and controlled manner. Hopefully you can now understand the issues that SDI raises for some of us on PCs

Whilst I really like the new behaviour on PCs, I too have clients for whom having multiple windows visible will be at best a confusing change and at worst - well who knows (it depends how well I programmed things in the past!) I guess you could mimic the old behaviour by hiding all windows except the one you want to be active. Perhaps a script something like this would help Script: Hide Other Windows Set Variable [ $activeWindow; Value:Get(WindowName) ] Set Variable [ $allWindows; Value:WindowNames ] Set Variable [ $iMax; Value:ValueCount ( $allWindows ) ] Set Variable [ $i; Value:1 ] #loop over all windows and close all but active window. Loop Set Variable [ $window; Value:GetValue( $allWindows ; $i ) ] If [ $window ≠ $activeWindow ] #Remember to uncheck "Current file only" for multi file solutions Select Window [ Name: $window ] Adjust Window [ Hide ] End If Exit Loop If [ Let( $i = $i + 1 ; $i > $iMax ) ] End Loop

Is it still the case that there is no way to get OLE objects out of containers? I have a DB with 2000 pdf scans that were dragged in to containers in FM11 from windows explorer and need to get them converted to files so I can use external storage in 14. Any Ideas? Thanks PJ

I have worked extensively with EasySync and you are correct in your assessment. My testing indicated that the time to process each record (after the payload has been saved locally on the iOS device) increases with payload size - so say you have a payload with 1000 text only records from one table and one record from another table with a container field. The addition of the one record with container data will have a significant impact on the processing each of the 1000 text records. I took several approaches to this problem 1. I added the ability for EasySync to work with subsets of the ES TOs so I can specify a sync to only work with TOs prefixed ESA_ or ESB_ etc This means I can pull one or more tables independently which reduces the payload size and the number of records each payload contains. I separate TOs with containers from text only TOs 2. I added the ability to to add custom queries to the Pull phase of a sync which allows me to pull only those records needed on the device in question at that time. 3. I used EasyDeploy to 'upgrade' the solution whenever I needed to 'reload' a large amount of reference data. This is Much Much faster than a sync. EasySync is a general purpose sync framework, and there is of course an overhead for the flexibility of referencing everything by name, in addition to that of parsing the significant amount of text in a large payload. I discussed with Tim adding my enhancements to the official version, but there has never been another release... I have some further ideas for EasySync and thought about forking the code, but don't have the right now... In your specific case, if you can't preload and upgrade the file, perhaps EasySync is not the best technique. In my scenario (with different requirements to yours) I ended up using EasySync for some of the sync and an alternative technique for the rest. I hope this is of some use to you... Paul Jansen