More than one active layout?

[PatriciaW]

A customer bought FM7 on the understanding that it would enable them to go from an active layout (creating a new record) and open another layout to browse some data ... without having to complete the data entry.

I haven't seen anything which describes this ... does anyone know IFF this is possible ... and if so how?

[Zero Tolerence]

Well, they can just go to Window -> New and go to the layout they want.

In FM7 Data entry is saved when you exit the field (or at least you can turn on an option so it is, i don't remeber.) So openin a new window should not depend on weather or not they've finished data entry. Alternatly in a script you can do it like this.

CommintRecord

New Window "Window 2"

Go To Layout [New Layout]

On your new window step you can specify how big you want it and where you want it to pop up.

[Ender]

FYI, navigation between multiple windows can be tricky to script. If your navigation is mostly controlled by scripts, then you'll want to familiarize yourself with FM7's window control script steps.

There's also a risk of locking a record in one window and not realizing it until you try to edit the record in another window. You can commit the record on the initial new window creation as Zero shows in his snippet, but the user could work between the two windows and eventually end up with a record locking problem.

[PatriciaW]

I don't think this would work ... doesn't commiting records automatically invoke validation? That would force them to complete data entry which is what they don't want.

Also, the New Window option only brings up a copy of the window they are working on ... which is not what they want. They want to open a new layout. When it creates a new window, the window contains the same data as the layout they are on and if they attempt to go to a different layout the record gets validated.

[Zero Tolerence]

Well, you can skip data validation in the commit records script step. And yes, new window brings up just a copy, but from there assuming they have access to the status bar they can go where ever you give them access too.

Other wise, you can specify where they can go in a script.

[PatriciaW]

But I don't want to skip validation ... once I do that I can potentially corrupt the data in the database ... unless there is something I am missing. :o

[PatriciaW]

Has any of this behaviour changed in FM7? I never worked in FM6 so I don't know what the limitations were in it.

[Ender]

But I don't want to skip validation ... once I do that I can potentially corrupt the data in the database ...

I rarely use validations as they are usually enforced for all users from whichever entry screen they happen to be on (even if the field is not on the current layout,) and I'd rather have a little more flexibility. Instead I usually use sub-scripts or completion flags (calcs) that can check that data entry is complete in a particular section. I can then have my process or navigation scripts proceed or give a message if something is not complete.

Has any of this behaviour changed in FM7? I never worked in FM6 so I don't know what the limitations were in it.

Much has changed with commiting records and window management. I don't think it will help you much to go into how things worked in previous versions unless you are planning to develop in both. If you want to know more about how to deal with these in FM7, check out the FM7 Foundations and Migration Methodologies tech brief on filemaker.com.

[PatriciaW]

The reason I asked if this had changed in FM7 was because the customer only purchased FM7 (they had FM6 already) because they were told that it would support this ... I presume they thought that it would allow concurrent threads ... or something like that.

I was asked to convert their application from FM6 to FM7 and I have done a lot of restructuring and have put a lot of validations into scripts but now they dropped this bombshell! I'm just trying to find out if they were misled or what.

[comment]

I am still trying to figure out where is the difficulty. I have no problems leaving the cursor in a validated field of a new record, opening a new window, and going to another layout and another record in the new window.

[PatriciaW]

I was going to say that soon as I attempt to go to a new layout it invokes validation, but when I did a test now it did not do so, although for a while the Window menu was greyed out and so I couldn't even create one. It may depend upon where in the validation process (or script) it is ...obviously it does look like it works ... now I guess it is up to me to figure out how to do it consistently.

Many thanks for clarifying this. :o

[comment]

The record is being edited in the original window. Therefore, it cannot be accessed at all in the new window (try clicking in a field right after you open the new window).

[PatriciaW]

It may have been overkill but I rearchitected the application to use several windows, two for each conceptual object in the database (client for example), one for browse mode, the other for find mode. This way the user can go backward and forward between editing these objects and doing finds on the same or different objects. There can only be one instance of each of these windows.

I'm in the process of testing this to ensure that it works consistently. Thanks again for all the help.

[comment]

Another option is to always open a new window when creating a new record. This has additional advantages, especially if data entry is into global fields.