UI change for keeping track of messages

[auspex]

It would be useful to me if the virtual folder for an actor's messages would indicate messages it might receive because it is a subclass of another actor. Showing the "inherited messages" as greyed out, perhaps with a mouseover tip, would suffice. Perhaps something similar could be useful for class methods which can be, but are not yet, overridden.

Perhaps my inability to easily recall potential incoming messages indicates I need to rethink my program structure, but I offer this in case it isn't and anyone else has the same problem.

[AristosQueue (NI)]

I understand the motivation for the request. The problem is the specific thing you've asked for: You're asking for an item to appear in the project tree multiple times -- once under the parent and again under each child. That's not how the project tree works. It would require a much more fundamental rewrite of LabVIEW's project system itself. That's not something that the AF could do on its own.

Even if the project allowed this... there's a major ambiguity... you're under the child's library, adding items that aren't part of the child's library. The .lvlib files don't have the inheritance relationship that the classes have. I don't think greying out helps. That would require a lot of contemplation, I believe, to avoid injecting more confusion than it solves.

Maybe we can propose some other tool to address this?

[auspex]

I suppose something like the VI or class hierarchy diagram would do. Even coming up with a rough sketch I get feature creep and want to make an entire language out of it.

[AristosQueue (NI)]

---

@auspex wrote:

I suppose something like the VI or class hierarchy diagram would do. Even coming up with a rough sketch I get feature creep and want to make an entire language out of it.

---

What can I do to encourage your addictive behavior to complete that sketch? Would sufficient caffeine result in you obsessively working on it until you actually produce code for this tool?  🙂

[kosist90]

AristosQueue, wouldn't be the easiest solution in this case, to put automatically override messages / zero-coupled messages childs classes to separate virtual folders?

Personally, I like the feature when for classes I can select, whether accessors methods would be put to some virtual folder automatically - so why not to have this feature for override methods? Moreover, then overrride methods could be separated to "Must Override", "Override" folders, etc...

In case of creating child for an abstract method anyway is executing script for creation of messages, which places classes to virtual folder "Messages For This Actor" - so could the script be modified in a way, that if child of abstract message is created, it would be put to another virtual folder "Childs of Abstract Messages For This Actor"?

And if I'm not mistaken, those script VIs do not have password protection, so it's possible to check them by ordinary user... 

What do you think about it, please?

Sincerely, kosist90

[AristosQueue (NI)]

First, I don't think this addresses your original central concern, which is identifying all the messages that can be received by a given class -- i.e., aggregating in a single list somewhere all of the inherited messages from all ancestors with the class' own messages. The abstract message issue seems completely orthogonal. If there is some connection I'm missing, please explain.

Second (addressing the suggestion directly), we organize the abstract messages with the class capable of sending them since that's the class that you have to launch in order to know to create a concrete message class of that abstraction. The concrete instantiations of that are no different from any other message that the class can receive from the point of view of the receiver, so I'm not sure why you would want to separate them into a separate folder in the API of the receiving class. BUT, having said that, yes, it is possible to do. Moreover, you're right, we have tried to keep password protection off of most of those VIs, so if you want to tweak those VIs for your own preferences, you are free to do so. (Make sure you copy off your edits to a backup so you can restore them after applying a patch, which might overwrite those VIs.)

[auspex]

---

@AristosQueue (NI) wrote:

---

@auspex wrote:

I suppose something like the VI or class hierarchy diagram would do. Even coming up with a rough sketch I get feature creep and want to make an entire language out of it.

---

What can I do to encourage your addictive behavior to complete that sketch? Would sufficient caffeine result in you obsessively working on it until you actually produce code for this tool?  🙂

---

Sorry. I got very busy with other things and even took ill for a little while there. I'll swing back around to this idea in a few weeks when I have some other things out of the way.

[auspex]

@AristosQueue (NI) wrote:

First, I don't think this addresses your original central concern, which is identifying all the messages that can be received by a given class -- i.e., aggregating in a single list somewhere all of the inherited messages from all ancestors with the class' own messages. The abstract message issue seems completely orthogonal. If there is some connection I'm missing, please explain.

That wasn't me. 😉

[AristosQueue (NI)]

---

@auspex wrote:
That wasn't me. 😉

---

Doh. Missed the change of person replying. Sorry about that.

[auspex]

I figured out something that works for me for now: An empty virtual folder named "<ancestor>::<message>".

I don't think I need this enough to try scripting it. We'll see.