1 of 1 people found this helpful
Value lists. As far as I know there is know way to gray out a selection.
Three ideas come to mind.
Separate value lists for each layout with the previous selections removed.
Dynamic value list using a calculated field.
Show all options but use a script trigger to control the value that is actually able to be be set to the field. User gets a warning that they cannot go backwards In the process if they select it.
I would make the value list dynamic, showing only those values that are above the current one. To do that . . .
I would put all the choices in a table with another field called "Value".
Estimate = 10
Quote = 20
Order = 30
Invoice = 40
In the Transaction table, create a field called "ValueNow". In this field you want to store the value of the stage it is in. I'd do a script trigger that sets this Transaction::ValueNow to whatever the user just selected. For simplicity sake, I'd hardcode the values, but there are better ways to do it (Start with this being an auto-enter calc of 0 )
Set up a relationship from transaction to Choices table. The relationship should be Transaction::ValueNow < Choices::Value. Create a value list based on this choices table, using related values only (picking the "Choice" field to show).
This should allow you to see only those Choices which have a value that is greater than the current stage of the transaction.
Ive attached a file to so you can see this in action.
ValueList.fmp12.zip 67.2 K
Thanks a bunch, this seems to be a good approach to my problem, the attached example is also a great help!
If I ever wanted to make certain options always available throughout the entire process, how might that look? Is there a way to merge value lists, and where one of the merged lists would have the excluding properties?
Thank you, I'm going with Jeremy's answer.
However, the script trigger solution you mentioned to control the value set to the field, how might that look? I tried it myself before but I didn't get it to work the way I intended.
Pardon the question, but is there a reason you are not keeping Estimates, Quotes and Invoices in separate tables, and hence retaining all in a linked series? To my way of thinking all have their place as historical data that has its place.
Sure. You could create two value lists. One related, as I show in my example, and one showing all values. Attach each value list to a different instance of the same "status" field and hide one or the other depending on a flag.
Object 1 is Transaction::Status (with related value list)
Object 2 is Transaction::Status (with all value list)
Stack them on top of each other exactly.
You could put on your layout a "Flag Transaction" button. This would set a field (Transaction::Flag_ChangeStatus) to 1.
Now Hide each object above if a certain condition is true:
Object 1: hide if Transaction::Flag_ChangeStatus = 1
Object 2: hide if Transaction::Flag_ChangeStatus ≠ 1
When a user wants to get all the values, they press the Flag button and it sets the flag field to 1. That hides the field object with the related value list.