if you are insisting that the user hits an 'OK' button, why do you make it one script with a pause? Why not make it two scripts - one to take the user to the data entry screen, then another to create the task when they hit OK? It would be nice to have a 'Cancel' button beside the OK button, too.
For the second problem I would suggest you let the user stay on the same data entry layout, and show them a text field with a pop-up list of all the Contacts they can pick from. If that list would need to be narrowed you can have the list show in a portal on that screen, and filter it by a global text field which relates global text field -> portal relationship. You can attach a script to the portal lines to choose the one the user clicks on.
thanks sorsbuster... i probably didn't explain it well enough. there are actually 3 scripts in total (at the moment anyway). the first script launches when the user clicks a button to create a new to do item. this opens up a data entry layout in a new window to allow the user to enter basic things such as a description of the to do item, the date it is due, the employee to whom it is assigned etc. it also has fields for the user to "link" the to do item to other records (such as invoices, contacts, projects, estimates, etc). there are so many records in each of these tables that a pop up would not be practical as it would have thousands of records to scoll through. a filtered protal would also not work in this situation, because the user would have to type in the exact invoice number or project name in order for it to appear in the portal. additionally, the filtered portal only allows the user to reference exact matches in a single field. to get around all this, if the user wantes to link the to do item to a record in one of these other tables they click on a "search" button which performs a second script to open up the appropriate lookup layout to allow the client to enter in a global field which is then used to find matches across several fields in the specified table (invoice number, invoice client, invoice description, invoice amount, etc). the matching results are displayed in a portal and the user can click on one of the portal rows to enter the matching record in to the to do item.
so if a user has gone this far and entered in information, it has populated some global fields with temporary information. i want the user to explicitly accept or cancel so that they cannot go back to the original to do layout and open up a second, third, fourth... window, for example. it also leaves certain global variables still set which would affect other operations (like editing a to do record) until the new temp record is commited or cancelled.
i have toyed around a litle bit with trying to get pause/resume script step (which as far as i can tell is mis-named since it only pauses scripts) to work, but i don't understand how to prevent it from resuming unintentionally or how to allow the user to intentionally resume it as there is no "resume script" step that i can find. any thoughts on how to control the pause/resume functionality? i am assuming anyway that this will allow me (in conjunction with "alllow user abort off") to prevent the user from navigating out of the desired window without clicking either ok or cancel... i think?
I'd use Sorbsbusters first suggestion. Use one script to open the window and use a second script attached to a button on it to close the window and perform those script steps that currently come after your pause/resume step.
As to working with 1000's of values in a value list, there are a number of methods to trim that potential list down to more manageable proportions. A conditional value list where you select a category and then a second value list displaying only values is one approach. A portal for searching out values is also very useful and need not be limited to "type in the exact invoice number or project name in order for it to appear".
Here's a demo file that illustrates several ways to search out values, two of which are search portals where a user enters search text such as part of a name or description and is able to see a list of all matching values to select from.
I don't really see how the scenario is significantly changed. Why do you open a second window, and bring with it all the control problems that has? Why not just make the script take the user to a layout with the global data collection fields? If they then hit an 'OK' button on that layout it runs a new script to create a new record and post the data they entered. If they hit 'Cancel' it clears the global fields and returns them to their previous layout. You can check in the OK script that they have entered enough data. You can warn them in the 'Cancel' script if they have any data that will be discarded.
"a filtered portal would also not work in this situation, because the user would have to type in the exact invoice number or project name in order for it to appear in the portal. Additionally, the filtered portal only allows the user to reference exact matches in a single field" - well, not really. You can easily create the match field in the Project Portal (say) to be the name of the project parsed out into the first 1, 2, 3, 4, etc... letters of the Project Name, separated by a return character. (You could add the data from multiple fields to that match field and they could effectively search by Project Name, or the start of the invoice number, or whatever.) Then as the user types in the start of the Project Name it will progressively filter down the portal listing to only show those projects. You can do the same with the invoices. You can leave them with a 'Advanced Search' button which takes them to that table in Find Mode if the filter would be too lengthy (although they will still have to type in the Project Name in Find mode there, so what is the difference?).
The 'Pause/Resume'cript step does just that - trigger once and it pauses the script, trigger again and it resumes it. Your problem is because when 'Paused' the default is that the Enter key will resume the script. You will see the 'Resume' button highlighted on the toolbar. If you attach the 'Pause/Resume' script step to your 'OK' button you will see that it happily Resumes your script after you have correctly entered the data (while your script has been paused) as you wish the user to. But I still don't see why you would want to do this that complicated way.
thank you both for your thoughts. it is very helpful!
i am curious about the search technique you are proposing. if i understand relationships correctly, the parsed out match field in the projects portal, for example, cannot be a calculation field so it would need the values entered by auto-entry or script triggers on the fields containing the actual data to update the parsed match field? even then, wouldn't it require the user typing into the global field the exact string from one of the target fields. for example, if you use the first 3 letters of your project name, let's say "abc", then it will only satisfy the relationship if the user enters "abc" into the global search field whereas "a" or "ab" would not match? i don't quite understand how you would implement the technique you are proposing but i would be interested in learning if you don't mind explaining it a little more.
also, while i understand how the ok button can be used to resume the script, i still don't understand how the pause/resume will function properly as you are suggesting because it gets triggered as soon as the user hits enter as a means of entering their information into one of the text fields and resuming hte script will then clear the data they just entered? perhaps i can trap this with a keystroke script trigger or something...?
thanks for the sample file! that is very helpful. i have a search script which works quite well but it requires entering a "1" into a field in the related to able to desinate a record as found. therefore, it does not work so well with an "on modify" script trigger as it takes several seconds to execute so you cannot type normally. but with "on object exit" it runs quite fast even with a large record set simply because of the limited number of matches. anyway, i am curious why you would ever use the "starts with" search instead of the patterncount search as it will not find as many potential matches (e.g. it won't find "5" screw" if hte user enters screw). is it faster on huge record sets or something? speaking of hte pattern match method, i noticed that it is several times faster in "on modify" mode than my search technique in the same mode and doesn't drop chaacters if the user types ahead. that is a very useful algorythm that i can adapt easily to filtering multiple fields with a simple "or" statement. thanks! (i only with the filtered portal would display accurate summary information)
any additional thoughts on constraining the user to click "ok" or "cancel" before allowing them to navigate away or close winow would still be much appreciated. it's not life or death in this particular situation, but it is a technique i would like to learn. thanks again.
Instead of "marking" records--which is dangerous as well as slow in networked solutions. Build a list of the ID's in a variable or global field if you must do so. (Sometimes you can use alternative approaches.) A calcultion can then use FilterValues to check and see if the current record's ID is listed in the list.
With regards to the two portals, it can depend on the data being searched. If you are searching for a person, entering the first few letters of a person's last name will produce a smaller number of matches than the "contains" logic of the other portal and this can be desirable. It's even possible to set up a single portal that uses both filter methods with a control added to the layout where the user picks the search method they want to use...
i can see how marking the records could be dangerous... i never really considered that aspect of it. i am interested in trying to implement the other method you described about building a list of id's in a global field but i don't really understand what you mean. how would i build it, what would it contain exactly, and how would it be used to search or filter the portal? sorry, this is all a little beyond my skill set!
"the parsed out match field in the projects portal, for example, cannot be a calculation field". - It can, as long as the calculation can be indexed. For example, on one side of the relationship is a global field, SearchText. On the other side is a calculation field derived from ProjectName and/or InvoiceNumber, for example:
Left ( ProjectName ; 1 ) & "¶" &
Left ( ProjectName ; 2 ) & "¶" &
Left ( ProjectName ; 3 ) & "¶" &
Left ( ProjectName ; 4 ) & "¶" &
Left ( InvoiceNumber ; 1 ) & "¶" &
Left ( InvoiceNumber ; 2 ) & "¶" &
Left ( InvoiceNumber ; 3 ) & "¶" &
As the user types in an increasing number of characters to match it narrows down the portal. (And yes, it needs a ScriptTrigger to make it work seamlessly.)
"I still don't understand how the pause/resume will function properly as you are suggesting because it gets triggered as soon as the user hits enter " - You are absolutely right. I was simply answering your assertion that the script step only works as a pause. I pointed out that the Enter working against you (to trigger the resumption of the script) was one of the sources of your problems.
Keep life simple. The Rest Of The World will inroduce more than enough complications. That's my philsophy, anyway.
ahhhh... i get it... that's clever. thanks sorbsbuster. and i learned something about calculation fields and relationships! 2 quick questions:
1. suppose that the first 2 characters, for example, in the project name happen to be the same as the first 2 characters in the project number... do you know if it displays the record twice in the portal or adds it twice in any summary fields like the sum of related invoices?
2. with indexing on for this field, will it update if the referenced fields are modified or do you have to force them to re-evaluate somehow?
Each portal row is one matching record, so even if you wanted to you couldn't get the same record to appear twice.
You shouldn't have to force any recalculations of the matching field. Though if you are using the fields in a match it is a *wee* bit of a worry that you would be changing them. (I recognise that ProjectName is a million miles from being ProjectID, but InvoiceNumber...?)
uh oh... now i am confused again. if i don't need to be worried about updating the calculation field (assuming that the reason for this is because it updates itself automatically as the referenced fields are modified), then what is the source of the "wee" bit of worry?
If the two of you were to look at the demo file, you'll find that you can match by starting letters like this without using a calculation field at all, which in turn avoides the inherent limitation (I used to do it this way also, before filtered portals were available), of only matching to the number of letters you build in to this multi-value calculation.
thanks philmodjunk... i definitely noticed that about your demo file... i was just thinking the calculation field method might come in handy in a situation where i wanted summary totals to accurate reflect the records that were displayed in the portal... at least my understanding is that the filtered portal method will still yield summary results based on the overall relationship regardless of what records are displayed as a result of the filter?
If you place a summary field from the portal table inside the filtered portal, it will reflect the current filter settings and only summarize the visible records. Sometimes it works to add a second one row portal with the same filter expression to use for displaying a portal total.