If you had a table of increments (your 10, 20, 30, etc.) and related to that table where your initial value is < that increment, you could use that as a value list.
The downside is that if you want the value list to change while the user is still on the record, you may need to commit and refresh (with a script trigger).
I think I understand what you want & am happy to tell you there are definitely alternatives to doing this longhand. Are the pictures below similar to what you are looking for?
I enter 77 in the NumberField and have the option to pick only 80, 90 or 100.
Next, I have a new entry in the NumberField where I enter 11 and am allowed only to pick 20, 30, 40, 50, 60, 70, 80, 90 or 100.
If that looks like what you are after, attached is the file from which those screenshots were taken for you to try out if you like.
The way I control what values appear in the ValueList takes place in the creation of the Value List as shown below:
ValueList.fmp12.zip 65.5 K
For my case, there will be 15 fields within one record that will be using the value list. In your solution, I would have to create the 15 relationships and that is not ideal. I want to avoid creating the static table of values.
You could use Script triggers on the 15 fields to update a global field. Use that global field on the left side of the relationship.
But it would be more work than 15 TOs on the relationship graph.
I was just about to upload an example of this technique as a compromise: static table of values with a dynamic filter.
In the attached, each of the NumberFields triggers a script to set the zg_GlobalFilter. So entering "1" in the 1st NumberField yields:
ValueList.fmp12.zip 67.9 K
Thanks dmp_fmp! That is a great alternative. Thanks for the help!
Thanks Daniele! This is along the same lines as the back up alternative I had in mind. For usability, the dynamic list is a more ideal.
I had also considered creating a button that incremented the field by 10 at a time, but I believe the users would prefer the list.
Appreciate the suggestion!
Could you please check this option?... I know is too late for this answer but the chalenge is so interesting.
Maybe the method is too complicated or not the right one for your needs, but at least it does exactly what you want (i think)
valuelist.fmp12.zip 8.8 K
Maybe the method is too complicated
Only it's execution …
Better use variables instead of otherwise unnecessary fields …
If [$$objectName = Get ( ActiveLayoutObjectName )]
Set Variable [$$objectName; Value:""]
Set Variable [$$objectName; Value: Get ( ActiveLayoutObjectName )]
Set Field [MyTable::gFilter; Max ( 1 ; Get ( ActiveFieldContents ) ) // if field was empty ]
Commit Records/Requests 
Go to Object [Object Name: $$objectName]
… requires just one additional field – the matchfield for the value lookup.
And – more importantly – you need to cater for an empty entry field, because the relationship doesn't work with an empty match field …
This method is not too complicated at all and I am always up for alternate solutions to the problem. There is a small issue with the solution you have provided. You must click the field, exit and reenter in order for the correct values to be displayed, otherwise it will display the values of the previous field clicked, if I can get that to work better, I will implement it in this way.
Thanks for the help!
Looks like the script is not working for you... the task of the script is to exit an go back to refresh te value list and prevent that "small issue" .
Now, in the other hand erolst is 100% right, the use of globald fields to be used as memory is unnecesary .... sorry those are bad programming habits that i need to erase from my notebook