[v1.7.2.1] Repeat and execute by name prefix/suffix commands don't execute fully

[Pfeil]

I encountered this issue in v1.7.2 with repeat phrases, and now the "Execute Another Command" action since it also supports prefix/suffix commands.

I didn't post this earlier because I tried narrowing down the exact condition in which this occurs, as the command is relatively complex(it's fairly old, if I were to redo this I'd probably do most of it in the inline function instead).


From what I can tell, when VoiceAttack encounters the first condition block in the suffix, it actually jumps back into the prefix without executing the rest of the suffix(removing the first block had it executing up to the second instead).

Again, despite the odd execution order, the command works fine when executed normally, but when using repeat phrases or the "Execute Another Command" action, it fails.

Other commands, even ones that jump back and forth like this, do repeat or execute by name just fine, which is why I'm having trouble narrowing down the cause.


Commands are attached.


EDIT: Fixed in v1.7.2.11

[Gary]

I think I've got this one wrapped up.  Thanks for the example, as that helped a lot.  Will have a release soon

Edit - I put a current build out there for Blackjack to try out in the unofficial bin: http://www.voiceattack.com/unofficial if you want to get what's done so far (and not wait til beta).

[Pfeil]

I tested the unofficial release, which runs the command as 1.7.2.1 did, but now also when repeating or executing by name.


That is to say, in v1.7.2.1 the command actually breaks:

The correct output for a folder with two sounds, on the third execution of the command is

Keeping 1/2 sounds = "/1/"

In v1.7.2.1 and v1.7.2.2, however, this output is

Keeping 150/2 sounds = "/1//2/"

", and no sound plays on subsequent executions(in fact the commands keep running in the background).

This happens because in v1.7.2

Code: [Select]

Write [Blue] '{EXP: 2 * 0.75}' to logreturns "1,5", whereas in v1.7.2.1 onward it instead returns "150".

Code: [Select]

Write [Blue] '{EXP: 2 * 0.75}' to logreturns an expression error in both versions, as you'd expect.

[Gary]

So, if I revert the parse to what was in 1.7.2, it works correctly?  If that is the case, I will revert, as that's probably the reason it was that way in the first place.  Have we been down this rabbit hole before?

Edit - Uploaded v1.7.2.3 which puts {EXP} back to what was in v1.7.2.

[Pfeil]

So, if I revert the parse to what was in 1.7.2, it works correctly?

I believe it should, yes.

It's probably what's happening in BlackJack 's topic as well.

Have we been down this rabbit hole before?

I know there's a longstanding issue with decimals that means neither decimal separator works when using the "Convert Text/Token" option.

E.G. "1.5" and "1,5" both result in the decimal value set to "15".

Perhaps it's that you're thinking of?

[Gary]

I know there's a longstanding issue with decimals that means neither decimal separator works when using the "Convert Text/Token" option.

E.G. "1.5" and "1,5" both result in the decimal value set to "15".

Maybe...

As a quick test, I've uploaded yet another unofficial:  http://www.voiceattack.com/unofficial with the decimal convert text/token reverted to a previous version as well.  Would you give that a whirl on your system for me and see if that changes anything?

[Pfeil]

Both "{EXP:}" and decimal text conversion handle decimal points fine in v1.7.2.4


I will note, as the output of tokens is still locale-dependent, chaining them together requires explicitly replacing the decimal separator.

E.G.

Code: [Select]

Set decimal [dec] value to the converted value of 0.15
Write [Blue] '{EXP: {TXTREPLACEVAR:"{DEC:dec}":",":"."} * 0.75}' to log

Would it be better to have the math work by default and have the tokens always return "." as the decimal separator?
There'd still be the option of using "{TXTREPLACEVAR:}" for display purposes, instead of every time you want to insert a non-integer value.

That said, it may break things, E.G. The command I posted actually uses the "," to check if the number is integer, so it wouldn't work if the output used "." instead.
In my case it can be changed easily, but if it's a bigger issue for larger profiles somehow, perhaps a "Use locale-based decimal separator" option could be a(non-futureproof) workaround.


I didn't get back to you earlier because I was waiting for the new beta to post, I even downloaded the installer, not realizing it was an unofficial instead

In my defense, I was about to go to bed