Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8013 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

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

Posted

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.

Posted

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.

Posted

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.

Posted

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"? smile.gif

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.

Posted

Hi Bob,

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

Posted

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

Posted

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?

Posted

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. smile.gif

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.

Posted

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.

Posted

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.

Posted

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

Posted

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

Posted

Overwriting data in Find mode is easy to fix. Don't let them use Find mode!

Create a "Find" layout with global fields. Users enter into this in Browse mode, then run a script that transfers the data into the real fields and performs the find.

Posted

If [ Status(CurrentMode)=1 or 1 ]

Oops, did I leave that in? The "or 1" part shouldn't be there. I put that in originally for testing (so that the conditional part would always execute) and apparently forgot to take it out. Sorry.

Vaughan, Yes. I don't like the user to be in any mode except browse. Using globals to enter find requests is safest. But, sometimes, it's hard to forego all the stuff that Filemaker has so conveniently provided in find mode. The example I posted is actually a find routine that I added to the latest version of my documentor db which I will will shortly post to the Samples Forum. I can get away with giving the users access to find mode in this one, because a documentor utility is only ever used by skilled FM developers. smile.gif

Posted

This should probably be a second thread... some may miss out... anyway...

I have not pitched find mode... it is very intuitive for users to use the layouts they are familiar with when specifying a find... and although that can be done with globals, it is so much easier to maintain just one layout... its too easy to update one and forget to update the find variation of it. So, instead I try to make Find mode look just a bit different... I am currently experiementing with color to make it stand out.

But that doesn't address your real question... find mode is just one source of users screwing up data. I actually have a couple threads on this topic going in Right Brain... validations and such. But ultimately, my solution for users making major messes is a solid Audit Trail! That way, 3 days from now when someone is complaining about stuff being messed up, I can:

1) Easily see who made the changes to the data

2) Easily restore the data to its prior values

3) Easily know where the changes were made (which layouts/fields) so that I can study whether the UI needs to change or the User wink.gif

I also use Audit Trail for a large portion of the things people use "security" for. I like to avoid field-by-field security as it complicates life for users and greatly complicates life for the developer. So, I just make sure only employees can get access and that they all know that every change they make is tracked... try to add a month to your brother's membership or reset your daughter's grade to an A and we'll know you did it. That combined with the ability to restore the old values is plenty of security for most internal applications.

You can check out an Audit Trail implementation in the Starter Template that I posted in the Sample Files forum some time ago.

Posted

I would rather prevent screw-ups than try to find who's to blame after they happen. The audit trail is a nice feature, but I wouldn't want to rely on it too much. I have a client who has had a solution set up for several years. It has a few security holes in it, but hadn't been much problem until they hired some summer students to do some telephone marketing/data entry. They accidentally deleted a lot of data. The point is, we know who did it, but it's too late to do anything about it. (Yes, the audit trail can tell us what we have to fix, but it's a lot of work.) If the proper security had been in place initially, this problem would not have occurred.

Posted

I do restrict some things... for example, deleting records is only allowed by a select few. For everyone else, they can only "mark for deletion". The select few then review an either unmark or delete.

I agree with preventing mistakes where possible (see threads in Right Brain) and preventing violations where possible... but both can create their own problems if you try to get 100%, or even 90%. Thus, if you can't get 100%, and you pay a horrible price getting 95%, I prefer to go 85% and fall back on Audit Trail for the rest. [Did that make sense? Or too abstract?]

  • Newbies
Posted

This is just the most amazing thread!

That floating preview pallette demo just blew me away. I had no idea that there would be stuff like that here. Really good tongue.gif

I've rated this thread with 5 stars * * * * * !!!

Posted

Miriam, you are so right. The quality of information on this forum and this post specifically is teriffic. I especially like the discussions on different ways of doing things and why they do it this way instead of that way. It gets you thinking and if your a developer or someone just building a small personal solution. It gives new ideas and gets you thinking a little more about what you want the the best way to do it. And this is the place to learn!

To you and everyone, I wish you a wonderfull Thanksgiving!

hj

Posted

Ray,

Two questions kind sir.

1. What got you into the mind set of the "print-preview floating palette"? There is nothing in conventional FMP that would make you think you could do it. So what got you thinking "outside the box"?

2. Once you decided thats what you wanted to do. How long did it take you to get it right?

I ask the question because there are so many times we ask "how to you do this, how do you do that" and we get the answeres on the forum and we just following the instructions we're given. I think at times the "methodology" and thought process can be as important and instructive as the answer itself. If you don't mind, I for one would enjoy hearing your answers.

Thanks a lot Ray,

hj

Posted

Bob -- what a great question!

Ray -- I'm going down to Mordialoc over the New Year period for a sailing regatta. We should get together.

Any other forum people going to be in Melbourne then? Anatoli? Kurt? LiveOak? (I can dream can't I?) wink.gif

Posted

Hi hj,

Your questions are really very big ones, and I guess the answers are philosophical as much as they are technical.

In trying to respond to a few other questions of this type, I recently put together a brief paper called 'Thinking about Solution Design' which is available as a pdf download from my website. Perhaps that provides a partial answer to the more general aspect of your question.

As regards the more specific details of the background to the preview pallette idea, it originally grew out of a 'marriage' of two lesser techniques.

The first was one which I started using about eight years ago, in which when a user selects a particular report to be printed, a script gathers the required data, then goes to the relevant layout, enters preview mode and then displays a message (using the 'Show Message' script step) giving the user the option to invoke page set-up, proceed with the printing or cancel.

Separately, around six years ago (with the first release of FMP v4.0) I had started using a technique for bringing up related files like dialogs to select related values (using the Go To Related [show] command, followed by a loop which freezes the window in place until a value is selected). This was a handy breakthrough in the days before conditional value lists, and is still useful when the number of values is too long to be efficiently handled in a pop-up list or menu, or when more than two values must be displayed in order for the user to make a meaningful selection etc. I've since seen others using the loop-based technique to freeze a 'dialog' style FM window over another one.

From there it was not such a great leap to put the two methods together and use a dialog style window in place of the Show Messsage dialog, giving the user feedback and full control over the preview process.

The process for arriving at techniques of this type is really one of 'melding' together known techniques in slightly different combinations to produce a desired outcome. It requires a preparedness to consider unlikely aslternatives and to maintain a degree of openness - the 'anything is possible' mindset. FileMaker is, first and foremost, a creative tool, and all the 'rules' are all there to be bent. :wink2:

As to your second question, I don't tend to work much by trial and error, - I prefer to think through until I 'see' the whole solution before wading in. I find it makes for 'cleaner lines'. I'd have to say that once I considered the options and settled on this one as an acceptable solution, it did not take long to code an initial version which worked. Implementations of the floating preview palette that I've done since have taken about the same time to code as the first - there are a few scripts to set up.

Other developers may find that different approaches to problem solving are more effective for them, and there are frequently several angles to come at a problem from. Bob Weaver's container-pasting technique is an example of a quite different solution to a similar problem. As you say, in some respects the process of solving a problem is just as important as the solution/outcome.

Posted

Hi Vaughan,

Drop me a note when you know what your schedule is like for your regatta at new year. Maybe we can organise to catch up! wink.gif

  • 2 weeks later...

This topic is 8013 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.