It seems to me you simply have two similar sets to be found: both sets meet some other criteria to produce the original found set, but then some have DB and some have DRIB. My suggestion would be that you simply find each set separately—
1. Find by your other criteria AND (new find request) DB—print that set
2. Find by your other criteria AND (new find request) DRIB—print that set
sort of. records that have DB and DRIB are the same and anything that doesn't have DB or DRIB will print to a different layout.
we could easily find each set separately but we want to streamline and automate it by scripts to make it easier for the user.
The latter is certainly possible. Just construct the relevant Find step within a script that also manages the printing and attach the script to a button. You could manage the whole lot within a single script that branches according to user selections.
how do you do branches. currently i have set up a few different scripts and have used custom dialogs and Get (LastMessageChoice) and perform script to navigate to the next script. do you just mean use If Get(LastMessageChoice) and then carry on? its kind of good in a way having it separate as you can see where your problems are etc.
Currently i do have find steps that manage the printing but when i use omit records i can't find a way to just omit the records from the previous find rather than for the product list.
edit: should i use modify last find after i have printed the first lot of records?
Pretty much i want it to say
- if the current found set includes products with "DB" or "DRIB" in the product code print those particular records to layout 1 and print all other records in the current found set to layout 2.
- else if the current found set doesn't include products with "DB" or "DRIB" in the product code then print all records in the current found set to layout 2.
does this make a bit more sense?? i just don't know how to write this properly in the script
One of the most efficient and easily debugged methods is via a series of short, single purpose scripts which you call from a master script as required. So you might create a script that constrains the current found set to those records WITH DB and DRIB and another that constrains the current found set to those records WITHOUT DB and DRIB.
However, that is not the whole story because your requirements appear to include working from an initial found set. Is that predictably scriptable? Or is it whatever is the latest whim of the user? Either is scriptable, but they present different challenges. If it's the latter, you might, for example, create a CurrentFoundSet field, which your script would populate with a 1 before proceeding to muck up the set by constraining it, then at the end of its run it could find all records with a 1 in that field and then clear the field so it is ready to reuse. Another method could be to control the whole process of finding by presenting the user with global field in which to enter their initial Find criteria, and using those values to reinstate the initial found set when needed.
So a script might be:
1. Working with an initial found set—created either by script or user selection—mark all the current records in some way.
2. Run the "with DB and DRIB" script to print this set of records
3. Use the current found set field to reinstate the initial found set
4. Run the "without DB and DRIB" script to print this set of records
5. Repeat step 3, and crunch the current found set marker field
i think you have got what i mean now. it is just "whatever is the latest whim of the user".
can you explain more on how to setup the currentfoundset field and how it should all work out please.
1. Create a number field on the table of records you are using; call something like FoundSetMarker. As you don't want users to enter data in this field, check the option "Prohibit modification of value during data entry", and also don't put it anywhere on any layouts.
2. Make the first step in the script: Replace Field Contents [ yourTOname::FoundSetMarker; Replace with calculation: 1 ] [ No dialog ]
3. At steps 3 and 5 in my previous post your script can use this field to perform a find which will reinstate the marked set.
4. At step 5 you would also, as the last step in the script, use a similar step to 2 above, but clear the value: Replace Field Contents [ yourTOname::FoundSetMarker; Replace with calculation: "" ] [ No dialog ]
thanks for that.
the only problem is i need another step that decides if there is any records that have db or drib in them otherwise it just continues to the layout and requests to print a blank record with CodeId.
something like if current found set includes records with db or drib, continue to go to db/drib layout else go to non db/drib layout.
this also needs to work if there are db/drib records but no records that don't have them - it will need to skip the last step.
You can cover that using error capture. Your script needs to be something like:
1. Mark the found set
2. Set error capture ON—this enables you to control how the script responds in the event of an error (see steps 4 and 7 below)
3. Run the "find with DB and DRIB" script
4. If no records found (error 401) move on, otherwise print this set of records
5. Reinstate the original found set
6. Run the "find without DB and DRIB" script
7. Repeat step 4
8. Repeat step 5, and crunch the current found set marker field
thanks for that keywords.
i think i have got it sorted now and will finish setting the script up and let you know how it goes.
Marking a found set is OK for single-user systems, but can be problematic with multiple users. Also it modifies the modification date/time of the record if you care about that.
I'd probably approach this by starting from your found set, open a new window, then Constrain the found set to DB/DRIB, print, close the window; then do the same thing but Constrain to ommitting DB/DRIB.
The user is left with the found set undisturbed, and no issues with multiple users.
good point, if two people are trying to print at the same time we will have a few issues won't we ??!!
is it possible to reinstate an earlier find? so constrain found set and print then reinstate and constrain again? and for omitting records is the correct entry Set Field [Table::Field; not "DB"] etc.?
should i use modifylastfind
this is what i have so far screenshot2.png - Google Drive