new window

[crazybake]

Is there a way to force FileMaker to open a new window when a button a selected. For example, the user clicks on a schedule for jobs for a specific piece of equipment. Currently, I have a button where if they click on a record, it changes views and shows details about a particular job... but not though a new window.. This would probably be easy through applescript. However, almost all user are windows. I want the user to click on a button and a new (additional) window appears where edits can be made and the data would be updated so that when the additional window closed, the data in the original window would be accurate..

Makes sense?

[LiveOak]

FM is pretty much limited to one window per file (almost). The exception is dialog boxes (show message). This option can be enhanced with a plug-in such a Troi Dialogs or Dialog Magic. Another option is to use a layout from another file populated with global fields to act as a pop-up window and hide it when you are done.

-bd

[Vaughan]

I want the user to click on a button and a new (additional) window appears where edits can be made and the data would be updated so that when the additional window closed, the data in the original window would be accurate.

Easy if the other data in is a related file... You can always make a layout that *appears* to have another window on it.

It sounds to me like a tabbed interface might be a solution to your problem. Switch between tabs, not windows.

[CobaltSky]

You can do this relatively easily by using a second file with only a single record.

How it works is that your second file has only two fields: - a single text field, called 'Key' plus a calculating constant (ie with the formula set to 1) called 'cGlobal.key'. It also requires a relationship from the Key field back to the a recordID field in the main file.

The main file also requires a calculating constant field (with the formula set to 1) and a relationship which matches it to the Global.key field in the dialog file.

Your script which is attached to the button in the main file writes the current record ID to the related file via the constant relationship, then calls an external sub-script in the related file.

The sub-script in the realted file brings it to the front, sizes it appropriately and then enters a loop with a pause in it (to hold the file in position until the criteria for exiting have been met.

The layout in the dialog file should have appropriate fields from the main file placed on it, so that the user will 'write through' directly into the current record in the main file.

A 'done' button on the layout in the dialog file should simply hide the file, thus returning the user to the main file which is still waiting behind.

This method has several advantages over other discussed (eg dialog plug-ins) insofar as it allows greater control over the look of the window and the combination and placement of fields, buttons, icons and text etc on it.

The only significant drawback is that if the solution is running under Windows, the main file will not be able to remain maximized underneath the dialog file window, since Windows does not allow a mixture of window states. However if desired, this can be overcome by using the latest version of the WindowUtility plug-in, which allows you to freeze (disable) a window in maximized mode on the Windows platform, while displaying other windows over it.

[crazybake]

I must be missing an important step... I canot get the approipraite records to display..

Do you have any examples of this. I have been attempting different variations since your post, with no luck.

Thanks much

[CobaltSky]

Hi Crazybake,

The way in which the method I proposed ensures that the second window will access the correct record in the main file is via the relationship from the field called 'Key' back to a recordID field in the main file.

The second file should have only one record in it - or alternatively the 'Key' field should be a global text field - to ensure that it is not possible for you to view anything but the current record in the main file.

If you check the above things and it is still not working, I suggest that you look at the data types for the 'Key' field and the 'recordID' field in the main file and make sure that they are the same (both text or both number).

[crazybake]

Thanks... checking the little things helps!!

Data type for the constant field was not the same

c

[Vaughan]

Woooo, back up a bit....

Ray wrote

"Windows does not allow a mixture of window states. However if desired, this can be overcome by using the latest version of the WindowUtility plug-in, which allows you to freeze (disable) a window in maximized mode on the Windows platform, while displaying other windows over it."

WindowUtility plugin.... do you have any details? This spunds like the kinda thing I'm looking for!

Thanks Ray (as always!)

[CobaltSky]

Hi Vaughan,

The comment you've picked up on is a reference to to version 2.x of the Atomic WindowUtility plug-in, which is developed/distributed by PracticeMaker:

http://www.practicemaker.com/WindowUtility20.htm

It's X-plat Win, MacOS9 and OS-X. I use it extensively and can recommend it. Here's a quick run-down:

One of the key aspects of the way it works is that it allows you to control other FileMaker (or runtime) windows from within the current file. It changes the whole paradigm for controlling windows - for example, you no longer have to call an external subscript within each file to hide it, move it, change its size etc. Thus you don't have to bring a window to the front and then zoom it and have users see the resulting window flashing - instead, you can specify its size and position on the screen (in fixed or calculated pixel coordinates) while it is still hidden, then have it display there when you're ready.

I guess that it's not for the faint-hearted - version 2 has 60 functions, a good few of which are platform-specific (be prepared to use the Status(CurrentPlatform) function extensively in an x-plat solution!). However on Windows, it really shines - allowing you to resize, position, maximise, restore, minimize or hide the Application window as well as each database window independently. It also allows you to hide windows in such a way that they don't show up as rows of 'bricks', nor appear on the windows menu on Windows. ...and it does the neat trick referred to above, producing apparent mixed window states - and thus making it possible to have a solution operate on Windows in a fashion which is somewhat closer to the way it runs on a Mac.

On both Windows and Mac, it can also be used to create the illusion of a single file interface where each file window called appears in exactly the same position as the one it replaced (regardless of where the user moved it or how they re-sized it) - making it seem as though the user has changed layouts rather than files. And it can be used to dynamically replace the filename and icon(s) in the header bar with a window title (and/or icon) of your own choosing, so the user no longer sees a parade of filenames with .fp5 suffixes, but can instead be presented with layout names or descriptive headings etc.

To get really clean and crisp results you have to be prepared to invest a bit of effort into the scripting because the sequence of function calls (and also the decisions about which file/s they reside in) have an impact on the outcome - and if your placement of the function calls is non-ideal, the transitions won't be as smooth. In this respect, WindowUtility can be a bit more demanding to use than some other plug-ins.

Anyway, check it out if you're interested. It's the usual shareware deal with free demo downloads from the vendor's site. But be prepared to invest a bit of time if you really want to get the feel of it...

[Vaughan]

Thanks Ray.

As always your response exceeds even the most demanding expectations!

[BFH]

Quote:

" . . . or alternatively the 'Key' field should be a global text field - to ensure that it is not possible for you to view anything but the current record in the main file."

Newbie ignorance here: what about simply disabling the status area? Wouldn't that prevent the user from viewing anything but the current (single) record?

Granted, Record>New Record is still available, but . . .

[CobaltSky]

Hi BFH,

Disabling the status area would not ensure that the file only had one record (nor, as you say, would it stop a new record being created inadvertently or otherwise while the file was being displayed). If for some reason there were already multiple records in the file, it also wouldn't ensure that the record that is displayed when the file is brought to the front is the correct one.

Don't get me wrong, I definitely think the status area whould be locked - in fact I would *always* hide and lock it for an implementation of this type. But doing so does not provide a solution to the 'which record' issue which was the subject under discussion in the post you refer to, whereas using a global field does.