Open a new window (New Window script step). Either put a freeze window step before the new window step , or open the window off screen (top -2000 ; left -2000). The new window will inherit the found set of the window that has focus when the script is run.
Perform your find in this new window and Constrain Found Set instead of perform find. This will limit the search to the current found set rather than all records.
Save your results to a variable
Close window [Current Window]
This will drop you back in your original window without breaking the found set you were working with before you ran the script. Now you can use the value in that variable as needed.
I agree with Judd45 that the best way to do this is to run your search in a new window, but I don't see the point he is making about constraining the found set—you can perform whatever find you need to in that new window.
The key point is the last bit. If you do it all in a new window the current found set and record focus in the starting window will be unaffected.
The point was that dangelsaurus is starting with a found set and wants to find a subset of that found set. Creating the new window already begins with the first found set (inherited from original window), so why do that first search again? In fact, we might not even KNOW what the search criteria were to achieve the current found set when the script that creates the new window is fired.
That was my thinking on that.
I could be wrong, but the fact that you are searching a set of records that a) have the same foreign key (projectID) and b) the current taskID matches values to a DependentTaskID suggest that you do not need to perform any find, constrain, nor a loop to find the data needed to contact task owners.
Option 1) set up a self join relationship with two pairs of match fields:
Tasks::_fkProjectID = AffectedTasks::_fkProjectID And
Yasks::__pkTaskID = AffectedTasks::DependentTaskID
The list function can then produce lists of info from AffectedTasks that might be used to notify task owners.
Option 2) don't add anything to your relationship graph. Use ExecuteSQL to produce the needed list of info used to send out your notifications.
Does the new window solution work with WebDirect as well?
I'm a little confused (because of my lack of experience in FM) by your suggestion to use either the list function or ExecuteSQL function in the context of a script... I click a "completed" button, which executes a script which starts how exactly?
Webdirect is a single window environment, so it manages new windows differently, but if you freeze window or open the new window off-screen (negative top and left values) from the user's perspective the effect is the same. Short answer yes it should still work in Webdirect.
In "Button Setup" (double-click the button object, right-click the button object and choose "Button setup...", or select the button and choose Format > Button Setup.
On the Button Setup HUD, under "action" select "Perform Script" and select the script you want the button to perform.
sorry I should have clarified. I've got the script part down.. what confuses me is I thought functions (list and ExecuteSQL) are only used in calculations... I'm not sure how I would loop through a list in a script...
Ok I think I've got it, something along the lines of..
Set Variable [$Val; 1]
Set Variable [$sqlresults; Value: ExecuteSQL("...")]
.. Exit Loop If [GetAsNumber ($Val) > ValueCount ($sqlresults;)]
.. Set Variable [$CurrentValue; GetValue ($sqlresults;; $Val]
.. <do various checks here and send email if necessary>
.. Set Variable [$Val; $Val + 1]
Looks about right.