I never expected when I started this post that it would become one of the best I

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.

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.

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

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.

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.

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?]

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

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

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

Already had my Thanksgiving last month

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

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?)

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.

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.

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!

Hi Ray,

Just as a footnote. I

I just joined the forum and if this is an example of what I