Find conditions must change because of filter ...

[Diana, Cda]

Boy, you close one issue and another opens <g>.

Due to changes I've been able to make where I can now enter two types of data into a database and manipulate them, the FIND buttons are no longer good since they deal with ALL the data. I need to change the find to search, I guess, within the already found conditions (?).

Here is the current FIND ALL script now (not 100% accurate since my export to text took out at least some quotation marks, and maybe other stuff for all I know, but you get the idea):

Go to Field [ "Recipe Title" ]

Set Error Capture [ On ]

Enter Find Mode [ Pause ]

Go to Field [ "Recipe Title" ]

Perform Find

If [ Status(CurrentError)=400 ]

Show Message [ Buttons: "OK", "", ""; Data: "You did not enter any find criteria; all records will be displayed." ]

Show All Records

Else

If [ Status(CurrentFoundCount)=0 ]

Show Message [ Buttons: "OK", "", ""; Data: "No records match this request." ]

Show All Records

Else

If [ Status(CurrentFoundCount)=1 ]

Go to Layout [ original layout ]

Else

End If

End If

End If

Any ideas on how to accommodate the fact that the FIND ALL is not really a find all anymore? only a find all within the conditions of the layout.

(I'm attaching my db just in case. You'll notice exactly what I'm talking about when you click on the magnifying glass for FIND and click on "Cake" in the category value list pulldown. You'll get records from both layouts when the preference would be for just one.

Recipe Cataloguer Clone.zip

[Diana, Cda]

Can someone at least direct me to a template, then? I've been working on this since I posted it, and getting all sorts of neat results, just not the result I'm striving for. Thanks!

[LaRetta]

Hi Diana,

I'm also new to the forum and very new to FM, but I've been working with relational databases for 8 years. And, since no one else has responded (people are pretty laid back on the weekends), I thought I'd try to help you. I know what it's like when you have a problem and you have no one to help you.

The first thing I noticed in reviewing your file, is that you have 66 items in a value list called Category. There were other things I noticed that will probably continue to give you problems in using a flat-base structure. You currently are using omit to hide unwanted records and you are trying to split your information according to layouts (which are just views of your whole database). It's very true that I don't understand your needs but I firmly believe that, in 15 minutes, we could create two additional db's (Category & Source), join them to your Recipes db and solve your problems.

If you are interested in considering this ... it really is very simple and, once you 'do it' for the first time, you'll be addicted ... I know. Anyway, kiddo, let me know if you want to try it. If you still wish to resolve this problem in other ways, I'm sure the 'smart guys' will be back online tomorrow!

LaRetta

[Diana, Cda]

Hi, LaRetta, it's just that I'm not a fan at all of having more than one file to juggle. In the office where I was called on to make a db in Approach (Lotus) a couple years illustrated a major, major problem with this - there were old files from before where a good part of the components were missing and so were completely and utterly useless. I know that there are better ways than what I am doing, but this db is just for me and others on a strict diet for health reasons and so isn't for commercial use at all.

The only challenge is if FMP cannot handle (in the "flat" db mode) a thousand records, or so, if that. That would be the only thing that would make me consider using all those portals or whatever they're called. Sure, they're probably more "correct" or whatever you want to call it, but they do involve more than one loose component. (It was also was reaffirmed to me in last week when I dl a demo that was missing a piece and so wouldn't work at all.) No, I'm very leery of that. To all intents and purposes I'm a FMP newbie but I've been working on computers for 15 years now myself and if FMP could keep relational db as whole units, then _yes_, I'd go for it in a heartbeat. Meantime, this quick and dirty way may not be the best, but it seems to be getting the job done so far.

I thank you for your advice and know that you are right, but I hope you don't mind my quirk (?) <g>

[LaRetta]

I agree that Approach is a bit messy with .adx .dbf and .dbt's. I agree that we all want to keep things as simple as possible. I don't agree that a flat-base database is easier. Regardless, Diana, we'll help as best we can. I hope you find that demo you were looking for. Cheers!

[mdpres]

Hi Diana,

Its Monday so I might be a bit foggy what your trying to do here.

Dean

Sorry about my 1st statement here I went down to your other posts and read a little more of what your trying to do. If you just want source file m insert it in your find step.

[Kurt Knippel]

Diana,

When faced with a scripting challenge like this it is best to describe in English what you are trying to accomplish.

For example:

Find All:

Show all recipies to user

Find:

Goto find screen

Allow user to enter find criteria

Find records

Display errors to user

Show user found recipies.

Once you do this it is ofen clear if you have a problem, and it give you a guide for doing you scripting. You should try be a bit more descriptive than I did in the example above, breaking things down as much as possible.

This will both help you to solve the problem and if you post this English description here, it will help people on the Forums solve the problem.

[Diana, Cda]

lol, LaRetta, just read your post again, NO I didn't mean flat-based db's are easier to create or use or anything, I don't think any db is easy. It's just much, much easier to deal with _one_ file. As a power user, even if a non-techie newbie in many ways, I am called upon at office to help my colleagues out all the time. Believe you me, having to backup multiple components for _one_ database file is beyond the comprehension of most people, as stupid as that may sound, and so they don't. Hence the missing components in the various types of db's I've worked with in offices (and not just Approach or even just db's, btw). Anyway, I do contract work, usu. short term, so I see a lot of this type of thing in general, what will trip people up.

Anyhoo, much much thanks for the offer of help; I am just so overwhelmed at how fantastic this forum is. The help has been tremendous. My db will be available once done as freeware to many people in a sort of health-through-diet forum and I know they will be very glad that I recvd all this great help!

[Diana, Cda]

captkurt, neat! and thanks for teaching me this. I tried to figure out how to go about it in this case, but it'll be easier if I just do an overview and attach the file itself, if that's okay. I obviously don't have enough of the terminology down pat yet to describe what I need to do properly.

So, in essence, the way the db is breaking the data up now is perfect for me. What happens with the find with conditions, though, is that when doing a find on one type of data, both data types are returned. Now, honestly, I spent nearly a couple of hours yesterday trying to fix this and I plugged in the code (as per another thread) line by line and in different combinations. I'm obviously not doing this right still since it hasn't returned good results yet. Removed all the extra coding and returned the FIND WITH CONDITIONS to normal. The Find I mean is the magnifying glass one. The FIND ALL works perfectly, it seems, btw.

p.s., on advice on how to toggle off the status area, I put a "perform find" button in (trying to get a mask to work); the mask is not my concern right now. What is a problem is that when keeping the status area on, I see that the "perform find" doesn't get rid of the "continue" button as shown when I manually turn the status area on. This continue button remaining is what has caused the SCRIPT > SCRIPTMAKER to be greyed out in the pulldown menus when the status area off.

Anyway, one step at a time. It's how to get the FIND to return records of the right data type (M or B, depending on whether in MISC layout or BOOK one).

Thanks! What an adventure this is!

Recipe Cataloguer.zip

[LaRetta]

Oh, Diana, I know what you mean about backups. I

[djgogi]

Get rid of all those pauses and restores (change Enter Find Mode [pause] to simply Enter Find Mode [] and Perform Find [Restore] to Perform Find [])

Also if you want to allow user to enter manualy find criteria you'll need to separete scripts:

The first one simply enters find mode (without pausing) and the second one actually perform find on user click (without restoring).

Now to condition find on current layout you'll need just one statement like this one:

Enter Find Mode[]

Set Field[source, Left(Status(CurrentLayoutName),1)

Perform Find[]

The above is fine if you have only two layouts which names start with letters B and M otherwise use something like this

Set Field[source,If(Status(CurrentLayoutName)="Books","B",If(Status(CurrentLayoutName)="Misc","M",""))

HTH

Dj

[Diana, Cda]

Great, okay will do re fixing up the Find. I never wrote that myself but picked it up out of a demo file somewhere and have used it in my homemade solutions ever since. Worked fine till I needed to split the data. I'm not surprised that it's full of unnecessary code due to all the trials I did with it recently. Will try to re-do.

I'm seriously considering at this stage if I can't get it to work, just to use a simple find script. Anyhoo, will see how successful I am in fixing this.

Thanks!

[Diana, Cda]

Ouch, LaRetta re the backup issues!! I hear you even if I don't do the type of work you do. At home it is an issue. I'm still backing up manually onto CDs since, a real pet peeve of mine, I have yet to find a single, decent program that properly backs up to CD re spanning. I didn't want the ones that go to zip format, but had to knuckle down and try. No good; noat a one worked and I have tried, literally, 2 dozens apps of various kinds. So, I backup, CD by CD. I have an excellent freeware cataloguer so at least I don't get lost trying to find my stuff afterwards!! Thanks and cheers!

[Diana, Cda]

djgogi, hi!

Well, I give up on the one <pulling hair out>. When I remove the pauses, nothing works. The pause powers the masked "perform find" button so without it that also doesn't work. Haven't a clue as to why this is.

So, I just went ahead and made a test FIND without all the fancy error messages and tried it. That seems to work much better. Am going to test it out more fully to see if that does the trick.

[djgogi]

OK, I've fixed the file the way you intended to use it.

I've added two fields and one relationship based on those fields.

It's only purpose is to enhance the Ray's invisible Find button trick.

Pratically now the button is only active if in find mode (in original version the button was clicable in either modes).

Also I've changed the button script, well maybe is better to say I've eliminated the button script, now the button has attached step "Resume Script" instead of Perform Script "Invisible find"

HTH

Dj

Recipe Cataloguer Clone.fp5.zip

[Korky]

When you click on either of the "Source" Tabs on the respective layouts FMPro performs a "Find" script.

In order to find records within the found set you need to modify the last Find by adding another criterion. Thus the script underlying your Magnifying glass button would look like this:-

Modify Last Find

Go to Field["Recipe Title]

When this script is run FMpro enters Find View with the Source Field already filled in. You enter data into the Recipe field and then click Find. You are actally running an "AND" request.

Change your "Find All" buttons to run the same scripts as the "Source" Tabs.

Problems with this approach are:-

1)If yo do a manual Find using the menu, this will be the last find and is the one that would be modified. This could produce strange results.

2) You couldn't allow for errors in the way that you have.

I attach your file amended as above.