Ring Typedef - what is the value?

[cbutcher]

My arrangement here is more in the style of Dmitry Sagetelyan's error presentation - the code is used only as a magic number to identify that the source string contains a flattened object, that can then use standard DD to get module-specific details and messages, along with generic information about the time, call chain, etc.

Implementing child error classes do have their own enums for specific error causes and convert integer values to a message and description using a case structure or similar.

I think probably a reentrant inlined VI outputting a constant number is the solution I need for this problem, but I was surprised that a typedef'd ring inside a PPL didn't seem to have any useful value.

[JÞB]

---

@cbutcher wrote:

My arrangement here is more in the style of Dmitry Sagetelyan's error presentation - the code is used only as a magic number to identify that the source string contains a flattened object, that can then use standard DD to get module-specific details and messages, along with generic information about the time, call chain, etc.

---

In other words.... Duplicating all of the LabVIEW internal functions that pull the error out of an *_error.txt file where * is the module name.  I don't see how that builds a "Rounder Wheel."

I suppose maybe you can make some argument that NI just plain has some specific feature missing from the built-in custom error abilities that allow expansion of errors but, I haven't heard one yet that wasn't just fixed by "Retain all errors" option of merge errors. (Although,  I'd be happy to see p-nodes with an "Ignore and retain all errors inside node" expansion but the workaround is obvious)

Now, I have not seen Dmitry Sagetelyan's presentation.  But, in general ( I hate using that phrase) developers that argue "The Errors need more Features" really are trying to shoehorn in Events, Alerts, Alarms, or something else that really isn't an error into an existing construct that already has a function (error abuse) or, they simply are not aware that errors live in text files and are easy to expand.  I'd like a link if you have it handy.

[cbutcher]

---

@JÞB wrote:

---

I'd like a link if you have it handy.

---

This is the presentation I think - I didn't see it live but there are slides at this link and I saw a video at some point (not sure if it's available by that link, I might have gotten it from the old Technova servers or similar?)

---

@JÞB wrote:

In other words.... Duplicating all of the LabVIEW internal functions that pull the error out of an *_error.txt file where * is the module name.  I don't see how that builds a "Rounder Wheel."

---

As far as I'm aware (and perhaps this is just a lack of knowledge), you can't (easily? at all?) pack such an error file into a PPL, or easily package them together. I did initially use those files to try and create a list of different errors, but found it quite difficult to maintain and share between computers (at the time, I was using multiple computers but running code largely in the development environment, rather than applications).

I also found the idea that I think you're describing (i.e. a different file per module) to be quite difficult to manage - I suppose this requires just some sort of bookkeeping discipline, but if I recall correctly you can't see the error codes you've already used in other files without switching back and forth in the error editor window? (I see now looking at documentation that you can write them via XML outside of LabVIEW, but I don't think that solves the problem).

How would you recommend writing and managing error files for ~50 libraries and then packaging them with their appropriate PPLs to use in either development or deployed applications?

I instead found a class per library inheriting from an "Error" class that provides some basic functionality and can be placed on the same LabVIEW error cluster wire to be quite convenient. In the worst case, you don't handle it specifically and get a weird garbled "source" string, but the message can still be sort-of read around the odd characters (e.g. like in an image below - typically I wouldn't bother displaying this, or resizing it to be so large even if I did...)

if expanded, you can get a bit more information, but as you say, a lot of this is not really so fancy or different to what you can get with native LabVIEW.

[JÞB]

Let's define custom error codes first.

Custom error codes are unique codes that are not thrown by any existing native LabVIEW function.  Your example "unable to connect" via TCPIP is not a custom error as it has nothing to do with anything the ppl does it is only that the class implementation throws a defined error.  So, there is no need to distribute the defined error.

Now if we look at some existing modules, drivers, toolkits and Addons we do find examples of each of these that have custom errors.  The report generation module, DAQmx driver, Modulation TK and App Builder show examples of each type.  Each installer writes the associated error.txt file to error definition location so those definitions are available to both the developer and the existing error handler vis.  You don't need 50 ways to distribute them. There is one good way ( the installer) and one crappy way (SCC) to send them around.

So, having the text file (and documentation files and Unit Tests) in the project with your source lvlib just makes sense.  A Build to pack the library after testing and a Build to install new ppl and associated documents and error files is fairly simple and handles any feature releases for your customers that need them.

PPLs for use by your developer base is more problematic.  Really, you shouldn't be Packing dev tools.  Instead install them as lvlibs and remember to add mnu files as well as custom errors.

[paul_cardinale]

When you make a typedef strict, is causes some extra properties (such as the strings and values of a ring), to be able to propagate to controls; but only to controls, not to constants.  One way around this is to use a control (with default value set as desired) instead of a constant.  There is another way, but it is unsupported (and therefore risky):

Put these in labview.ini:

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE

Then when you right-click on a constant that is linked to a strictly typed typedef, you'll have this option:

[billko]

---

@paul_cardinale wrote:

When you make a typedef strict, is causes some extra properties (such as the strings and values of a ring), to be able to propagate to controls; but only to controls, not to constants.  One way around this is to use a control (with default value set as desired) instead of a constant.  There is another way, but it is unsupported (and therefore risky):

Put these in labview.ini:

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE

Then when you right-click on a constant that is linked to a strictly typed typedef, you'll have this option:

---

Just to clarify the risks a little, the main reason this is risky (and it's a big one) is because your source code just became incompatible with any LabVIEW installation that does NOT have these properties set in the ini file.  The worst thing about this is you will get no warning that your changes will no longer propagate to your block diagram constants.

Of course the opposite is also true; anyone who doesn't know these settings are active may start developing code that relies on them without realizing it and then wonder why their block diagram constants are not updating when they open it up on their computer to make a change and the changes don't propagate to the block diagram constants.

Edit:

Actually, I don't know if old constants will keep the new setting if opened in a LabVIEW installation that does not have the special properties enabled.

[paul_cardinale]

---

@billko wrote:

---

@paul_cardinale wrote:

When you make a typedef strict, is causes some extra properties (such as the strings and values of a ring), to be able to propagate to controls; but only to controls, not to constants.  One way around this is to use a control (with default value set as desired) instead of a constant.  There is another way, but it is unsupported (and therefore risky):

Put these in labview.ini:

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE

Then when you right-click on a constant that is linked to a strictly typed typedef, you'll have this option:

---

Just to clarify the risks a little, the main reason this is risky (and it's a big one) is because your source code just became incompatible with any LabVIEW installation that does NOT have these properties set in the ini file.  The worst thing about this is you will get no warning that your changes will no longer propagate to your block diagram constants.

Of course the opposite is also true; anyone who doesn't know these settings are active may start developing code that relies on them without realizing it and then wonder why their block diagram constants are not updating when they open it up on their computer to make a change and the changes don't propagate to the block diagram constants.

Edit:

Actually, I don't know if old constants will keep the new setting if opened in a LabVIEW installation that does not have the special properties enabled.

---

That's not accurate.  The .ini settings just give you access to change a hidden property of constants.  That property is persistent, regardless of the .ini settings.

[billko]

---

@paul_cardinale wrote:

---

@billko wrote:

---

@paul_cardinale wrote:

When you make a typedef strict, is causes some extra properties (such as the strings and values of a ring), to be able to propagate to controls; but only to controls, not to constants.  One way around this is to use a control (with default value set as desired) instead of a constant.  There is another way, but it is unsupported (and therefore risky):

Put these in labview.ini:

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE

Then when you right-click on a constant that is linked to a strictly typed typedef, you'll have this option:

---

Just to clarify the risks a little, the main reason this is risky (and it's a big one) is because your source code just became incompatible with any LabVIEW installation that does NOT have these properties set in the ini file.  The worst thing about this is you will get no warning that your changes will no longer propagate to your block diagram constants.

Of course the opposite is also true; anyone who doesn't know these settings are active may start developing code that relies on them without realizing it and then wonder why their block diagram constants are not updating when they open it up on their computer to make a change and the changes don't propagate to the block diagram constants.

Edit:

Actually, I don't know if old constants will keep the new setting if opened in a LabVIEW installation that does not have the special properties enabled.

---

That's not accurate.  The .ini settings just give you access to change a hidden property of constants.  That property is persistent, regardless of the .ini settings.

---

So it works like enabling Unicode support, where objects created that have Unicode turned on keep their property?  Is it still exposed in a LabVIEW setup that doesn't have the ini setting enabled, or do you just have to live with whatever it was set to?  Maybe I should take a vacation from answering questions because my track record has not been stellar lately.

[paul_cardinale]

---

@billko wrote:

---

@paul_cardinale wrote:

---

@billko wrote:

---

@paul_cardinale wrote:

When you make a typedef strict, is causes some extra properties (such as the strings and values of a ring), to be able to propagate to controls; but only to controls, not to constants.  One way around this is to use a control (with default value set as desired) instead of a constant.  There is another way, but it is unsupported (and therefore risky):

Put these in labview.ini:

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE

Then when you right-click on a constant that is linked to a strictly typed typedef, you'll have this option:

---

Just to clarify the risks a little, the main reason this is risky (and it's a big one) is because your source code just became incompatible with any LabVIEW installation that does NOT have these properties set in the ini file.  The worst thing about this is you will get no warning that your changes will no longer propagate to your block diagram constants.

Of course the opposite is also true; anyone who doesn't know these settings are active may start developing code that relies on them without realizing it and then wonder why their block diagram constants are not updating when they open it up on their computer to make a change and the changes don't propagate to the block diagram constants.

Edit:

Actually, I don't know if old constants will keep the new setting if opened in a LabVIEW installation that does not have the special properties enabled.

---

That's not accurate.  The .ini settings just give you access to change a hidden property of constants.  That property is persistent, regardless of the .ini settings.

---

So it works like enabling Unicode support, where objects created that have Unicode turned on keep their property?  Is it still exposed in a LabVIEW setup that doesn't have the ini setting enabled, or do you just have to live with whatever it was set to?  Maybe I should take a vacation from answering questions because my track record has not been stellar lately.

---

1. Yes.
2. Access to the setting is only available with those super .ini settings.  Without them, you are stuck with whatever it's set to.