08-28-2009 10:25 AM
Great point I never thought about the localization issue. I had to write an application to support 5 languages before and found localization non-trivial.
08-28-2009 03:29 PM
I've been using the disabled property in my current applications, and now that you point it out I guess the enum wasn't in previous versions. I like it. I always try to use enums and text rings in my applications as oppose to ambiguous numeric entries when appropriate.
As for block diagram realestate, here is a good solution: ask your boss for a larger and higher resolution monitor. Problem solved...for now...
08-29-2009 12:34 AM
IMHO, the enums need not be localized... Do they?
I mean printf remains printf in any human language.
But yeah considering that even the VI labels are localized this may seem out of place. How about pict enums? Essentially showing what they do, just like color box? or perhaps just have shortened symbols universally for all languages... oops... i think this should go into the idea market...
08-30-2009 02:40 AM
falkpl wrote:Great point I never thought about the localization issue. I had to write an application to support 5 languages before and found localization non-trivial.
I find this quite an understatement. For me multi-language apps do more seem like a pain in the a** than anything else. I still do them sometimes as customer demand it, but I do calculate some extra time for the issues that causes.
Rolf Kalbermatter
08-30-2009 07:43 PM
The learning experience for me in multilingual development is to minimize the text shown to the user, uther than that, Yes a royal pain. I would not like to try to support a development environment with multilingual localization and can see how this could weigh in the decision to minimize enumerated type use.
08-31-2009 07:46 AM
The major problem with localizing an enum is that its datatype changes when you do this. Case statements and comparisons stop working. So you cannot blindly change the text of an enum when converting from one language to another. Rings, on the other hand, are fair game, but you lose the whole advantage of enums.
Of course, this is all a moot point unless you are sharing code across language boundaries (and we never do that ). So, for developers in a single company who are not developing in multiple languages, it is not an issue. For a company, like National Instruments, which needs to write code which can be localized at the code level, enums are a problem. As a corrolary, you should never use an enum in a GUI if you plan to localize the GUI. Use a ring on the GUI and convert it to an enum.
09-02-2009 10:38 AM
NitinD wrote:
But yeah considering that even the VI labels are localized this may seem out of place. How about pict enums? Essentially showing what they do, just like color box? or perhaps just have shortened symbols universally for all languages... oops... i think this should go into the idea market...
Although the idea seems appealing (as does the use of these enums), won't this just contribute to further code bloat. Personally, it doesn't seem that difficult to me to use the help function and hover over the property you are trying to access to determine whether you want 0,1 or 2.
09-02-2009 10:46 AM
09-02-2009 10:51 AM
mtat76 wrote:
Although the idea seems appealing (as does the use of these enums), won't this just contribute to further code bloat. Personally, it doesn't seem that difficult to me to use the help function and hover over the property you are trying to access to determine whether you want 0,1 or 2.
I agree with you mtat76. It is a code bloat. Probably you'll get used to the values if you keep using them often. But when you're new to it, the 0,1 and 2 just glare at you and confuse you. Yes, context help is very useful in such a case. But still, there is no harm in making the life of beginners easier.
Trying to emphasize on what I'm trying to say, since anyways we have the whole text coming up in 2009, I think its good to have symbols instead of such a large amounts of text. Kind of trying to balance between what beginners want (clarity) and what experts want (less clutter).