The Assigned> function has always felt cumbersome and until today I wasn't sure why. Actually, the Assigned> function is an If> function. "If" variable has a value then do one thing "Else" do another thing. The part that's odd is that rather than performing the "If" function, Assigned> forces you to create a result variable. Of course the first thing you're going to do with that result variable is perform an "If" on it to see if its value is "TRUE" or "FALSE".
It seems to me the Assigned> function would be more concise and more elegant if it performed the "If" on it own. I'm proposing that two new parameters be added to the Assigned> function. The first new parameter would be a label or subroutine name for a true condition and the second new parameter would be the label or subroutine name for a false condition. I would see each of these parameters as optional.
Assigned>Variable_Name,result[,true_label_name[,false_label_name]]
In this usage the "result" variable might be extraneous but must remain for backward compatibility.
I also think this same revision could be made to the Ask> function, possibly others but none that come immediately to mind.
Thanks for listening,
Dick
Assigned> Enhancement Suggestion
Moderators: JRL, Dorian (MJT support)
Hi Marcus,
I would like to second this enhancement request... though I would like to see this change applied to Ask> even more than to Assigned>.
In addition to (not instead of) JRL's suggested change to these two commands... please consider adding the ability for us to test a variable to see if its assigned from within a complex expression. That should make all of the following examples possible... without any changes to the If> statement:
Comments Marcus? Anyone else?
Thanks for listening... and thanks JRL for posting this request
I would like to second this enhancement request... though I would like to see this change applied to Ask> even more than to Assigned>.
In addition to (not instead of) JRL's suggested change to these two commands... please consider adding the ability for us to test a variable to see if its assigned from within a complex expression. That should make all of the following examples possible... without any changes to the If> statement:
Code: Select all
If>{Assigned(%my_variable%)}
//lines to execute if my_variable is assigned
Else
//lines to execute if my_variable is not assigned
EndIf
Code: Select all
If>{Assigned(%my_variable%)},my_variable_is_assigned,my_variable_is_not_assigned
//any number of lines
Label>my_variable_is_assigned
//appropriate lines
Label>my_variable_is_not_assigned
//appropriate lines
Code: Select all
If>{Assigned(%my_variable%)},my_variable_is_assigned
//if we fell through to here, my_variable is not assigned
//appropriate lines
Label>my_variable_is_assigned
//appropriate lines
Thanks for listening... and thanks JRL for posting this request
jpuziano
Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post -
Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post -

Please add my vote for jpuziano's suggestion to allow Assign to test complex expressions. This ability would allow the test and set of a variable if not already defined, to be placed in an SRT for clean application.
I've just posted more information on this SRT issue at: http://www.mjtnet.com/usergroup/viewtopic.php?t=6252
I've just posted more information on this SRT issue at: http://www.mjtnet.com/usergroup/viewtopic.php?t=6252