What do the experts say regarding Status Bar / No Status Bar?

You see many different solutions today. Some show the standard FMP status bar on the left and some hide it. Other than aesthetics and allowing additional space on the window. What rational would one use to determine the way to go with a custom solution?

It may seem trivial at first blush, but it's really something that needs to decided right up front. Or at least before you write your first script.

Thanks for your help.

hj

In order to lock down and control our solutions, we are 100% hide and lock Status Bar. The only databases I've done with an unlocked Status Bar are the underdeveloped, never worked on ones I use in my own office (the shoemaker's kids go barefoot)!

-bd

Hi Harry,

Like a good few other 'features' of FMP, the status area is something of a hang-over from FileMaker's early days. It has barely changed a whisker in either function or appearance in more than ten years. It looks dated and it is.

The chief value of the Status Area is that it provides a means of navigation that you can use before you've built custom navigation - and as a way to test and troubleshoot custom navigation systems during development.

Like Brent, I never give users any form of access to the status area in a finished solution, for a longish list of reasons - aesthetic, security and functionality and ergonomic reasons being high on the list! :smile2:

In general I never allow user access the status bar either, with ONE exception. When previewing a printed output, I do show the status bar, so that there both a "Continue" button on the screen and so that users can flip between pages. I also lock out pretty much ALL layouts so that the user cannot switch to a different layout when the Status bar is open.

Ditto with me, my use is exactly the same as Kurts. However having said that, I think the status area is still a great interface even after all these years: it's elegant, simple and relatively intuitive even across different modes (browse, find and preview).

In preview mode, I provide users with a floating navigation palette with all the functions and information relevant to the particular report. That way I can have scripted buttons, working in preview mode, etc, not to mention maintaining the look and feel of the interface.

'Simple' and 'relatively intuitive' I can accept. I couldn't agree with 'elegant', however. Battleship grey, clunky and extraordinarily wasteful of screen real estate don't line up with elegant as far as I can see...

It's elegant in that the same bar is used for browse, layout find and preview modes with no change in interface functionality. I think that's pretty good! As far as battleship grey... that's just fashion.

*Deep thoughts*

Hmm... I only lock out status bar sometimes, not always. Come to think of it, you guys bring up some good points. It is ugly, space wasting, and basically useless.

The idea of floating palette is interesting, can you point me in the direction of how to set that up?

You can duplicate everything in the status bar except the little slider thing, which I find quite useful when the found set is large. So, I generally put in a couple of buttons that skip ahead or skip back by a percentage of the current found count. Like so:

# Script for skip ahead button

Set Field [gTargetRecord, Min(Status(CurrentRecordNumber)+Int(Status(CurrentFoundCount)/10),Status(CurrentFoundCount))]

Go to Field [gTargetRecord,by field value]

---

# Script for skip back button

Set Field [gTargetRecord, Max(Status(CurrentRecordNumber)-Int(Status(CurrentFoundCount)/10),0)]

Go to Field [gTargetRecord,by field value]

---

Ray... do tell how you get a floating navigation palette.

Pretty please with sugar on top!!!

While we wait for Ray's reply:

I kinda like the Status Area. Although it doesnt seem practical in some apps. I like having one extra way of manipulating if its built into your soln. Besides, I notice Mac-conscious FMers make their work areas kinda small anyway so there's plenty of room

I was laughing when I first read this because the original question was about the Status Bar which is that little bar on the bottom of the window. But somehow everyone knew what he was really talking bout (or did they? )

Cheerio!

First let me say that I will post a demo of a floating pallette technique on my website in the next day or two.

I have a heap of techniques developed or adapted over the years that I've been working my way through doing demos of, as time permits - and that one was on the list, but I'd not yet got to it. Given the interest expressed here, (and back-channel, since I mentioned it on this thread) I've moved it up the list.

I'll post here with the URL when it is online.

Meanwhile, it may be of interest that the 'Status Area' was orignally called the 'Status Bar', and is referred to as such in all the earlier application documentation - including various articles still available on the FMI Kbase (eg article #101304 - one of many such examples) and there are even occasional references to it by that name in recent version documentation!

As the Status Bar that Ken is referring to is a Windows-only phenomenon, I suspect that a lot of MacOS-only users use the terms interchangeably. I'm guessing that is one reason why we all knew what hj meant?! :wink2:

An alternative method for providing 'fast-forward' and 'fast rewind' style navigation options, is to use a modifier-key click combination to invoke rapid scrolling, with a script along the lines of:

If ["Status(CurrentModifierKeys) = 1 or Status(CurrentModifierKeys) = 3"]

loop

Go to Record/Request/Page [Exit after last, Next]

Refresh Window [ ]

Exit Loop If ["not Status(CurrentModifierKeys) = 1 and not Status(CurrentModifierKeys) = 3"]

End Loop

Else

Go to Record/Request/Page [Next]

EndIf

With this in place, users can hold the shift key down and click-and-release the forward button. Fast scrolling will then continue until they release the shift key (or the end of the file is reached).

There's a locked demo of this one on my website. If anyone wants to take a look, the direct URL for the file download is:

http://www.nightwing.com.au/FileMaker/demos/nav_bar.zip

The main purpose of the file to to demo some other navigation stuff, but you'll see the fast-scroll at work in it also.

It

Thank you for saying exactly what I feel!

I second that.

Ray is Gem in our community

Ok folks, a demo of the print-preview floating palette is now available. It is a tour of the basic technique and could be described as the 'midrange' version - ie it doesn't have *all* the bells and whistles, but enough to give the general idea.

Hopefully the interface is fairly self-explanatory. And the file is password free for the benefit of anyone who wants to inspect the 'cogs and levers'. The download is now online, and is available as a choice of either a PKzip or Stuffit archive at the following URLs:

http://www.nightwing.com.au/FileMaker/demos/PreviewPalette.zip

http://www.nightwing.com.au/FileMaker/demos/PreviewPalette.sit

Comments and feedback welcome!

That is incredible! It is also elegant! I can't wait to use it! I think I'll design a report I can use it on RIGHT NOW! You are much appreciated, Ray!

Ray, the "floating palette" is incredible. I had no idea such a thing was possible. Once you had the idea, how long did it take you to figure it out and actually implement it?

This does beg the question, what other goodies have you been fiendishly hiding from the unsuspecting public?

I hesitate to use the old expression "you da man" so allow my simple, "You're the Daddy! Now the only question is who is the smarter of the two. The one who started the post "me-me-me-me-me! Or the one who answered it? I think we all know the answer don't we. Oh ya, fer shur! I mean Ray's a doctor and FMP developer and all that. But think of my post "Status bar vs. No Status bar" now that's some pretty heady stuff.

Got to go, my wife said I can't play anymore. But don't let that effect your voting. Sorry Ray but "they love me maaaaaaaaaaan!�. Thank you, thank you very much"...

Excellent work Ray.

It is really pity, that FMI doesn't think enough about developer problems or logic. How long will take for them to produce something like this available for all developers straight from single database?

Just curious if anyone would share an example of "no status bar" techniques? Layout space can be at such a premium. There are times when using another layout doesn't work very well because the information needs to be seen in one place for continuity. So anything to help clean up the clutter and give better visuals is essential. We have all opened a file and our first reaction was "whoa, what

Just saw a great example of the "No Status Bar" example at: www.clevelandconsulting.com

It has some great features Take a look. It's the solution that's called "Navigation"...

hj

At first: compliments to Nightwing for the floating Preview demo

Another, far from elegant, but at least more then less solution, for enabling scrolling through preview pages, is to script the next/previous record/page/request steps and make them available through command+[1] and command+[2] (or whatever number key)

Harryk

What I usually do is create a script that enters preview mode, goes to the selected page, copies the page, goes back to browse, and then pastes the image into a container field. I have buttons for moving forwards or backwards etc. The user is always in browse mode except for the brief instant that the script runs to capture the output page.

Bob,

Do you have a demo of your solution. I'm not sure I understand your approach.

hj

>copy preview pages into container fields

not a bad idea when it's only one or two pages, but more pages..mmm..

An image is not small in size usually.

It's a global container field, so there is only one image in memory at a time.

I'll try to find something to post as a demo.

Here is a demo of the container field technique.

Got the idea from Captkurt.

PrevueNavbar.fp5.zip

Appreciate the demo, Bob!

The approach it illustrates provides an alternative that would likely be preferred by developers who veer away from allowing the use of windows in the Windows OS (ie who 'maximise' everything) - but who nevertheless don't want to make the Status Area accessible.

Like the Status Area, it uses up a slice of screen real estate, but it can be a much smaller and less inconvenient 'slice' (eg you have control over its placement!) - and has the advantage of being able to be crafted to match the 'look and feel' of the solution. Neat! :wink2:

I first started using this idea on a solution that I inherited. The client wanted to view daily sales summary info without having to print out a report, and it was easier to retrofit this into the database than try building something that would allow paging through a preview without messing up the user interface. Since then, I've found it useful for generating quite a few quick (often single page) summary views.

Summary views would be an excellent application for it Bob.

Clients often require quick summary 'snapshots' that can be viewed on screen, and sub-summary parts don't work in browse mode.

A neat way to approach this might be to have the container field in a related 'summary snapshots' file, with a date and a notes field and a few other details. That way clients could save an unlimited number of summaries if they wished (and the back and forward arrows could be used to navigate through the saved 'snaps') - without bloating the size of the main file.

Hi Bob,

I love your idea. I have a silly question however ... The only way I can understand things, is to select everything and then see what script is attached. Your forward/backward buttons aren't even grouped (they're like one graphic) and I see no script attached to each button, nor a script attached to the 'group.' However, when I look at the scripts, there are four - one for each button.

Question: How can a script be activated when you click the Skip Ahead button if a script isn't attached to it? How does the script know which button you are selecting?

Hi LaRetta,

Bob has been a little tricky and has attached the button definitions to separate rectangle objects, which he as then formatted with transparent line and fill characteristics. As a result, you can't see them in either browse or layout mode (or any others for that matter).

In layout mode you can't select them by clicking directly on them either. However if you use the mouse to click-and-drag a selection rectangle across the area that they're in, or use the 'Select All' command from the edit menu, you will see the little 'handles' (black squares at the corner) of each of the button objects.

It's easy to miss, unless you know what you're looking for!

Well, thank you Ray! That makes me feel much better! Ahhh yes, I have noticed that, when you draw a rectangle, it's difficult to click-select -- seems you have to get EXACTLY on the line or it doesn't select it. Tricky, tricky Bob! I really like this technique and, once I figure it out, I'll bet there are other things in which it will come in handy! Bob, thank you for sharing it with us

Hi LaRetta,

I found that out too. Nothing else worked so I held down the Ctrl. key on the Pc, held down the mouse button and dragged over the buttons and sure enough, there it was. That Bob is a tricky little devil!

hj

One last thought regarding the Status Bar is the

Nothing else worked so I held down the Ctrl. key on the Pc, held down the mouse button and dragged over the buttons and sure enough, there it was. That Bob is a tricky little devil!

Sorry about the confusing buttons. I wasn't trying to be tricky. I just happened to have that navigation bar as a single graphic since I had been pasting it into a bunch of different files and layouts.

In the View menu you can select the Show Buttons option. Then all buttons on your layout will have a grey outline around them.

In my status bar, I have an Omit button that simply omits the current record.

In Find mode, I have a separate set of buttons appear... one which Finds the omitted fields. So, you can get the same effect easy enough, but in two steps rather than one... find and then swap. Seemed less complex that way, given I find the swap omitted functionality to be so useful anyway.

As for the symbols palette, I would be interested in a good solution for that.

Come on guys, somone must have a "No Status Bar" solution that incorporates the "Omit Box" and Symbols". Come on, "Give it Up"!

hj

Here is a sample showing how you can replicate all the items in the Find Status Area (including the symbols popup). It's a bit rough around the edges, but it's something to play with. It may need tweaking to properly run on Windows because of the different behavior with popup lists. (Or is it popup menus?)

<11/17/2002> revised the sample so that hitting enter in find mode doesn't create problems.

It is popup menus that are so platform dependent.

Thanks for posting this Bob... figuring out how to do the symbol menu has been on my todo list for a while... for usability by average users, I consider it a must-have.

You have "If[ Status(CurrentMode) = 1 or 1 ]" in the EnterSymbol script... what's that?? "If in find mode, or even if not"?

Also, in looking at your implementation of the Omit checkbox, I actually learned something: the omit property is independently selectable for each find request/record!! Wow... now it seems suddenly more useful... maybe I will implement that, too. (I thought it was for all requests... so I just set up a Find Omitted button so you can find and then swap... seemed simpler... now I see I am actually missing some good functionality.) Looks a tad complicated, though...

Your documentation in the scripts is great... thanks! Can you give a quick run-down of what each global is intended to hold? I can infer it from the scripts and the field names... but I always feel more confident seeing a doc string on the field itself.

BTW, I think this is worthy of the Sample Files Forum. It will be part of my next post of my template as well! I'll let you know if I find anything as I map it into my files.

Thanks again.

Hi Bob,

I don't seem to be able to download the sample (404 not found)... maybe when you updated it something went amuck?

Hmm, yes. That happened the last time I tried to replace an attachment. Here it is again.

BTW, I should point out that this example isn't necessarily the way I like to do things. Just because you can emulate all of the basic status area features, it doesn't mean you should do it. I don't particularly like giving the user access to the symbol list, because it can be confusing to a quite a few people. There are other means to accomplish this.

My usual preferred approach is to use a layout with globals where the user enters find criteria (while in browse mode), and then a script enters find mode and transfers the globals into the appropriate fields, etc. This gives more flexibility, and allows other methods for getting the same functionality as the special symbols.

Other Notes on the revised example file:

I deleted a few fields that aren't used. These were leftovers from some experiments.

Field Usage:

gNReqs - This is the current total number of requests and is used only for display in the status area.

gReqOmitted - this is the global field that the Omit checkbox gets its value from. The various scripts update it whenever a different request is displayed, or the omit status is toggled. Again this is simply for display only.

gAllOmitStatus - This is a long string of zeros initially. Each position in the string represents the omit status for a corresponding request number.

0=Find

1=Omit

Eg. If request 1 is a normal find request, request 2 is an omit request and request 3 is an omit request, then the field contents will be:

0110000000...

This is used to update the gReqOmitted checkbox when navigating between requests. This is because there is no other way to determine the current request's omit status (except with applescript).

Symbol - A regular text field that is used as if it were a global. This is the field which is assigned the popup value list. A regular global won't work in find mode, so a normal field is used. It's important to remember to keep the field cleared. Otherwise it's going to affect the find results.

FindSample.fp5.zip

I don't particularly like giving the user access to the symbol list, because it can be confusing to a quite a few people. There are other means to accomplish this.

I partially agree... some will not get the symbol list, but I think they'll just ignore it... the intermediate users, who might be wondering how to search for a range but would never guess/remember the syntax, will be helped tremendously...

And I agree that if that was common, you could make it easier for all with a different layout for finding... but I've always thought it hugely valuable to stick with the same layout, as the users are very familiar with it.

OPINIONS: Which is better: finding using the normal layouts, or going to a special find layout whenever you hit "find"??

gAllOmitStatus - This is a long string of zeros initially. Each position ...SNIP...

This is used to update the gReqOmitted checkbox when navigating between requests. This is because there is no other way to determine the current request's omit status (except with applescript).

Is this robust in the case of "ModifyLastFind"?

This was where I stumbled and aborted when trying to implement this myself some time ago. I guess I could leave the global set across finds, and reset it only when they hit "Clear Specs" or delete a spec... but then I also need to make sure they don't enter Find Mode the normal way (Cmd-F), since I would need to clear it in that case as well. Thoughts?

OPINIONS: What is more valuable? The ability to augment your last find OR the ability to set up multiple specs with each having a separate Omit setting??

Symbol - A regular text field that is used as if it were a global. This is the field which is assigned the popup value list. A regular global won't work in find mode, so a normal field is used. It's important to remember to keep the field cleared. Otherwise it's going to affect the find results.

This bothers me... I don't like introduction of bogus normal fields... and the burden of keeping it cleared. I wonder if this wouldn't be a good place for a floating palette of buttons, where each button inserts a symbol. Using the same dimensions as my floating palette for controlling Print Preview, I could set it up so that I give a couple lines of explanation if you Shift-Click on a symbol. It might look like this after you shift-click on the range operator:

Insert Find Operator:

[ = ] [ == ] [ < ] [ <= ] [ >= ] [ > ] [ ... ] [ @ ] [ * ] [ // ] [ ? ] [ ! ]

... is the range operator; put it between two number, date, or time values to find any value

in between (e.g., 9-1-2002...10-31-2002 would find all records dated in Sept or Oct of 2002).

OPINIONS?

Question 1 regarding the effect of a modify last find. It's robust as it stands, because this example doesn't allow you to do a Modify last find.

But, since going into this customized find has to scripted to some extent any way, If the user chose to Modify last find, it would only be necessary to NOT clear gAllOmitStatus. So this shouldn't be a problem.

Question 2 regarding Symbol being a normal field. Well, I don't really like this anymore than you do. I leaves a lot of room for problems, but I was really just playing around trying to make a popup that works in find mode. I would probably replace this with a series of small buttons, one for each symbol. It might not look as nice, but would actually be easier to implement and it would be a lot safer. One other problem with the popup symbol list that I didn't mention is that if you click on it and then hit enter without selecting anything, the symbol field stays selected, and the symbol entry script won't terminate. If the user then hits enter to perform the find, instead of clicking the find button, nothing happens. You can get out of this by clicking anywhere outside the symbol field or by clicking the find button, but it's not very graceful.

Regarding an earlier comment about the conditional "If [status(CurrentMode)=1], this is very important, because you don't want to be executing scripts that think they are creating and deleting find requests when they are actually creating and deleting records.

I learnt the hard way. Do not show the status bar unless the user understands completely how the thing works.

A Managing director of company that I had an excellent DB set up for as a sales program got hold of it, tried it out without asking for even a preliminary explanation, could not work out why the numbers on that little thing on the top of the bar did not correspond to the record number he wanted, and scrubbed the whole program forthwith!

I do not even use the inbuilt 'find' mode, but always construct a layout and scripts.

Lesson 1.. do not use the status bar except for experienced users.

Which brings up a good point... Experienced users LIKE to see the status bar (I do at least).

Because I am familiar with it, I get annoyed when people take it away, but for new users I agree that you are better off without it.

Regarding an earlier comment about the conditional "If [status(CurrentMode)=1], this is very important, because you don't want to be executing scripts that think they are creating and deleting find requests when they are actually creating and deleting records.

If that was the conditional, I wouldn't have asked. But what you have negates what you just said. In EnterSymbol, you have:

If [ Status(CurrentMode)=1 or 1 ]

which AFAIK is the same as

If [ 1 ]

which will not give you the benefits you list above.

Am I missing something?

Brian

I think there are two perspectives here.

1. Solution developed for yourself and/or small office envirnment where you are part of the staff. (This I think can go either way depending on your staff, but I still think the