OS language settings break CVI code

[nickb]

Hello -

This actually turns out to be a pretty devious little problem...

When I examine your format string with the memory display (I copied it into a much smaller program), I can see that the space that preceeds the '%d' is actually ASCII character 160, a non-breaking space:

This character is rendered exactly the same as a space with most fonts, so there's no way to know that the character being printed is not an ASCII code 32 space.  The problem with this is that as soon as you change to a multibyte code page, that non-breaking space is interpreted as a lead byte and the '%' in your format string is swallowed up as a trail byte.  This is what causes the run-time breakage when the locale is changed.  The CVI runtime is just being diligent to interpret your format string exactly as you typed it, and has no idea that non-breaking space should actually be a space.

My guess is that some of this code was copied and pasted from a webpage, where non-breaking spaces are used often.  There's no easy way for you to know whether you're copying code 32 spaces or code 160 spaces, and so you end up with these type of problems. 

Fortunately, you can do a find and replace on that space, replacing the code 160 spaces with code 32 spaces, and you won't see this problem any longer.

Let me know if you have any questions about this,

NickB

National Instruments

[icastillejos]

Hi Nick,

This actually does solve our problem, I replaced all 160 spaces with the 32 spaces and CVI was happy. Dll's do not mutate so I think we'll be able to use the chinese messages in LabVIEW and TestStand, it will take some time to double check all our drivers but having localized operator instructions is definitely worth it.

It would be great if you guys could add a KB about this issue,  it would save other users and AE a lot of time and headaches. Also, would it be a lot to ask if you guys could open a CAR for CVI to be able display multiple encodings, this would give developers visibility on the original code even with different language settings... which is probably the majority of users or at least where things in many organizations are heading to. Please let me know if you are not able to do this so I can forward this through my sales rep.

Thanks a lot for your support!

<<-N->>

[LuisG]

Hi,

The ability to display multiple encondings in the CVI source window is a good idea, and I definitely encourage you submit it in the Idea Exchange, so that others can add their feedback and support it. Doing so will increase the likelihood that it be implemented in a future version.

Creating a CAR for this issue isn't really appropriate, since this is a feature request, not a bug. CARs are intended to correct bugs.

Also, note that even if the ability to display multiple encondings in the source window existed today, it would not have avoided the binary incompatibility that you ran into. It actually would have been worse, since you would not be seeing the chinese character in your code, and consequently the problem would have been more hidden than it was. Even though you wouldn't see the 160 character displayed as a lead byte in your code, at runtime the sprintf function would still interpreting that character as a lead byte (since the global locale of the OS is Chinese) and the % character would still be ignored, thus causing the format string to not be processed correctly. This is correct behavior for the sprintf function, even though it was not the desired behavior for your particular application.

Luis

[icastillejos]

Hi Luis,

Finally got my entire project’s CVI drivers fixed and my TestStand solution up and running. Two things:

The product:

I understand the technical details of the function and the way CVI handles files. Even if CVI had the ability to convert these particular character from extended to ascii it would be really hard to know when to make this change in the source code. This is just wishful thinking but maybe there is something to be done (no idea what) about the binaries, I can only imagine what would happen if I didn’t have the source code….

Anyway, it’d be interesting to research how other NI products handle this space situation so the Developer Suite is consistent and behaves the same way everywhere.

The Process:

I’m a firm believer in Agile methodologies and user involvement in the software lifecycle process and I think I’m a pretty active participant in my NI users community. On the other hand I also think that these practices taken to the extreme tend to disengage stakeholders from the process.

I think we both agree that this idea would make CVI a better product and would make NI’s customers happier. By doing all this investigation and reporting the issues I’m having I'm considering my feature request submitted. If you guys want to be proactive and decide to create a KB and track the request, fix the issues/improve the product that’d be great. If you decide to do nothing about it and wait until someone external to NI takes ownership of  the tracking process that’s ok with me too, but I can assure you that more customers are going to run into this issue in the future (more support calls, research time and frustration).

In summary, the way I perceive this as a customer is: I’m paying for a product (Dev Suite), a service (Support) so I can get my job done… tracking improvements in the tools I use to get my job done looks like a hidden cost (engineering time) that I might not be willing to pay. Something to think about…

My 2 cents

<<- N ->>

"Any ideas or opinions expressed here do not necessarily reflect the ideas or opinions of my employer."