It is possible if you use unique Window names and unstored calculation fields with dependencies to the window name/ window title based on globals. It is quite some work but rock-solid.
Via the window title and your user login in unstored calculations you can retreive all the filters etc from a related session table.
1 of 1 people found this helpful
Multiple windows can be a source of unnecessary complication. Are you sure this is the best way to run things?
1 of 1 people found this helpful
I went down this path one time, and while everything worked as desired, in retrospect, I would not go down that path again.
The problem, as I see it, was that the level of complexity that I created with my solution was beyond acceptable, and beyond what could be reasonably left behind for another developer to comprehend.
I will not go so far as to say that this should not be done, or that you should not go down this path -- I am just giving you my two cents.
As Uli has mentioned, having unique window names is the key, and much is possible. In my case, I experimented with what would happen if I named a window with a return-delimited array of data. If I recall correctly, only the top line showed in the title bar, and the last line showed in the windows menu. (This was on OSX. Windows behaved close enough to this, but not exactly.) Everything in between the outer array entries was concealed, and thus inbetween I was able to store meta data about the window state, as well as a unique string per each window to guarantee the uniqueness of the content, and hence the uniqueness of the window name. Custom functions and a script allowed me to store and operate with the more-or-less the functional equivalent to window IDs. These IDs allowed me to get/set meta data, as well as obtain the full window name so that I could perform window script steps against a target window. Getting a handle to any window was possible since the WindowNames function essentially returned all meta data for all of the user's open windows. Since the format of the meta data followed a well-defined structure, it was possible to know what meta data was linked with which window/window ID.
I would not do it again. Perhaps with some of the insights that you or Uli have, I might have created less of a monster, but such was not the case.
Good luck and very best regards,
Thank you keywords for asking this question. Right now I am not sure if it is the best way. I simply assume that users will want to be able to have multiple windows. However, I don't know for a fact that they will want it. So right now, probably it's not worth the effort to dig too deep into this. On the other hand, at some point there will be a web-accessible version, in which case I expect that users will want to be able to open multiple windows simply because it is expected of all things accessible through web browsers.
Hi Uli and Steve,
Thank you for your input.
Uli, I think that I am doing what you are describing. I found out this afternoon that I mis-remembered the problem. The Get ( WindowName ) calculation works as it should, but the relation delivers the wrong record in certain situations. Probably because of chached relationship data. After a window-refresh that flushes this data, things go back to what I was hoping for. This however turns into a new problem, which is that in a client-server constellation such flushing is what one should try to limit.
Steve, thanks for the warning not to go down this path and for very sharing your solution. It's very nice out-of-the-box-thinking.
I too have recently tried to develop a multi window application and gave up after realizing that the level of complications introduced made it not worth the effort. I started off using a separate session table to manage the windows, and while it worked fairly well, things started getting unwieldly very quickly.
Part of the problem was that there is no effective way to have a window have its own data set that can be used to address and distinguish the window elements and other required session functions, other than the window name, so it is hard to abstract your code to handle certain functions for multiple windows based on the same TO.
Opening multiple windows to the same TO can complicate matters even more when you are using global fields to do certain things that should be unique to each window. The globals' values are common to the application client session, and not unique to a window, so changing it in one window affects all other windows with values/fields based on the same table.
Things like GTRR become difficult since you cannot tell it which window to go to if you want to use an existing window.
As a PS: some experiences with WebDirect
Although I abandoned the concept, last week I had to return to it and found out that in FileMaker WebDirect (I was not thinking of that in December 2014 when I asked the initial question but ended up going there later) multiple windows do not really work. Opening a new window with a script will create a 'virtual window' on top of the initial one within the same browser window (i.e. the user still sees only one window). Forcing a new browser window by asking the user to open another one and log in again results in the initial browser window to become blank-ish: only text remains. Color nor other layout elements are visible and there is no interaction possible (on a Mac with Safari on a FMP 13 server. I didn't try other constellations).
However, opening another browser (say Chrome instead of IE or Safari ) does work: i.e. both windows work as they should. I'm guessing because the web-engine sees them as different machines. They at least get different device IDs.
The reason that I explored this was that a user wanted to see an image file on one display and the data fields on another display. (One could have one window spread out over two displays but I don't find that elegant at all and is sub-optimal when the displays are of different pixel size.) Communications between the two windows works via the windows table that I still maintained in the database. Basically, the first window broadcasts the data about the images that need to be shown to all records in the windows table with the same account name. There is a little bit more to it (about how the first window knows that another window is actually taking the role of image-display window) but I'll have to spare you the details for now.