LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Not a good setting for API?

Solved!
Go to solution

Which is not a good setting for an API in LabVIEW.

  • Disable automatic error handling,
  • disable icon resize for front panel,
  • run enabled when open
  • OR default window appearance?
0 Kudos
Message 1 of 13
(2,263 Views)

Hi FMC,

 

what do you think is annoying when you would use an API/library developed by someone else?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 13
(2,226 Views)
Solution
Accepted by topic author Fresenius_Medical_Care

@Fresenius_Medical_Care wrote:

Which is not a good setting for an API in LabVIEW.

  • Disable automatic error handling,
  • disable icon resize for front panel,
  • run enabled when open
  • OR default window appearance?

  • Of course you ran all of the Unit Tests on your well documented API so debugging is not helpful at all because you wrote no bugs
  • I'm not sure how you could resize the icon on the front panel. The FP and Icon are separate parts of a vi.  Your Library and API should be in a SCC location and the user's "Should" (see signature line) enable the LabVIEW ini token to treat read only VIs as Locked preventing silly cosmetic changes anyhow.
  • Most of the window appearance settings are run-time writable and I am of the opinion that the VI itself should change those settings as needed only when running.  I bet you can find a copy of my Champions Tip of the Week "Avoiding the Three-Finger Salute" with a Google search. 

So, bullets 1, and 4 are excellent practices for API development and bullet 2 "Should" be pointless.  So, I'll ask the hard question. 

 

Why, oh Why would you ever set an API VI to Run when Opened? How would the using developer read the documentation in the FP controls and indicators Tip strips and descriptions? Or the free text usage information if the VI just started executing wherever the user opened the VI FP?


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 13
(2,199 Views)

I really don't understand the point of your questions without having more background.

 

Maybe start with defining what you mean by "API", because it seems to conflict with the common definition of the term, then explain what kind of API you are trying to write and its targeted use.

 

 

0 Kudos
Message 4 of 13
(2,176 Views)

Hi

This looks like a question NI could ask in a CLAD exam.

Is that right?

greetings from the Netherlands
0 Kudos
Message 5 of 13
(2,158 Views)

Since Bob Schor will continue to ask how I handle FP vi properties....

 

Here is a link to a document that once existed in the abandoned FAQ area of the discussion forums.  Linked from here 

And attached in the original docx which, IIRC, contains an embedded object 2012 snippet of a replacement for TBD Core.vi (the core vi underneath the shipping version of Three Button Dialog.vi)  It should have been updated to be a malleable VI and TBD Core.vi obsoleted, but AQ never got around to it. 

 

As a salient point, Three Button Dialog.vi, breaks several best practices for an API VI.  Everyone can always learn, grow and improve.


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 13
(2,133 Views)

Hi Jay,

 

I was leaning more towards "Disable automatic error handling" as I feel it will make the VI non-responsive if there is an error which will act like a modal VI.

Your point of view make sense, but is "run enabled when opened" same as simply run when open?

I feel it just enables the run icon and doesn't run the VI?

 

0 Kudos
Message 7 of 13
(2,111 Views)

Hi Alten bach,

 

Thats exactly my point.

As Albert responded in his post, this was a question in CLA-R exam which I have unfortunately failed a number of times now.

They didn't provide more info on this.

Given the options which one and why do you feel is the best answer?

 

0 Kudos
Message 8 of 13
(2,109 Views)

Hi Gerd,

 

It will be Error pop-ups 🙂

Then is it disable automatic error handling?

0 Kudos
Message 9 of 13
(2,102 Views)

The wording sounds a bit off but I HATE, and I can't emphasis that enough here, with a passion anyone who tries to set his VI to run when opened. For a function library (or API) that setting makes even less of sense than for other VIs.

 

point 1 can be useful, your software library should ideally not require the user to debug inside it and all possible errors should be either properly handled or purposefully ignored. I do often use disable error dialogs in VIs, AFTER they have been intensely debugged and tested. The error dialog can be annoying but in a properly developed library there should be no unwired error out in most cases although I can understand that having to connect Clear Error functions to intentionally ignore error outputs can be sometimes annoying.

 

point 2 sounds to me like a trap, there is no resizable icon in LabVIEW so not sure how you could even disable that.

 

point 4 is nonsense, your API functions are not supposed to open their front panel at runtime so the window appearance settings are meaningless and should really be left at their default setting, if they are not I would consider it a minor annoyance but it's not a problem either.

 

Unless you did not choose point 3, this question was not where you went wrong.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 13
(2,051 Views)