In windows, no, but the effects can be minimized. I use the following script steps immediately after the New Window (or Go To Related record with new window selected):
Move/Resize Window [Name: Get(filename); Current File; Height: Get (screenHeight); Width: Get(ScreenWidth); Top: 0; Left: 0]
Then I script closing the child window to include a step to maximize the main window.
You still get a "twitch" in your windows, but this step keeps it to a minimum and prevents your windows from popping to some weird and unexpected size.
That depends if you want to prevent users or scripts from resizing a window.
If it is users, then no. If a user can get at a window, they can resize a window. The only time they would not be able to is if the window were so small that a user could not click in a window control that allows the resizing of a window.
If it is scripts, you have full control of your scripts and, therefore, you have full control over windows. If a window with a specific layout has a script trigger that resizes the window, add code to your scripts that indicates whether a specific window can be resized or not before the resize operation.
If you want to stop a user from resizing a background window while a script is running, make sure "Allow user abort [off]" is in your code early in the script. When the script is paused, users will not be able to select any background windows. If users can not select a window, they can not resize it either.
David Lalonde wrote:
If it is scripts, you have full control of your scripts and, therefore, you have full control over windows.
Have you found a way to prohibit a maximized window from resizing when a new window is called for on a PC?
If so, please share...many of us have been waiting for such a technique.
As surprising as it sounds, all but one of my clients are Mac users. It surprises the heck out of me! As such, I do little testing on Windows.
I am equipped to perform testing on Windows. I will dust off the test environments and try things out. You sould not expect an answer until at least Monday.
Thanks for trying. I think you'll find that, on a PC, any new window will resize the existing maximized window rather than sitting the new window on top of it.
If you find a way to prohibit this behavior, you'll hear cheers go up from many, many users. The re-resize technique that Phil describes above is applied specifically because we haven't found a way to prohibit the unwanted resize in the first place.
Good luck to you! I truly hope you are successful.
I use a plugin to lock the windows resizing. However still there i no way to keep the window in fully Maximized. You can have it be sized to fit perfectly within the application window size though.
I am using FMP 10 on a Mac and would like to know how to prevent the window from resizing. Very frustrating. Please help. Many thanks in advance...
As far as I know from the posts here in this thread and elsewhere in this forum, New Window does not trigger a resize of the parent window when Filemaker is installed on a Mac Platform.
Perhaps you can elaborate on what you are doing?
You might also want to read this link:
Thanks Phil for the link and I apologize for not elaborating in greater detail. I'm using FMP 10.5.8 and Mac OSX 10.0v3. I have used Filemaker on and off and for 2 different companies over the past 10 yrs and am not familiar with database design. I work for a small business (2 employees) and have had a FMP "expert" working on a new db for over a year now. I am familiar with basic editing of the layout, but I am not proficient in FMP db design.
For example, if I am in a contact's screen and I have resized my window so that it is small enough for me to view others (trimmed unnecessary space) - if I click on Main Menu or move to any other contact, the entire window is automatically maximized.
This is something that has never happened in the FMP databases I have used. I've been using FMP 10 for several months now and this has only begun to happen since our FMP person released a new database. There are many problems with the new db that will need to be tweaked, but this is by far the most annoying.
Sounds like the layout has an OnRecordLoad script trigger. Go into layout mode for the offending layout. Click the edit layout button (looks like a pencil and sits to the layout name's right). Click the script trigger tab. If there is an OnRecordLoad script assigned to the trigger, note its name. Get out of layout mode. Now go to Manage Scripts. Find the noted script. You should see the code that resizes the window.
If there is no OnRecordLoad script assigned to your layout, then I am at a loss to help.
If there is an assigned script, you may want to talk to your developer to see if the script is used anywhere else in the solution. Changing the script can impact those other places where it is used.
Just to clarify the issue:
I am using FileMaker Pro 10 Advanced, running under Windows XP Professional (but the issue remains the same in Vista or Windows 7).
This is a very simple database with 300 records, 10 fields and only 2 layouts, that is not being shared over a network (yet) or published to the web via either Instant Web Publishing (IWP) or Custom Web Publishing (CWP).
The database starts with layout #1 in table format maximized in a window. An icon is present in the header that will allow the user to edit a specific record in layout #2, that opens in a child window.
When the user clicks on "Edit Record", layout #2 opens in its own window, and the windows with layout #1 automatically resizes instead of staying maximized, and that's what I'm trying to prevent.
There is any script triggers associated with the layouts.
Thanks a lot for the advices, now I know I'm not alone with this problem.
Searching the web I've found many descriptions of the problem but few solutions (I have not yet tried any of those you guys so generously offered).
Something that sounds as a very specific answer is offered in http://www.fmcode.com/codeDetail.php?id=3606, but it turns out it requires a subscription, and I'm not willing to pay a hundred and somethign bucks for just 1 answer.....
Thanks a lot again for all the comments!!!!!!!!!!!!
I also use a plugin to help with this, altough simply resizing the window as suggested by PhilModJunk is still required
Using the WindowUtility plugin from medeyedbs[dot]com
I first resize the window using the technique PhilModJunk described, however the calculation goes more along the lines of this in my case
Move/Resize Window [Current Window; Height: Get(WindowHeight) + 39 ; Width: Get(WindowWidth) + 20 ; Top -32 ; Left -10 )
I then create a new child window.
Using the plugin, I then disable the parent window and again using the plugin maximise the parent window
Beleive it or not, it does indeed maximise leaving the child window in place and it happens in fairly quick.
When the child window closes, a script is triggered to enable the parent window again, the parent window is already maximised.
See an example of both methods here, BTW Im not saying to buy such a plugin for this, but I use it for many other things so I thought it would make a good example to show the difference.
By the way, all the red dots around the dialog box appear when im clicking the mouse trying to activate the parent window.
mac users dont have these sorts of issues since they are not running the document windows within another window unlike us windows users.
I have looked at maximized FileMaker Pro windows in Windows XP. I am sorry to take so long. I have had a very heavy schedule lately.
I have few Windows applications, so I can only give limited comments on what the expected behaviour is in Windows.
FileMaker Pro does something odd in Windows - it tries to be a Mac application. By that, I mean that the application has a window of its own where the menu bar appears. All FileMaker Pro document windows appear in the application window and have no menu of their own. Double-clicking a FileMaker Pro file will not open the file in a new FileMaker Pro application window or a window of its own if FileMaker Pro is already open. It will open the document window in the existing FileMaker Pro application window. This is a definite departure from the norm in Windows, at least when I compare this behaviour to all my other Windows applications.
Is this a good thing? I think FileMaker would be hard pressed to do things much differently. We expect to see our solutions work almost identically on Windows and Mac OS. How would a classical Windows application deal with a FileMaker Pro hidden window? Should they show up on the task bar?
In FileMaker Pro on Windows, a document window becomes the application window when it is maximized. It is not the same as a window resized to fit its content, even if the content is the size of the application window or larger. All other windows are in an odd state, as they are hidden, but not hidden in the usual FileMaker way.
Let's assume the current window is maximized.
If you switch window, then the next window will also be maximized. On a sufficiently slow system, you will first see the current window restore down, then you will see the window you are switching to maximize.
If you have a script that creates a new window with a predefined size, then the maximized state of the current window will be lost because there can only be one window, the application window, when a window is maximized. If you have a script that creates a window without a predefined size, then the new window will be maximized and the previous window will be hidden (in that special sort of way).
If you close a window that is not the current window, it will close and the current window will remain in a maximized state.
It seems the current window is the only window that "remembers" it is in a maximized state. If you close the current window, the maximized state becomes lost. This is the only flaw I see with this windowing model, at it seems to go against the expected behaviour.
There is an easy workaround. Let's assume the current window is window 1 and the window "behind" it is window 2. First, make window 2 the current window. Then, close window 1. Because window 1 is no longer the current window, it will close without changing the maximized state of the current window, window 2.
If I understand the posts I am seeing on this thread, many are looking for a way to place the equivalent of a modal dialogue box in front of the maximized window. FileMaker Pro has no ability to create arbitrary modal dialogue boxes other than the "Show Custom Dialog" script step. I believe plug-ins are the only solutions in this case.
I really hope this helps folks understand FileMaker Pro on Windows a lot more. I spent quite a bit of time to understand this myself.
"If I understand the posts I am seeing on this thread, many are looking for a way to place the equivalent of a modal dialogue box in front of the maximized window."
That's exactly how I use this script step.
"FileMaker Pro had no ability to create arbitrary modal dialogue boxes other than the "Show Custom Dialog" script step. I believe plug-ins are the only solutions in this case."
With careful scripting, a new window command can replicate the functions of a modal dialog without using a plug in. The result can be a bit "clunky", since you can't eliminate the window controls in the upper right corner like you would for a real modal dialog, but other than that, you can do it.