Jump to content

Notifiers w/ Class


Recommended Posts

I have an architecture that requires a notifier to be part of the class data.

This is so that wherever the class gets sent to, it can send itself back via what would now be waiting on the created notifier.

(I know there are other ways but roll w/ me on this)

So would you think that it's a bug or rather should be illegal to embed a notifier which has the data type be that of the class that it is contained within?

I understand this feels a little chicken-eggy, but I see no real reason why I should be prevented from doing this.

(because every time I do try, it breaks the class)

See the attached code and simply replace the data type within the notifier to be a variant and everything is ok.

Open project, look at class data def, observe simple data structure, open write notifier.vi, observe dead wire, open typedef and replace

Download File:post-208-1229833042.zip

So before I harass an AE that I might actually run into on the elevator, I thought I would see what y'all thought.

Link to comment

LabVIEW doesn't allow using recursive data types. I wrote an article on it a year ago on ExpressionFlow. What you can do is to make the notifier type to be of parent class or LabVIEW object. Then simply cast the notifier data to more specific when the notifier is received. Also note that you should use the new Wait on Notification (from Multiple) With Notifier History function in class method vis and other reusable code to avoid possible incorrect behaviour or in worst case application freeze conditions.

Cheers

Tomi

Link to comment

  1. From a logical point of view, you are correct that no there's no reason that LabVIEW should disallow a notifier of a class being inside the class itself (or a queue or an array whose default value is an empty array, or a datalog or indeed any other refnum type with the class embedded inside it). After all, although the data *type* may be recursive, the data is not.
  2. From a language simplicity point of view, it's just a lot easier to explain "LV does not allow a class to be used as part of its own definition." than to go into the intricacies of why an array would have to have a default value of zero length, or try to puzzle out the error list window when such a circular class breaks. This is ESPECIALLY true when we start talking about circles of greater than one step (i.e., A includes B which includes A).
  3. From a language implementation point of view, there are plenty of performance shortcuts that can be made when loading a class into memory if we assume that all classes that are not broken are ones that do not include themselves in their definitions. Class unloading is complex enough without having to try to find "in any given circle of classes, identify which one is the reference one and allow it to unload first".

Because the need for circular definitions is particularly rare compared to the total number of classes in the world, and because such need is typically encountered by advanced programmers, and because such programmers can and do stumble upon the idea of using the parent class in their child class definition to achieve much the same effect, points of view #2 and #3 trumped #1 during LV's design process.

Link to comment

I've noticed problems when the class data contains a queue/notifier/event reference that includes the class data type -- this is a recursive type definition. You should (do as Tomi suggested and) make your Notifier use a generic LVClass reference and then upcast it to the more specific type after you receive the notification. This solution works very well and is how we solve this problem at JKI.

Link to comment
  • 2 years later...

I am just adding to this old thread.

I was trying to use the same type of architecture in my project, until I realized that LV is not allowing me to use notifier of Class datatype inside the Dynamic Dispatch VI. But as posted here, LabVIEW now supports recursion, so shouldn't this kind of architecture be allowed?

By the way, I still didn't get a clear picture of why this type of architecture can't be allowed in LabVIEW.

Link to comment

If speed doesn't matter, it's perfectly valid to have an Variant containing the Class / DVR to Class / Notifier with Class / etc... in class data. You have simply to convert to / from Variant in the accessor methods.

Edited by jerl
Link to comment

I am just adding to this old thread.

I was trying to use the same type of architecture in my project, until I realized that LV is not allowing me to use notifier of Class datatype inside the Dynamic Dispatch VI. But as posted here, LabVIEW now supports recursion, so shouldn't this kind of architecture be allowed?

By the way, I still didn't get a clear picture of why this type of architecture can't be allowed in LabVIEW.

LabVIEW supports recursive CALLS but not the recursive DATA TYPE DEFINITION which is what they discussed here. To help you answer why continuehere

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.