Search the Community
Showing results for tags 'typedef'.
I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data. Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want. For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES. I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
Hi guys! I'd like to have my XNode to behave differently when the input is a (strict) typedef but also differently according to the typedef path (or name) if any. In a regular VI, this is easily done by extracting the path of the typedef: Terminal>Control>TypedefPath, but in Xnodes it's another story! So far I managed to get the regular type in the 'AdaptToInputs' ability (which is the common use of this ability!) and to see if it is a typedef or not by reading the properties of the control in the 'GenerateCode' ability. But in this last ability VI, an error occurs when I try to obtain the TypedefPath (Error 7). This error apparently occurs in Xnodes and especially Express VIs when "one of the internal paths is hard coded incorrectly" Is there a limitation due to the XNode or else? I guess that I could get around the problem by scripting the owning VI and retrieve the typedef of the control connected to the XNode directly but it would be quite cumbersome and ugly. Any thoughts on the subject?
Hi all ! I mainly use XML files as configuration file for my applications. And then use flatten/unflatten from XML to populate a configuration cluster... I've made a routine which creates the configuration file if it has been deleted by the user. In that case the XML file is create with default values. I usually 'store' these values in the strict type definition of my cluster (see In Strict Typedef png). I was wondering if it was a good idea ? Or should I explicitly bundle the values in my code (like in Init png) ?