I'm trying to figure if the formatting bar is showing or not. There is a function that tells me if it is allowed or not, but I cannot find a counterpart that let me know if it is visible (like what we have for the status area).
I must admit that if the function does not exist and it's not just me not seeing it while it stares back at me, I will be a bit disappointed.
Right now, to circumvent this, I run a script that toggles the formatting bar to figure if it is visible or not, but, to be able to capture the difference in Get(WindowContentHeight) it provokes, I need the window to refresh (done via a short pause right now). As you may guess this refresh, combined with the action to toggle the formatting bar, ends up making my hack visible to the user, who, even for a fraction of a second, will see the layout objects move vertically and back to their original place. I could do all this in a new window that is off-screen, but I would rather avoid any triggers to fire off in a new window. Plus, creating the window may fail and I would then need to error trap for that, ... you see the picture.
All this because I can't find a darn function that gives me something quite simple.
Not that it would be ideal, but might you be able to determine the status by checking a difference of ?:
Get( WindowHeight ) - Get( WindowContentHeight )
This seems to show some promise on MacOS with v.18 FMPA, and do not believe it would require any refresh. I must admit, however, I have not been thorough about thinking this one through -- it just looks promising...
Regarding an existing native function for this purpose:
Yeah, I think you're on the right track with Get(WindowHeight) - Get(WindowContentHeight)
Assuming you only need to detect these in Mac and Windows FMPro clients, then I think you'll be able to use the hardcoded heights to detect the Formatting Bar state. Here are a list of the height differences with the various bars/status area shown/hidden:
Therefore if difference is 131 or 47 on Mac, or 185, 101, 81, or 165 on Windows, the formatting bar is open. I haven't thoroughly tested this, except to gather up the values above, so forgive if I missed something.
Of course you can use Get ( MenubarState ) and Get ( StatusAreaState ) to further break down which values to look for.
I'm curious if FM has changed the heights of those bars from version to version or even OS to OS, but I'm not about to go down that rabbit hole today, haha. Good luck (and maybe this would be a handy CF to share on BrianDunning or otherwise).
My understanding is the chrome (status area, formatting bar, text ruler, anything else I forget?) is fairly consistent from version to version on the same OS. Between Mac and Windows, all there are differences. On Windows, I'm not sure how much has changed since got rid of the embedding window. As you can see, I'm mostly on Mac. Looks like I'll have to boot that windows machine to figure out the missing parts.
I remember that there were OS to OS differences, especially on windows in the olden days but I don't have any current data. Mac OSX window chrome has been consistent.
If ever I was to publish such a CF, it would be with a BIG disclaimer that says this needs to be tested on more configurations than I care to actually test for something that basically should be part of the product and would be ridiculously easy for Claris to implement. To top this off, I would say it uses hard-coded pixel dimensions that, even if they were to hold true for all OSes and FM versions to date, could not possibly be future proof.
Given all this, I honestly do not see how a CF would serve the community. There are things that are ok to leave up to us, to let us build on top. This specific item fits nowhere near what we should have to build ourselves and pretty neatly into what Claris should have done YEARS AGO.
I guess by now you see that I'm really not happy with the fact that this is MISSING from the product, unless all of us here are simply oblivious to a function that yields the result I'm looking for (not something I'm ready to believe).