Catering for the different methods could have got real messy and much harder to use the standard set of algos without it. Not only did it allow for using new algos if the user updates the binaries without having to wait for me to release a new version (they just type in the name) but it enabled paramterisation of the algorithms (like DH 1024 or DH 2048) for advanced uses. I was only recently turned on to the text combo box too which, when you consider string case structures, is an excellent enum replacement, I used it for the Encryption Compendium for LabVIEW since there is a predefined list of algorithms to choose from. Enums are overrated and overused now IMO and pretty useless in flexible messaging architectures. That really became a moot point when cases started to support strings. One of the biggest (but not the only) "pro" for enums used to be that case statements created readable case names when wired and for things like state-machines it was a lot easier to see what was happening-readability. But still this is a bit of a band-aid when the IDE could support sparse enums. Come to think of it, this would probably be a good place for some OO and classes to handle all of this. Having to translate that back into enums, from enums back to rings, while supporting an "Other" mode, and saving and loading from disk can be a pain.
#LABVIEW RING MENU CODE#
I can have a list of common baud rates for hardware on the UI like 500K, 250K and it translates to a decimal value of 500,000, but then I can have an Other option where the user types in what they want and my code does its best to work with it. Yup, there are just some places where rings are so damned convenient. This means that if you want to translate a UI.don't use Enums on the FP. This also has other subtle implications such as you can change the ring strings at run-time whereas you cannot with enums. Changing all my BD constants into dummy controls with defined default value doesn't look very elegant to me. Now I'm scratching my head about whether I want to turn my generated typedefs into enums, then write a translation layer to obtain the nonsequential values, or what. I already had in place a dynamic way to create all the typedef.ctls I needed only, I realized that all was fine when the typedefs were used for subvi controls and indicators, but not for BD constants, which were static. My use case is to interface with a C library, whose (many and sparse in value) #defines may change across versions, and certainly do across bitnesses. Only enums carry their legal range and labels as part of their data type. So yes it turns that presenting the BD typedfd ring constant as typedef with a black ear is just a graphical mockery on the BD, that object is treated as a non-typedefd, "Because type definitions identify only the data type". Kudoed that idea, and the duplicate one mentioned in the discussion, for what helps.
0 kommentar(er)
