1 of 1 people found this helpful
this script step is not (has never been) Mac compatible. It's not a bug.
- Windows: all windows were displayed inside the FileMaker application window
- Mac OS: windows are displayed on the Desktop
- Windows and Mac OS: windows are displayed on the Desktop
The difference is that on Mac OS, there is only one Menu Bar, and it can't be hidden. On Windows, every window cans have a Menu Bar or not.
On your Mac, the Menu Bar should be displayed on top of one of the monitors. Do you mean it does not appear on any of your displays if more than one ?
I just noticed while debugging.... Error code 3
I still don't 'get' what you are saying when you say "Windows and Mac OS windows are displayed on the Desktop".
In Windows all the 'secondary' / 'report' windows running the same script show their own menu.
In Mac OS, they don't and apparently CAN'T????
16 is starting to make 15 look good...
Thanks for the thoughts.
I kept thinking of what you said: "The difference is that on Mac OS, there is only one Menu Bar, and it can't be hidden. On Windows, every window cans have a Menu Bar or not."
So I tried attaching the following script trigger to my Main window (On LayoutEnter)
Show/Hide Menu Bar Show
Install Menu Set "Membership Menu"
In Mac OS, the PRINT menu DOES show on the Report window (I suspect this may confuse users in the beginning) but as soon as I click on the Main window, I get the default (MembershipMenu).
And, in Windows, each window has it's expected menu.
Thank you very much for your idea and comments. (If you couldn't tell, I was 'stuck' in my search for an answer).
The bottom line it is not a 'bug'. It is 'me'. And 16 is acting as designed. But, I must say, some parts of 16, like this little problem, are counter intuitive.
I still don't 'get' what you are saying when you say "Windows and Mac OS windows are displayed on the Desktop"
On Mac OS, there never has been a main Program Window that would enclose all other windows fore that program. On Windows it's called MDI (Multiple Document Interface). Up to version 15, on Windows, FileMaker was running is SDI (Single Document Interface), that is you see all or nothing. In fact that's partially true only since the Inspector window was outside of the main Program Window.
Now in 16, FileMaker did away with SDI on Windows, for our pleasure .
RE: MDI / SDI
What I find confusing is that BOTH FM mac and FM PC are operating in the
same way. But, the same feature (a custom menu) does not result in
identical outcomes. Specifically, Windows allows for additional windows to
have their own menu. OSX mandates that additional window menus show on the
I haven't seen this behavior in any other software so it is hard to believe
that it is a function of the OS. Or, am I wrong about that?
In any event, a layout level script trigger fixed the problem. But, this
being the case, doesn't that indicate that the solution to this difference
'could' be affected in the underlying Filemaker design???
No, they are not operating in the same way.
Yes. The question is, "Since they are both operating under the same paradigm, WHY don't they operate the same way?
Right. They do NOT OPERATE in the same way.
In Windows, a 2nd window can have it's own menu.
In OSX a 'new' menu is attached above the 1st Window.
Hence they do NOT OPERATE in the same way.
(this is what I mean by operate in the same way. I have no idea what you
But, since they are both MDI, the question is WHY don't they operate in the
same way? Is it because of a difference in OS or is in the way that FM 16
is written in each OS That is the question....(Hamlet)...
On Sat, May 20, 2017 at 6:08 PM, BruceRobertson <firstname.lastname@example.org>
It's a matter of operating systems. FielMaker can't go around the architecture of an OS. Even in the times of Mac OS 8 and 9, the menu bar was detached from an application.
Thanks. I can quit wondering 'why'...
This situation becomes reason number 357 why I develop in OSX...
I appreciate your clear insight. Thanks again.
I'm not sure, but I think perhaps the question you're asking is why can't FMP "abstract" (hide) the OS differences for the developer? That is, why can't FMP make reasonable decisions that don't dump error codes in your lap?