cannot display square root symbol in cvi

[CVIBri]

I don't understand why this would be an issue, but if I'm writing in the source window (with the default font of NIEditor), I cannot display a square root symbol "√" - every time I type alt+251, I get "v". Ok, not a huge deal in the source window, but it is a big deal if THAT is what's being stored in a string variable I'm writing out to a file. Additionally, if I use the following to format a string:

"Fmt(setpointUOM, "%s<W%cT/P3", 251);", then setpointUOM = "WüT/P3". If I display this variable in a string control, it displays as "W√T/P3", which is correct, but if I use it in a Text Box or save it to a sql database, it displays "WüT/P3" which is unacceptable.

I've tried changing the fonts but nothing works or I get even stranger results. I've been dealing with/ignoring this since CVI7 and I'm currently at CVI10. Thanks for any help.

[LuisG]

The difference in the display between W√T/P3 and WüT/P3 has to do with the character set that you select for the UI control. From what I can tell, only the OEM code pages map the √ symbol to character 251, so if you want to see √ for that character, you should pick the OEM character set, in that control.

Entering √ with the keyboard in a CVI window seems like a much more problematic task. When you type Alt+251 on a CVI window, the keyboard driver is converting the 251 to 118 (the letter v). I don't know why it does that, but I noticed that the code that it converts 251 to varies, depending on your input language (which you can change in Control Panel>>Region and Language>>Change keyboards or other input methods). When english is selected in the language bar, it converts it to 118. With other languages, it converts it to other codes. I tried entering the unicode value for √ directly, which is Alt+221A (to enter unicode characters using the keypad, you have to follow the steps described here). But it didn't work. It still converted it to 118. I suspect the keyboard driver is doing this because it tries to map 221A to some symbol that is valid in the code page that corresponds to the input language, isn't able to, and picks what it thinks is the closest match.

In lots of other applications (but not all) you can type Alt+251 or Alt+221A and it works just fine. This is because those applications accept unicode characters directly. Unfortunately, CVI isn't one of them. It uses code pages (a.k.a. character sets, or multibyte sequences) instead of unicode, and symbols don't have a universal meaning; they depend on the code page.

Even if all this were not an impediment, you'd still run into the problem that in CVI 2010 you cannot change the font of the CVI source window to use an OEM character set. So, you'd still see it displayed as a v or a ü. In CVI 2012 you can change the change it, and so if you were using CVI 2012 you could conceivably use the clipboard to paste the √, but there is a bug in CVI that is preventing OEM characters from being pasted correctly (I realize the description says that it affects tree tooltips, but it's also generally affecting clipboard operations of some less commonly used character sets).

So, to make a long story short, I think you should continue entering the code directly with the Fmt function, at least until this bug is fixed. And make sure that all UI controls that need to display this string are using the OEM character set.

Luis

[Wolfgang]

Following the explanation of Luis you should also consider promoting the request for Unicode character support in CVI....

This proposal can be found here : give a Kudo to it to make its visibility and importance higher, right now it's well below average...

[msaxon]

---

LuisG wrote:

Entering √ with the keyboard in a CVI window seems like a much more problematic task.

---

Alt+0251 works, if you have the right character set. Don't ask me why you need the 0

[LuisG]

Wow, you're right, it works! That's good news, and it means that starting with CVI 2012 you can actually enter and display the √ symbol in the source window.

I'm still a bit confused about why it works, though. All the references I've seen say that when using the leading 0, the code is interpreted relative to one of the Windows code pages (Windows-1252 for English). But this code page uses û for 251, so I'm not sure how it works.

Interestingly enough, when I type Alt+-0251 in Notepad, for example, I get û (which makes sense, given what I've read), and when I type Alt+251 I get √ (which also makes sense). But in a non-Unicode app, I actually need to enter Alt+0251 to get √, and even that will be displayed as û if I'm not using the OEM character set (OEM-437, for English).

Luis

[CVIBri]

I appreciate all the input (and sorry for my slow repy), and whereas it sounds like 2012 may have a solution for the source window, I'm not ready to update to 2012 yet. So using the Fmt function seems to be my only way to display the √ symbol, however, I cannot display it in a Text Box control or save it to a database (or file). Forgive me if this is ignorant on my part, but I have no idea what the OEM character set is for CVI 2010 nor do I know how to change it. (I google'd about it but that just gave me some background info and no way to adjust it) I've changed to just about every available font that the control offers, but still no luck. Please advise ... 

[LuisG · Accepted solution]

You need to change the character set of the text box, not the typeface, to use the OEM character set. Here's some code that does this programmatically:

panel = NewPanel (0, "", 100, 100, 100, 100);
textbox = NewCtrl (panel, CTRL_TEXT_BOX_LS, "", 10, 10);
SetCtrlVal (panel, textbox, "√");
SetCtrlAttribute (panel, textbox, ATTR_TEXT_CHARACTER_SET, VAL_OEM_CHARSET);
DisplayPanel (panel);

If you load the textbox from a .uir file, you can also change it in the UI Editor instead:

 

[CVIBri]

Thank you Luis! I appreciate the education, and now I know how to resolve this issue with any control. However, the problem still presents itself when storing externally. I have an NI Report and a database that display 'û' for '√'.

For the NI Report, I create a table and one of the column names needs to have a label with the √ symbol. I found the following attribute to change the character set: NIR_TEXT_ATTR_FONT_CHARSET but doing so made no difference. The simplified code is below.

Fmt(colNames[0], "%s<test");
Fmt(colNames[1], "%s<W%cT/Pa", 251);

ret = NIReport_New (&reportHan);

NIReport_TableStart(reportHan, 2, 1);

for(i=0;i<2;i++){

NIReport_AppendText (reportHan, colNames[i]);

NIReport_SetTextAttribute (reportHan, NIR_TEXT_ATTR_ALIGNMENT, NIRConst_Center);
NIReport_SetTextAttribute (reportHan, NIR_TEXT_ATTR_FONT_CHARSET, NIRConst_CharsetOEM);
if(i<1)

NIReport_TableNextCell (reportHan);

}

ret = NIReport_SetReportAttribute (reportHan, NIR_ATTR_ORIENTATION, 1);
NIReport_Print(reportHan, NULL, 1);

For saving to the database, I have no idea what can be done as it seems it stores exactly what is in the string variable. Which, as I've said, if you look at the value of the variable during execution, it displays as û for √.

Please let me know your ideas.

Thank you for all the help so far.

[LuisG]

Unfortunately I don't have any concrete suggestions that could help with either of those problems.

I don't know what the database software could do to interpret the 251 as a √ character. The data itself is probably correct, so this is a font problem and a code page problem, and so it has to be handled through the database's GUI interface.

I also don't know why NI-Reports isn't printing the correct character. It could be a limitation of the printer driver, which might not have good localization support. I don't have access to the NI-Reports source at this time, so I can't see if there are any other limitations that could play a role, but from what I can tell, you're using it correctly. If you would like to test whether the character set functionality, in general, is working properly, you can try using characters specific to some other character set (Greek, for example: αβψδε) to see if that works. If it does, then the problem is probably with the printer driver, rather than with NI-Reports.

If you have Office software installed, something you can try is to test it using Word Report (see C:\Users\Public\Documents\National Instruments\CVI2010\samples\activex\word\wordrpt.prj), instead of NI-Reports. If you can generally print a √ from Microsoft Word, which I'm guessing you can, then it should also ultimately work with Word Report, although you might have to tweak it some, so that it can handle Unicode strings.

Luis