format into string bug

[shoneill]

I've run into some unexpected (for me that is) behaviour of the scan into string function.

I'm implementing a text-script based approach to firing a custom sequence of a state machine.  I thought it would be good to define macros within the script to allow frequently used steps to be more efficiently used.

The parsing itself works fine, and I solved my problem by using Format into string.  I then implemented Macros which accept arguments (up to 6) which are then converted using the macro string as a Format specifier and the 6 elements input.  If I only reference one item of the 6 inputs, everything works fine.  As soon as NONE are referenced, not only does no concatenation take place, but the entire result string is empty......  This actually surprised me a bit.  Shouldn't the function behave as a "Concatenate" if there are no format specifiers listed?

I'm not inclined to call this a bug without hearing other's opinions on it.

Here's a small VI to illustrate.  Running with default values is fine, but as soon as the %1$s and %2$s format specifiers are removed, the entire output string is deleted!  I would understand a concatenate with an error out, but deleting the string?  Isn't that a bit much?

Am I expecting too much here?

Shane.

Oops, LV 8.2.1 BTW.....


Message Edited by shoneill on 11-20-2007 10:47 PM

[RavensFan]

Here's what I see:

Remove both string specifiers, but leave in the rest of the format string.  No output, an error 83 about too few format specifiers.

Make the entire format string empty, you do get the start string with all the strings concatenated to the end, and no error.

Make the entire format string nothing but 6 %s 's, you get the start string and the concatenation, no error.

Only put in 5 %s 's, no output, you get error 83

Put in 7 %s 's, no output, you get error 84 about too many format specifiers.

So I don't think this is a bug.  I think if you do the %1$s in there, it knows you are dealing with reordered or selected strings and handles them accordingly.

If there is nothing there, you get the concatenation.

If you use text in there, it expects things to be in the %s format and wants there to be the exact number of %s 's as there are inputs.

So if it sees text and sees a %1$s, it knows how to handle it.  Text without the %1$s format, it reverts to thinking of the %s format and wants there to be the correct amount of them.

If you mix %#$s and %s, the subsequent %s 's will be the values that follow what ever the %#$s index was.  so %2$s %s %5$s would be TWO THREE FIVE.  But a %5$s %s %s raises an error becasue it would be FIVE SIX then the non-existent SEVEN.

I don't know if this help explains things, but playing around with different variations of the format string helped show how it behaved.

[shoneill]

Ravens Fan,

Thanks for taking the time to have a look.

I hadn't looked at the differences between %1$s and %s, so I missed what you have now filled me in on.

It makes a bit more sense now.  %s is the default, and this produces errors when input number and specifier number are different.

I'm thinking I could define a dummy specifier and a dummy input %7$ and "" to allow me to get away with what I want......

I'm still not sure about the return value being an empty string when the errors occur though.  For me, it should just do a concatenation and give the error.  The function takes an "Initial string" input.  Why should this be deleted by an error in the format function?  Note also that these errors can only occur if we're feeding a control to the Format specifier.  Feeding a constant checks the errors at compile-time.

Here's my hacked version....

Shane.

[RavensFan]

---

I'm thinking I could define a dummy specifier and a dummy input %7$ and "" to allow me to get away with what I want......

---

That look's like it works.  Yes it's a hack, but if it does the job .....

---

I'm still not sure about the return value being an empty string when the errors occur though.  For me, it should just do a concatenation and give the error.  The function takes an "Initial string" input.  Why should this be deleted by an error in the format function?  Note also that these errors can only occur if we're feeding a control to the Format specifier.  Feeding a constant checks the errors at compile-time.

---

It probably should feed what it can through, i.e. the initial string.  I guess it is one of those functions where if you fed an error in, nothing gets executed.  And in this case, the error is generated inside, and probably checks for the error and executes nothing after that.  In other words, the passing through of the initial string would occur after the internal error check and does not get executed if there is an error.

The fact that an invalid constant broke the run arrow is interesting, but makes sense.  But since the constant is well "constant", the compiler is immediately able to check and tell you its invalid.

I'm glad to see you found a way around this issue.

[McTOM]

How about this: I am building a xml-ish parser and wanted to format into string: "<\%s>". It won't work, neither if I type it by hand, nor if I use string builder. It gives you broken arrow since the whole thing is treated as exact output string and hence there is an excessive input.

Mind you, the "<%s>" format string seems to run normally.

I use LabVIEW 2011 SP1.

[dkfire]

Have you tried with: <\\%s> ?

One \ cancel the %s as a formater, then two \ will give you a \ to print out.

[altenbach]

When adding to a 6 year old thread, it might help if you give a bit more detail and also attach a simplified VI that shows the problem.

Thanks.

[pincpanter]

Use <\\%s>

[McTOM]

It seems to work, thank you for your support.

Despite my problem is solved, I'd expect from the string editor to do that for me, just as it does with "%" character. 

[altenbach]

What is the "string editor"?

Both versions are valid statements, how is the computer supposed to guess what you want?