Use a Dictionary(Of String, String)
to store your values, not a set of disconnected variables.
Then you can access the value without breaking into data contexts (which btw is possible to access, but it’s extremely brittle to make your implementation rely on that).
So your code could look like this:
// Somewhere in the code
Dictionary(Of String, String) valuesToType = new Dictionary(Of String, String)()
valuesToType("aForm585") = "bar" // instead of aForm585 = "bar"
valuesToType("aForm20") = "baz" // instead of aForm20 = "baz"
...
// The looping part
DataTable someDT = ReadRange(...)
foreach fieldPairToCheck in someDT
If (GetText(selector: fieldPairToCheck("Selector Number")) = fieldPairToCheck("Form Number")
Then SetText(selector: fieldPairToCheck("Selector Input"), value: valuesToType(fieldPairToCheck("Variable")))
Sidenote - I’d change the headers of that table (and a little bit column order).
In current state they don’t tell what they represent and without your paragraph of explanation wouldn’t make sense.
Form Number = 585, 20, 586 etc.
One could get out of that that “Form” is something in the app the robot is working on, and the number is the value of that something.
But:
Selector Number = (some selectors)
Now the first part describes the value, second part describes something in the app (?)
But:
Selector Input
First part is the value, second is something in the app (?)
And Variable doesn’t fir that naming scheme at all.
So the first one is the most inconsistent, but if you switch it around to “Number Form” it doesn’t make much sense either (unless you already know what it represents).
Consider: how could you name them so that your data structure has meaning on it’s own?
If you’d rename/reorder them to something like (I’ll write in the order I’d put them):
Selector Number → FieldToCheckSelector
Form Number → FieldToCheckExpectedValue (or ValueToCheckAgainst ?)
Selector Input → FieldToWriteToSelector
Variable → ValueToWriteKey
You could reason about the data structure on it’s own. Only thing doubtful now is if the value should be written if it matches or not matches, but that could be solved as well.
And even if that’s not solved, if you’ll just have that Excel, you can infere from just the headers:
Robot gets value from FieldToCheck by a selector and checks it’s value and then if (match or not match) writes to second field (which is actually in the next column in the same row, so this could be generalized further) a value that it identifies by a key.
Just from the data structure alone.
Then above pseudo-code becomes:
If (GetText(selector: fieldPairToCheck("FieldToCheckSelector")) = fieldPairToCheck("FieldToCheckExpectedValue ")
Then SetText(selector: fieldPairToCheck("FieldToWriteToSelector"), value: valuesToType(fieldPairToCheck("ValueToWriteKey")))
Which, on it’s own, gives exactly the same message as the data structure in the Excel.
As a side-bonus - if you look at the code and the input structure, you now have an almost-generic workflow to write values from a dictionary, if some other field has expected value.
This could be worked upon further to pass a comparison bool as well (so it could write on match or not match, which could also be stored in the Excel), as well as some other variants (depending on needs).
Which could easily end up allowing an external rule set to exist in that file, as the data structure would naturally read as:
(if) FieldToCheck.Value.CompareTo(ExpectedValue) = MyPredicateBool (then) FieldToWriteTo.Value = ValueToWriteKey // or just ValueToWrite
As Fred Brooks said (and assuming fields are named descriptively):
Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.