Comments on: The Diagram Disable Structure causes bugs http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/ an unfiltered stream of data flow consciousness Fri, 5 Sep 2008 20:06:15 +0000 http://wordpress.org/?v=2.6.1 By: crelf http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10371 crelf Mon, 12 May 2008 20:00:42 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10371 Jim: Where's the (mooning) emoticon? Jim: Where’s the (mooning) emoticon?

]]> By: Jim Kring http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10370 Jim Kring Mon, 12 May 2008 19:31:16 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10370 Crelf: Sorry, I assumed that you'd actually read the article :p Crelf: Sorry, I assumed that you’d actually read the article :p

]]> By: crelf http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10369 crelf Mon, 12 May 2008 19:25:46 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10369 Grrrrrrr :) Yeah - he's cool. Well, if you <strong>must</strong> make it obvious that I didn't completely read your original article :o Sorry - I'd just skimmed - you're absolutely right - as always... :p Grrrrrrr :) Yeah - he’s cool.

Well, if you must make it obvious that I didn’t completely read your original article :o Sorry - I’d just skimmed - you’re absolutely right - as always… :p

]]> By: Jim Kring http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10367 Jim Kring Mon, 12 May 2008 18:55:55 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10367 Crelf: Yes, that is an evil-looking smiley. I hope it doesn't lead to any hostility, here :) Crelf: Yes, that is an evil-looking smiley. I hope it doesn’t lead to any hostility, here :)

]]> By: Jim Kring http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10365 Jim Kring Mon, 12 May 2008 18:54:04 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10365 Crelf: I made those qualifications in my original statement (in the article) ;) Crelf: I made those qualifications in my original statement (in the article) ;)

]]> By: crelf http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10364 crelf Mon, 12 May 2008 18:41:20 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10364 :) Does that Smiley look a tlittle evil to you? I think it's because of his eyebrows... :) Does that Smiley look a tlittle evil to you? I think it’s because of his eyebrows…

]]> By: crelf http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10363 crelf Mon, 12 May 2008 18:40:45 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10363 Jim wrote: "I think that it is acceptable to auto-wire an output to an input that is <strong>exactly the same data type and vertical position</strong> as the input" Sure - now that you've made those qualifications, I think that use case is absolutely valid. PS: :) Jim wrote: “I think that it is acceptable to auto-wire an output to an input that is exactly the same data type and vertical position as the input”

Sure - now that you’ve made those qualifications, I think that use case is absolutely valid.

PS: :)

]]> By: Jim Kring http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10359 Jim Kring Mon, 12 May 2008 17:26:27 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10359 Chris: Here are my thoughts on this.... There are two reasons that you might want to comment out a block of code: 1) You don't want to execute a block of code 2) You want to execute a different block of code, instead of an original block of code (but you don't want to delete the original block of code -- only comment it out, and put the new block in the enabled frame of a DDS). In case #1, I think that it is acceptable to auto-wire an output to an input that is <strong>exactly the same data type and vertical position</strong> as the input. If a reference, path, error, or other "chained" data input and output are not the exact same vertical position, I consider this to by a <strong>style bug</strong> in the user's code. The worst possible thing that could happen is that some input argument is the same vertical position and data type as an output argument and you don't want to auto-wire them. This has a small chance of causing problems. Perhaps it would be good to limit the data types that we allow to be auto-wired to error cluster, path, refnum (i.e., object, VISA, datalog refnum, DAQmx, etc). Also, if a simply commenting out a block of code (and making no changes to it, other than auto-wiring chained data) will not prevent the parent code from executing, then I can only imagine a couple situations where it might be bad to have a non-chained input argument accidentally auto-wired to an output return value. In case #2, auto-wiring doesn't hurt, because you're going to edit the newly created, enable frame and will likely make significant changes, anyhow. And, if one's worried, they can disable (or not enable) the feature in the options :) Chris: Here are my thoughts on this….

There are two reasons that you might want to comment out a block of code:

1) You don’t want to execute a block of code

2) You want to execute a different block of code, instead of an original block of code (but you don’t want to delete the original block of code — only comment it out, and put the new block in the enabled frame of a DDS).

In case #1, I think that it is acceptable to auto-wire an output to an input that is exactly the same data type and vertical position as the input. If a reference, path, error, or other “chained” data input and output are not the exact same vertical position, I consider this to by a style bug in the user’s code. The worst possible thing that could happen is that some input argument is the same vertical position and data type as an output argument and you don’t want to auto-wire them. This has a small chance of causing problems. Perhaps it would be good to limit the data types that we allow to be auto-wired to error cluster, path, refnum (i.e., object, VISA, datalog refnum, DAQmx, etc). Also, if a simply commenting out a block of code (and making no changes to it, other than auto-wiring chained data) will not prevent the parent code from executing, then I can only imagine a couple situations where it might be bad to have a non-chained input argument accidentally auto-wired to an output return value.

In case #2, auto-wiring doesn’t hurt, because you’re going to edit the newly created, enable frame and will likely make significant changes, anyhow.

And, if one’s worried, they can disable (or not enable) the feature in the options :)

]]> By: crelf http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10356 crelf Mon, 12 May 2008 16:56:48 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10356 Jim: I'm not so sure: the reason I don't like default outputs is that they don't break the code and make me wire them up to something intelligent - won't autowiring have the same issue (it'll wire something up, which might or might not be wrong) and not break the code. I don't see the difference (other than it *might* get it right, but sometimes a default response it right too...) Jim: I’m not so sure: the reason I don’t like default outputs is that they don’t break the code and make me wire them up to something intelligent - won’t autowiring have the same issue (it’ll wire something up, which might or might not be wrong) and not break the code. I don’t see the difference (other than it *might* get it right, but sometimes a default response it right too…)

]]> By: Jim Kring http://thinkinging.com/2008/05/11/the-diagram-disable-structure-causes-bugs/#comment-10354 Jim Kring Mon, 12 May 2008 16:43:40 +0000 http://thinkinging.com/2008/05/20/the-diagram-disabled-structure-causes-bugs/#comment-10354 Ton: I agree about the True/False case. There was a similar issue when converting to an Error Case. NI eventually gets around to fixing these usability issues, but only after much complaining from us :) crelf : I think that auto-wiring should be optional and very intelligent. I'm pretty sure that we could come up with a rule-set for auto-wiring that would work in a majority of situations. Also, the auto-wiring output tunnels would be MUCH safer than outputting default values. Rick: I'm curious to see if you can reproduce the wiring of the error cluster issue -- that's spooky. Ton: I agree about the True/False case. There was a similar issue when converting to an Error Case. NI eventually gets around to fixing these usability issues, but only after much complaining from us :)

crelf : I think that auto-wiring should be optional and very intelligent. I’m pretty sure that we could come up with a rule-set for auto-wiring that would work in a majority of situations. Also, the auto-wiring output tunnels would be MUCH safer than outputting default values.

Rick: I’m curious to see if you can reproduce the wiring of the error cluster issue — that’s spooky.

]]>