Debug an inline function?

[DevGnoll]

OK, I have an inline function that isn't behaving. 

It behaves differently depending on whether or not this is the first time after editing it has been invoked.  It never "works" but only lets the rest of the actions in the command execute on the first run.


 Normally I would just salt the code with heaps of printf's until  I stumbled on the answer, but how do I do that?   Whatever is hanging my command is also making the Say with TTS actions not work on the second run.

So where's the console for the inline functions, and how do I reset them so they don't hang the rest of thier commands.

[Pfeil]

The WriteToLog() method outputs to the log on the main window.

If your inline function is running asynchronously ("Wait for the inline function to finish before continuing" unchecked), you'll need to restart VoiceAttack if you didn't build in a way to stop the inline function externally. Otherwise, stopping all commands can normally also stop a synchronous inline function.

That is assuming the issue is caused by the inline function running in the background.

[DevGnoll]

Thanks,  that helps a lot.   

So that  section of the manual about calls for plugins applies to inlines as well?

Some of the problem was higher-up: 

When you have an action that is a multi-condition compare, the UI doesn't tell you which type of variable (int, text, bool) you are comparing in the one-line summary on the command screen, and if the type of compare is wrong, then the variable treated as is Not Set.   Not good when you are using it to keep your inline from getting a Not Set in a variable it's going to use for an array index.
 

So, it's looking like GetText() and SetText() don't  deal with Not Set  and null the way I think they did.   (Get something Not Set and you get null, Set a null and you get Not Set)   Looks like instead the pitch an exception.  I'll try to catch that next code session.

[Pfeil]

So that  section of the manual about calls for plugins applies to inlines as well?

Yes, that documentation applies to inline functions as well as plugins, for the most part.

When you have an action that is a multi-condition compare, the UI doesn't tell you which type of variable (int, text, bool) you are comparing in the one-line summary on the command screen, and if the type of compare is wrong, then the variable treated as is Not Set.   Not good when you are using it to keep your inline from getting a Not Set in a variable it's going to use for an array index.

You would normally be aware which type of variable you are comparing, no?

VoiceAttack, like C# which it's written in, is strongly typed. When you define a variable of a given type, that is it's type.
 

So, it's looking like GetText() and SetText() don't  deal with Not Set  and null the way I think they did.   (Get something Not Set and you get null, Set a null and you get Not Set)   Looks like instead the pitch an exception.  I'll try to catch that next code session.

VoiceAttack variables are stored in a dictionary, and if the dictionary does not contain the variable name you're attempting to get the associated value for, null will be returned. In the GUI and when using tokens this is labeled as "Not set", which is likely to be clearer to must users than "null".

The proxy returns null values directly, which is why, as the documentation notes, Get and Set methods use nullable datatypes (string is nullable by definition, so it doesn't have an explicit nullable variant).

You can use the null-coalescing operator if you'd rather deal with the literal text "Not set"