06-25-2009 08:19 AM
In the (relatively) new multilingual world of CVI I'm trying to update some of my older applications so that they work correctly in CVI 9.0.1. For many of them, I have to change the character set used by most of the panels and controls from 'Native' (VAL_NATIVE_CHARSET) to 'Western' (VAL_ANSI_CHARSET).
No problem (so I thought) - just export the UIR file to a .TUI file, do a global search-and-replace to change all the character set attributes, then re-import.
Except it doesn't work. Some attributes are correctly changed to 'Western', but others (e.g. the labels on checkboxes and the text of a string control) stay resolutely 'Native'.
I can change these all manually within the UIR editor, but with several thousand attributes to change overall I'm not relishing the idea.
Is this problem known about? Is there a (reasonable) workaround? How does the SetPanelCharacterSet() function interact with the individual character set attributes for controls (if at all)? Unfortunately, the CVI help doesn't seem very detailed in its explanation of character set attributes, unless I'm missing something.
06-26-2009 03:05 AM
Whilst investigating this further, I noticed that the axis labels on graphs do not appear to respect the character set setting - is this a bug?
Attached is a small .tui file that doesn't import correctly.
06-26-2009 05:47 PM
Hi Martin,
The reason this .tui is not importing correctly is because it is internally inconsistent. The font in the .tui is VAL_DIALOG_META_FONT, which is a predefined metafont (metafonts contain not only typeface information but also values for all other font attributes: point size, italics, angle, character set, etc...). Typically, controls have VAL_DIALOG_META_FONT as their default font, but when you change one of the other attributes, such as the character set, for example), you are implicitly telling the control that it should no loger use this metafont. As a matter of fact you can see this in the UI editor, as you edit one of the fonts in the font dialog. As you change one of the other controls, you should notice "NIDialogMetaFont" turn into "NIDialog".
The problem you had is that when you edited the .tui directly, you changed the character set from its default value, but you also left the font set to the meta font, which causes it to supersede all other settings when you load the control. If you had also changed the font to VAL_DIALOG_FONT, then it should have loaded correctly.
I haven't looked into the graph labels issue yet, but I will soon, and I'll post what I find.
One thing I did want to ask you, though: in your first post you wrote that you had to convert all your character sets to Western so that they would work in 9.0.1. Is this a situation where your application used to work differently than it does? with 9.0.1? Because that's definitely unexpected. In CVI 8.5, even though you couldn't change the character sets, they all behaved as if they were native. Which means that when you change to 9.0.1, they should have continued working the same way without you having to change them.
Luis
06-28-2009 07:48 AM
Luis:
There's not a lot of information about the use of fonts (especially in the context of MBCS) in the CVI documentation - I wonder if it would be possible to produce a white paper describing how fonts are and should be used? I, for one, have always been confused about the difference between e.g. NIDialog and NIDialogMetaFont and with the introduction of different character sets it is not getting any easier.
Regarding the version issue, our particular 'problem' is that this year our products have begun to sell in Japan and China, so we are coming across issues that we have never previously had to consider - particularly challenging for an old fogey like me, brought up on Hollerith cards and Teletypes
06-28-2009 03:49 PM
Hi Martin,
There is a white paper on multibyte programming that you might find helpful, in case you haven't run into it yet:
C:\Program Files\National Instruments\CVI90\bin\multibyteprogramming.pdf
(It's also linked to from the Guide to Documentation topic in the online help). It doesn't really address fonts, specifically, but it does discuss some of the issues involved when programming for multibyte character sets.
As far as fonts vs. meta fonts, there is this help topic:
Library Reference>>User Interface Library>>Overview>>Common User Interface Objects>>Using Fonts
I realize it's not very thorough, but if you have any specific questions concerning this topic that are not answered, please do let me know, and I'll do my best to answer them and to add to this topic, if needed.
By the way, I've since tried using non-native character sets with graph axis labels, and it seems to work for me. I'm attaching a screenshot to make sure that we're talking about the right thing. In what way is it failing for you?
06-29-2009 08:11 AM
Luis:
See the attached files. This panel has a graph and a text message control. The left y-axis label, bottom x-axis label and text message are all set to NIDialog font in Shift JIS character set and contain the same text string. Yet the text message displays differently to the graph labels.
06-29-2009 12:06 PM
I think I know what the problem is. Whereas you've changed the axis labels font to ShiftJIS, the axis names font is still set to Native.
The axis labels fonts refer to the fonts used to draw the label markers (0, 20, 40...) of each axis. Each axis has its own label font. Normally these are numeric values, so changing the character set of these is probably not very useful. This is why in the image that I attached earlier, I had used an axis label string, because that's what I thought you were referring to.
The axis name font, on the other hand, refers to font used to draw the names of each axis. You set this font globally, for the entire graph, by clicking on the "Axis Names" button in the main dialog.
And yes, I do acknowledge that this confusion is entirely understandable, since it's perfectly reasonable to also think of these axis names as labels. In retrospect I wish we had used "markers" and "labels" in the very beginning, rather than "labels" and "names". But this terminology goes back to the dark ages of LabWindows for DOS, and each step of the way it probably would have caused just as much confusion to change it, given that a number of users were already used to the existing terminology.
Luis
06-30-2009 10:39 AM - edited 06-30-2009 10:40 AM
Luis:
OK, I'm gradually getting there. Be nice though if the font setting for axis names were available in the Axis Settings dialog, where the name itself is specified.
Some last questions:
07-01-2009 02:50 PM
Hi Martin,
I agree that it would be nicer if the axis name fonts could be set in the same dialog as the names themselves. The reason they can't is because each axis has its own name, whereas the name font is common to all axes. Therefore, it has to be set in the graph properties dialog and not in the individual axis properties dialog.
1. That is indeed a minor bug, one that we had found and fixed back in March, but that did not make it onto the 9.0.1 maintenance release (we try to include only significant bugs in maintenance releases so as to reduce the additional risk that large number of small changes always imply). The bug has to do with the fact that when you change the character set in the font selection dialog and if, as a result of this change, the font name becomes something else (in this case, @Arial Unicode MS), this change in the font dialog is not recognized in the dialog. As a result the font in the control remains as Arial. Later on, when you invoke the dialog a second time, "Arial" cannot be found in the font typeface ring (which is filtered by character set), and this results in the "not found" designation.
A simple workaround would be to make some spurious additional change in the font name ring, to spur the dialog into the realization that the font did change.
Note that this bug has no impact on what font is actually used for drawing the text, since the underlying font mapping algorithm will try to reconcile the fact that "Arial" and "ShiftJIS" are not available in the same font, and will then use the closest approximation, which happens to be @Arial Unicode MS.
2. I can't yet explain the behavior you're seeing. I tried to change the language in my English-language PC to Japanese to see what would happen, but I wasn't able to: Japanese was not listed as a choice (see attached screenshot). It seemed to not have any multibyte character set at all. You are referring to an English PC, correct?
Luis
07-02-2009 03:37 AM
Luis:
Yes, it's an English PC, but support for Japanese isn't installed by default. You have to check the 'Install files for East Asian languages' checkbox on the Languages tab of the Regional and Language Options applet to get it.