Thank you for your post. We have been in development of adding unicode support to LabWindows/CVI for a little while now. As it is a large feature, users should see unicode support added in the next couple of years.
Regards,
Collin Draughon
LabWindows/CVI Product Manager
National Instruments
support of Unicode character set would be most welcome
I second this wish. And actually it shouldn't be that difficult, it could even be handled more conveniently than Windows itself does it: Win9x compatibility is of no concern anymore anyway, so a switch from the -A to the -W APIs poses no problem. Now, instead of redesigning the whole CVI API to accept wide characters, stick a MultiByteToWideChar call before every UI/Text API call and convert the string according to the character set of the meta font. This is what Windows does internally for the -A APIs anyway and this way old CVI code remains 100% compatible. The only twist is that you can now allow UTF-8 as another "character set", which MultiByteToWideChar already knows how to handle, and voila, complete Unicode compatibility.
No compiler change (for wide strings), no API change, just a few adjustments to the runtime library... I mean yeah, there might be a few more details to worry about, but the important thing is that Unicode support doesn't need to be UTF-16. In my opinion UTF-8 is more convenient anyway!
Well, the idea didn't leave me alone, so I made a proof of concept. I actually patched some quick&dirty UTF-8 support right into cvirte.dll and it WORKS In less than a day. Static controls work, string controls work, tables... I even got keyboard entry working just now. Funny thing is, for Chinese the string control in my solution actually seems to work much better than with CVI's native GB2312 support!
So I suppose I'm the first person to ever have run a Unicode CVI application? Now imagine what could be done if I had the damn cvirte source code...
Of course for a real implementation quite a bit more work has to be done, like updating the UIR and text editor. This line e.g. currently looks a bit messy in my example:
But as seen in the picture it still renders nicely in the UI, Chinese characters and all. So overall Unicode support really seems more than just achievable. I hope the NI engineers take this as a challenge
In case anybody is curious, a patch to GetTextExtentPointA, ExtTextOutA, a few MBCS functions like mbsinc and a little alteration to the message loop for keyboard support was all it took.
I also would second this wish. In fact it should have already put in place. Localization requires more than a utility to augment the GUI. Message output and keyboard input must also be localized.
Thank you for your post. We have been in development of adding unicode support to LabWindows/CVI for a little while now. As it is a large feature, users should see unicode support added in the next couple of years.
Hi Wolfgang,
Thank you for your post. We have been in development of adding unicode support to LabWindows/CVI for a little while now. As it is a large feature, users should see unicode support added in the next couple of years.
Regards,
Collin Draughon
LabWindows/CVI Product Manager
National Instruments