dannyt Posted January 12, 2012 Report Share Posted January 12, 2012 An OpenG VI I used quite often is 'Fit VI window to Largest Decoration.vi' I find it vey useful to help make message popup winows an the like look OK to the user without to much effort. I would like to suggest that this VI is a good case of a VI which should just ignore the Error in state and still do its job in this case just passing any error out obviously merged with its own error line. Anybody else like to comment on this ? Danny Quote Link to comment
Antoine Chalons Posted January 12, 2012 Report Share Posted January 12, 2012 I really like this idea! Quote Link to comment
jgcode Posted January 12, 2012 Report Share Posted January 12, 2012 I would like to suggest that this VI is a good case of a VI which should just ignore the Error in state and still do its job in this case just passing any error out obviously merged with its own error line. This is just my opinion... Although I really like the VI, I don't use it as I have my own API for setting up a UI which is my part of my UI templates. But my initial response to this suggestion is why would you want that behavior? If there is a downstream error then possibly something that feeds inputs in this VI may be wrong - and if an error did occur in just setting up the UI for display - then I probably would opt out on showing the UI to the user and report and error because other weird stuff may have happened to the UI setup. I see that the change could be handy if you are not worried about the above and are linking errors to specify dataflow. Of course one could get the effect of both of the above use cases by overriding the behavior e.g. like this: ...Having said all that, from an OpenG perspective things can always be changed. As this is a change in behavior, this VI would have to be deprecated, and a new VI created to do what you are proposing. What do others think that use this VI? Quote Link to comment
crelf Posted January 12, 2012 Report Share Posted January 12, 2012 I don't think this is a good idea - there are only a few cases where I would expect a subVI or primative to ignore an error in: closing references comes to mind. I think that changing the behaviour of common reuse components in this way is untintuative. If we really want to do this, I'd suggest that the OpenG VI include an "Ignore incomming errors" Boolean input (kind of like how you can ignore node errors on property and invoke nodes). Quote Link to comment
Antoine Chalons Posted January 12, 2012 Report Share Posted January 12, 2012 Oups... I'm just realizing now that I didn't understand what dannyt said, I first thought he meant that the 'Fit VI window to Content.vi' should not take into account Error in & Error out clusters when resizing... reading jgcode's answer I realized my mistake. Sorry for that. And then now I don't think the original idea is that good. Quote Link to comment
dannyt Posted January 12, 2012 Author Report Share Posted January 12, 2012 Jgcode, your suggestion is what I currently do, in a few places. So I am quite happy to carry on doing that. The backwards compatbility aspect is a good comment, I had missed. So I will keep quite now Quote Link to comment
crelf Posted January 12, 2012 Report Share Posted January 12, 2012 Jgcode, your suggestion is what I currently do, in a few places. So I am quite happy to carry on doing that.The backwards compatbility aspect is a good comment, I had missed. So I will keep quite now I think the idea still has merit, and adding the Boolean suggested would keep everyone happy - I think you should still push for this if you think it's valuable. Quote Link to comment
jgcode Posted January 12, 2012 Report Share Posted January 12, 2012 dannyt: crelf's idea is really good and I concur - we could proceed with this change to the VI and everyone is happy (and backwards compatible). Now anyone feel free to comment on the below: So... Functionally: this would occur inside the VI if the boolean was set to TRUE: Name: Ignore Incoming Errors (F) - with a default of false Input Type: Optional CP: Add input here Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.