>>>I remember we discussed that several years ago; since then we implemented this 'dual synched browser forms' support at a client request: https://youtu.be/o-X_pyCG7j0
>>>It's now a standard FoxInCloud feature.
>
> Nice! Please bear with my barrage of questions:
> Is this via the server or directly between browser instances using Javascript?

open window: FoxInCloud server > FoxInCloud.js > this.win = window.open(…) // same origin
update window: FoxInCloud server > FoxInCloud.js > this.win.document.getElementById('id')… // possible because same origin
close window: FoxInCloud server > FoxInCloud.js > this.win.close()… (possible because same origin)

> Using Sendmessage (to allow cross-origin) or relying on same origin scripts?

same origin script (see above)

> Still works if users are allowed tp open and close windows at will?

sure

> If I were to have (say) 6 or 7 open panels, could their size and location be persisted (so they come back in the same location next time)?

yes, in user's session by default (can be permanent eg. 'remember me'), method can be overridden to store in user's record

> If I were to have (say) 6 or 7 open panels, can they all update at good speed?

depends on:
* user's machine HP; as https://developer.mozilla.org/en-US/docs/Web/API/Window/open states: "Opening new windows, even with reduced features, uses considerably a lot of the user's system resources (cpu, RAM) and involves considerably a lot of coding in the source code (security management, memory management, various code branchings sometimes quite complex, window frame/chrome/toolbars building, window positioning and sizing, etc.). Opening new tabs is less demanding on the user's system resources (and faster to achieve) than opening new windows."

* total number of HTML objects to be updated upon each request; you might be using multiple windows for several reasons:
(1) display lookup references together with details; eg. order + customer + city + …
(2) display large elements such as maps or images

(1) depends on user action: modifying details is faster than moving to another invoice where all lookups also need an update
(2) depends on bandwidth

also depends on the number of elements part of the user's state. As FoxInCloud server has to be agnostic about the application, it uses brutal force: saves and restores all what can possibly change (the only optimization is: don't restore if the same server serves another request of the same user in a row). For high load scenarios, we could add properties or shell methods that allow developer to specify elements that can be skipped (depending on event or whatever other parameter).

> Performance on Windows using a VFP Compiled C++ app is blazingly quick- on an Atom processor, the app loads in about .5 second and updates itself in .2 second, which delights users.

Several factors here:
* a desktop application deals with one single user at a time; can load everything in memory dedicated for this user. A Web application server can deal with any user: must take care of user's state.
* your desktop application probably has 15 years of optimization history; Web applications not yet
* Natively addressing the GUI layer will always be faster than through JavaScript and HTML DOM
* Transmission through the Internet layers takes about .2 sec (request + response, based on FoxInCloud Dashboard)