Bundle output updates Typedef

[Intaris]

Whend ealing with buldled data structures, we're always told that creating Typedefs is a good idea.  It's just a shame that it's a PITA to maintain them sometimes.

Take a User-event API I have for one of my modules.  At the moment I have bundled my events (some sub-clusters of which are (or should be ;)) Typedefs themselves.

If I change the bundle at position 1, I have to do this updating routine once, twice at location 2 and three times at location 3 to properly update the ouput cluster typedef.

If we could link the output of the bundles (of each step of this clustersaurus) then the output data will be automatically updated to reflect our coding changes, which cuts out all of the manual updating.  The following illustration shows only the last bundle with the option activated (Autoupdate Typdef).

Why can't we designate the OUTPUT of the bundle to define the typedef.  Link the bundle to the typedef control so that whenever the datatype output of the bundle changes, the typedef is automatically changed also.  Event API programming would get SO much easier with this.

While the graphic shown seems to imply that the input terminal to the bundle is somehow important to the operation, it is not intended that way.

[Intaris]

Well for me, in my use case, no I don't edit the Typedef directly after it has been initially created at all.

Regarding creating a constant and copy-pasting, I've missed cluster boundaries so often on that operation that I gave up on it years ago.  I'm really referring to prototype phase programming where the full requirements are not yet known, therefore a highly variable typedef.

Because (in the case of using bundled User Events as an API) I need to create the events anyway, so creating the code first and then updating seems to duplicate less work.  If the clsuter was compirsing of something else, then yeah, I have plenty of cases where I simply edit the Typedef.  Problems arise when notifiers, queues, events and registered events enter the equation.  Events store the name of the Event in the datatype, no?  Therefore the copy-paste doesn't help much because I end up with a load of duplicate event names.....

[Intaris]

Either way, I know this is a corner use-case.

It riles me every time I have to jump through loops to essentially automate something whose intention is apparent to me.  Maybe I just need to script more.

[SteenSchmidt]

I, on the other hand, have a really hard time seeing the problem here - other than you need to stop using clusters that are not typedefs, and stop using the bundle node 😉

All (and that's without a single exception) my clusters are typedefs. Often I make them strict as well, but not because they are UI objects, but so they do not roam about on the FP when I update their contents (making them strict lets me control the exact layout of the cluster everywhere on the FPs, even though LabVIEW itself should be smart enough to not make me have to do this).

The above also means I never have any problems updating my cluster types via the typedefs. Every change propagates automatically into the code, and I don't have to fiddle about making manual changes anywhere (except of course where my code breaks, but that's by design in that case).

/Steen

[Intaris]

Steen,  I use typedefs.  The word typedef is in the idea title.  It's not a problem of typedef propagation, that works fine for me thae same way it does for you.  That's NOT the topic of my idea.

I have clearly done a miserable job of explaining what I want.  It has more to do with typdef change management in combination with rather complex datatypes (Refnum to a user event containg a notifier of a specific enum) than typedef propagation.

[SteenSchmidt]

Intaris, ok, so you're looking for a shortcut for doing create constant from new data type->drag or copy constant to typedef FP->drop constant onto old refnum to change its referred data type? That shortcut being automatic propagation, and AQ suggesting it being an activatable context menu option?

If that's so, your suggestion (or maybe rather AQ's) is a slight improvement, but I still don't find the current activity of just dropping new data types into the typedefs that cumbersome. Especially not when you can update the data type of refnums by just dropping another constant on top of it.

Or maybe I'm still missing the target? I'll try to read from the top again...

/Steen

[Intaris]

There is actually a precedent for this.

When opening an FPGA bitfile, there is an option to bind the interface to a typedef which actually does exactly what I am looking for.  Whenever the interface for the Bitfile changes, LabVIEW automatically updates the typedef accordingly, sparing a lot of manual update work.

I would like to be able to define this for OTHER typedefs in combination with certain LV primitives.

In the example shown above, my Interface or API is the result of the various bundle steps which tends to change during the course of programming the code.  Manually keeping these up to date is extremely tedious, even if there are shortcuts.  My proposed idea would greatly improve such an experience.  I think with user events as APIs in general, this idea would be a great time saver.

[AristosQueue (NI)]

I gave this some more thought over my recent long periods in airports and airplanes.

It isn't a bad idea, but it isn't a slam dunk either. Intaris mentioned that maybe he needs to script more... that may very well be the best solution here, but I'm willing to explore the design space a bit.

At root, Intaris is requesting that the prime location for definition of a typedef be someplace other than the typedef itself. The actual .ctl file -- if it even still exists -- is not the place where you go to edit the type. Instead, you edit the type from the block diagram by virtue of adding/removing terminals to a particular bundle node. So the bundle node is the thing that defines the type. It doesn't matter that it is an unnamed Bundle node. The reason for advocating Named Bundle and Named Unbundle is that those nodes do a much better job of updating to match changes in the typedef. That logic doesn't apply to a node that is pushing changes out instead of pulling them in.

The impetus behind this request (as I understand it) is that it is common for him to have one place where data originates that is then passed through and used in many other places (or, at the least, this occurs during prototyping). From that perspective, it makes more sense to have that point of origin be the place where the typedef is defined rather than having a separate definition that you update and then patch up the point of origin.

Technically this is viable. We either make the .ctl file not be editable and have it update when the designated diagram changes OR we do away with the .ctl file entirely and have other VIs point to the designated diagram directly as the source of the typedef. There's a small amount of weirdness around "Apply Changes" now having to be an operation on a non-ctl, but that can be dealt with, I believe.

The implmentation questions that occurred to me:

1. How common is it to have a single point in the code that could be considered the "origin" point for an entire data type? I do not believe this would account for most typedef clusters, but it might be that most users have at least one such cluster per application. The answer to this question would guide how pressing it is to create this feature, even if people do not kudos it ... this is the kind of feature that they might not realize that it would benefit them.

2. How would we flag "this typedef is different" for someone trying to understand a large code base? If they recognize that a particular type is passed from point B to point C and they would like to add a data field to it, they will go edit the typedef. How do we signal to them that they need to go to point A to edit this typedef (because it is a diagram-defined typedef)?

3. We should be able to modify a typedef to say "this node no longer defines the typedef... move that responsibility to the ctl file." Do we have to have a way to move the responsibility the other direction? (Note that this is an argument for keeping the .ctl file as an entity even though it isn't strictly needed while the node is the definition location.)

The deeper "should we do this" questions that occurred to me:

1. How corner of a use case is this? Echoes my question from above about how many customers actually have code like this.

2. If we did implement the feature, how would we guide users to use it? Can it be made discoverable so that people who would benefit from it actually learn about it? Given that in most cases NI advocates for the "Bundle By Name" version, few people would ever see a new option on the "Bundle" node. If it isn't discoverable, it might as well not exist.

3. Can this feature be implemented as an editor feature instead of a language feature? In other words, LV could have some mode that I enable briefly that says "for the moment, put this Bundle node in charge of the typedef... don't break the wires, let me add terminals, etc, until I choose Apply Changes, then update the typedef and go back to putting the ctl in charge." That would dodge implementation questions 2 and 3 entirely. But I am not sure whether or not such a mode is better or worse usability compared to just putting a given node always in charge.

That's it.

[Intaris]

For the implementation i would point tomexisting code with the fpga module.

Here we have a standard ctl.  We link a bitflie interface to this ctl and whenever LabVIEW detects a change to the bitfile, it updates the ctl accordingly.  The code monitoring the bitfile is the same code which updates the ctl i would guess.

This already exists and seems to work nicely.  Its just a shame i only discovered this recently.

In my idea, a single bundle node (maybe a new primitive?) Is the point of monitoring / changing and not the open bitfile primitive.

With the existing code we can both autoupdate the ctl upon bitfile change or we can edit it directly.  LabVIEW just uses the current version on disk (or in memory).

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.