Hmmmm. On my Mac I do this with a script to open small windows which manipulate data in other layouts. I don't see a resize issue or the flicker you see apparently. If I understand you correctly that is.
Have you run your solution on Mac to see if it behaves similarly? Perhaps this is a behavior specific to the Windows OS and not to FileMaker itself?
Ron Smith, MD
No it only applied to Windows machines apparently which makes it all the more frustrating.
The main annoyance is that it could be fixed, as I mentioned various plugin's can do it. I guess I am just venting in the hope someone from FM will respond - in some way shape or form.
While the basic function is the same on Mac and Windows...the presentation is very different.
On Mac: the parent window fills the screen and can't be resized. Menu bars remain at the top, until you switch to another app.
On Windows: the parent window is in itself a floating window. And the current file window is encapsulated within the confines of that window. The nature of Windows' windows makes having a window maximized and restored impossible.
It would be nice if Microsoft would remove or at least change the function/appearance of the parent window. With that said, FileMaker could also work toward a different development set...SDI instead of MDI. But it would be quite the change. And there are challenges with keeping 2 windows related within the same session. You may want to put in feature requests with Microsoft also.
This can not be beyond the wit of Filemaker to solve - as mentioned some plugins appear to do it very well.
I recently returned to FM from Alpha 5. They have window control spot on, it just works as you need it to. Filemaker just fails at this, I guess there are fewer Windows OS users.
I am curious as to what plug-ins you are referring. I don’t recall one. Did see a Windows Control by M. Edoshin, however as I recall it did not address the sizing of the application window. Rather only the database windows, which my script does as well.
Once I encountered this issue, in 2005 or 2006, cannot remember which, I modified my code to encapsulate the filemaker database window inside the application window, since then no worries. No screen flashing, no window bouncing. I have over 200 layouts currently in my system with multiple windows called at will. The designing of database systems requires us to work within the confines and behaviors of the tools we employ. The windowing philosophy of Microsoft and Macintosh are fundamentally different, because of this any design for the Windows platform must embrace and adjust for these differences. To that end I created a “Full window” script which sizes my window to my liking and call it when needed in my navigation scripting. My goal is to give the user all the screen they need and squash the habit of forcing window maximization, if they have no need of pressing the maximize control on the window they will stop doing so. For me this modification is nothing more than a task of navigation, go to the right layout, make sure the display is the way I designed it to be, give it to the user to modify or view the data. Sure, it would be nice if Filemaker did more for me, but I still want the power of choice ( where do I want to go….. what do I want it to look like).
Works for me,
I guess there are fewer Windows OS users.
My understanding is that there are more Windows users, more Mac Developers.
I agree Tim. I wish it was better...and someday I'm confident that it will be. Until then, I can make the windows respond and act/look the way I want for the most part.
I basically do the same thing Tim. Custom Function to capture the size of the parent window. Custom Function to give me the app window dimensions. Generic script to resize the window. I call that script whenever I need and the window stays fit perfectly inside the app window. Looks maximized, but it's not. Then any new window doesn't cause flash, or resize the main window.
No need for custom functions here. A single script step as follows does the trick nicely:
Maybe since only one script step can stop this unwanted behavior (Screen bounce when new window is called ), I really don’t feel all that inconvenienced.
Try it you’ll like it!
Sorry it mangled my code.
"// Move/Resize Window[ Name:"mainwindow"; Current file; Height: Get( WindowsDesktopHeight ) - 10; Width: Get( WindowsDesktopWidth ) - 12; Top: 0; Left: 0]"
Here's hoping this goes through.
Looks like your example got dropped.
I use Custom Functions a lot. In this case I use those two custom functions for a lot of other stuff. Including getting window position and size. So I have the CF's even if I don't need them for this. It's kind of a habit...and means I can reduce the amount of typing. lol
I included that calculation in a CF, so I never have to retype it. And if an OS changes any of the pixel dimensions, I only need to make the change in one file and import it into the other. It's the Borg efficiency syndrome.
I got that!
Mine is a utility script in my interface file. Can call it from anywhere in my solution and change the script when needed.
You say tomato(c.f.), I say to ma to(script).
They both taste the same. Ha-ha
Although, I've met the occasional developer that loves Dodge and hates Chrysler. lol
You really need to get over this. It's a Windows thing. Microsoft Word does it. Microsoft Excel does it. FileMaker does it. There are workarounds to it. Does it have to be that way? Perhaps not, but it is what it is. FileMaker lets you have a lot of control over window sizes and positions, it just becomes part of the development process. 95% of our clients are on Windows and we develop on Windows, so it's just second nature to us. The trick is to never use maximised windows. Control the size of every window so your end user never encounters the issue.
Submit it to FMI as a feature request. It certainly won't be the first time. Then adopt good window management practices in your database development and don't stress about it. Complaining about it won't make it go away, it will just add to your frustration.