Jump to content

Property nodes are "upside down" - discuss!


Recommended Posts

I was just doing some coding and getting information out of a property node, and it struck me that, from a style point of view at least, property nodes are upside down...

Having recently read Peter Blume's Labview style book, one of the big conventions seems to be that error clusters should wire in an out of the bottom of subvis... So why do we have to wire errors in and out of the top of property nodes? I like my code to have a nice continuous error line somewhere near the bottom, but as soon as you start dealing with a few properties from one node, you can't do that neatly anymore. Wouldn't it make sense for the base part of the propery node (i.e. the class label) to be at the bottom with the error, and then you could open the properties terminals upwards...

Anyways, I probably just have too much time on my hands!

Paul

Link to comment

QUOTE (Ic3Knight @ Feb 25 2009, 09:32 AM)

Another big convention is to have references wire in and out of the top of subVIs.

QUOTE (Ic3Knight @ Feb 25 2009, 09:32 AM)

I like my code to have a nice continuous error line somewhere near the bottom, but as soon as you start dealing with a few properties from one node, you can't do that neatly anymore.

Are you talking about statically linked or dynamically linked property nodes?

Link to comment

Statically (I think?!), I've attached a picture of the code I was just working on as an example... Its part of a bigger application to control a system which contains a DAQ device. Since there is a possibility that my system will be connected to a PC which already has a DAQ device attached, I use the serial number of mine to find the device name and then populate a cluster of channel names which I'll use later on in my code....

post-14639-1235574922.png?width=400

Anyways, you end up having to do several operations below the "error line" which I don't like (although functionally it doesn't matter obviously!)

Anyway, as I was say its just something that struck me, I have to admit, I didn't think it through a huge amount!!

Cheers!

Paul

Link to comment

QUOTE (Ic3Knight @ Feb 25 2009, 04:18 PM)

Since Property nodes are expandable imagine the mess which would be created if the error wire was dragged up and down with the lower edge of the property node..... If anything, the upper part (Refnum & Error connector) could be made larger to support the standard Connector wiring scheme spacing. Less error wire bends...

Shane.

Link to comment

QUOTE (shoneill @ Feb 25 2009, 03:29 PM)

Since Property nodes are expandable imagine the mess which would be created if the error wire was dragged up and down with the lower edge of the property node..... If anything, the upper part (Refnum & Error connector) could be made larger to support the standard Connector wiring scheme spacing. Less error wire bends...

Shane.

You can already get into that mess by dragging the top of the property node upwards...

Perhaps something it should be selectable (reversible) and the size of a typical SubVI? So that you don't get error bends on the default size and you can choose whether to have the properties above or below?!

Just a thought

Link to comment

I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.

Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy?

Link to comment

QUOTE (Ic3Knight @ Feb 25 2009, 10:18 AM)

Yep - that one's static (there's no reference terminal).

QUOTE (Ic3Knight @ Feb 25 2009, 10:53 AM)

You can already get into that mess by dragging the top of the property node upwards...

Yep - I think both approaches are equally valid, but NI just choose one way over another. I still prefer the reference/error clusters where they are, as they define the object, whereas the expandable nodes are methods/properties of that object. IMHO, I think it should stay the way it is, but it's always good to try to think outside the box every now and then :)

Link to comment

QUOTE (Aristos Queue @ Feb 25 2009, 05:15 PM)

I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.

Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy?

Ding!

That's the right Idea I think, even though upwards expansion of property nodes still messes up wires but it'd be an improvement.

It'd cause a stir and it'd take some getting used to though.....

Shane

Link to comment

QUOTE (Aristos Queue @ Feb 25 2009, 08:15 AM)

I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.

The worst part of this idea, in my opinion, is that it would've made a really great April Fool's joke. And now you've used it all up :P.

Link to comment

QUOTE (Aristos Queue @ Feb 25 2009, 09:15 AM)

I recently placed an idea in front of the LV R&D team to think about: Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? That is the one consistent location that you could then string an error wire across between functions, regardless of type. Then if you have a second type that is railroading along side the error code, have it running in the second-from-the-top terminal. This means that you have one side of your node that you can get values to the other terminals without crossing your two railroad track wires, and your nodes can stay top aligned to minimize bends in the error wire.

Yeah, it'd be a big change to the diagram to do it today. But if we didn't have 20 years of diagrams, wouldn't that be a better strategy?

While you're at it if you're going to change the error terminals it may also a good recommendation to change the error cluster... into a class.

Link to comment

QUOTE (Rio C. @ Feb 25 2009, 01:09 PM)

While you're at it if you're going to change the error terminals it may also a good recommendation to change the error cluster... into a class.

That's a definate thread hijack right there - please start a new thread to continue that discussion.

Link to comment

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

Link to comment

QUOTE (crelf @ Feb 25 2009, 08:20 PM)

Errors are data too.

He he, funny :lightbulb: Yes, but everyone knows what that data is... It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

Link to comment

QUOTE (bsvingen @ Feb 25 2009, 03:10 PM)

It is only when debugging that the data in those wires are of any interest, if at all. The main purpose of those wires are to transport errors away to an error handler of some kind.

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

Link to comment

QUOTE (Aristos Queue @ Feb 25 2009, 11:15 AM)

Shouldn't error terminals be moved -- on all nodes -- to be the top terminal of all nodes? , wouldn't that be a better strategy?

I like this idea!

I would like to see the default label "(no error)" part of the error in go away.

Link to comment

QUOTE (bsvingen @ Feb 25 2009, 01:11 PM)

Or better, make the error wires invisible. Seriously, they mess up the diagram wile serving only an implicit function that distracts away from the flow of data. I mean, LV is dataflow - not errorflow. There could be a switch that makes them visible/invisible, and the connectors could be "filled" when a wire is connected and unfilled when not.

I would argue instead of this (but similar) to have error wires default to the bottom z-order of a diagram, beneath all other wires. I don't want to hide them, but I always do Ctrl-Shift-J to put them beneath all other wires. It would be awesome if this was somehow the default behavior.

Link to comment

QUOTE (gleichman @ Feb 25 2009, 01:56 PM)

I would like to see the default label "(no error)" part of the error in go away.

It takes about a minute to go into C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\errclust.llb and remove the annoying "(no error)" part of the label (don't forget to fix both the classic and the 3D version). That's just about the second thing I do to a fresh copy of LabVIEW after turning off 'Lock Automatic Tool Selection', 'Automatic Wire Routing', and AutoGrow.

Link to comment

QUOTE (crelf @ Feb 25 2009, 09:25 PM)

I don't agree - I make a lot of decisions in my code based on what's in the error cluster, even before it gets to an error handler.

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

Link to comment

QUOTE (bsvingen @ Feb 25 2009, 07:17 PM)

Yes, but I don't see how the ability to make the wires invisible (transparent) will prevent you from doing that. I mean, this would basically be an implementation of layers, that have existed in CAD/graphical programs for decades.

If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion...

Link to comment

QUOTE (crelf @ Feb 25 2009, 05:45 PM)

If the wires were transparent then I wouldn't be able to look at the code and see where the data flows. That would be a big step backwards IMHO. Layers in the diagram - well, that's different, and certainly deserves further discussion...

Layers would be good esp if the error wire could come to the top of the z-order IF an error or warning is being propagated.

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.