Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

design practices from the CLD Exam Prep Guide

    I have a question about design practices as stated in the CLD Exam Prep Guide found at   http://ftp.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf
    Please refer to statements

2.e.1. Set the value or attributes of a control, statically using the property dialog box of an object, or dynamically using Property Nodes.
2.e.2. Initialize or set control values at application, load, start, and stop.

4.a.4. Use local variables to update controls.

    Because the words initialize and set and update all mean to change the value and two different methods are suggested to do so, I first saw this as contradictory.  Assuming there is no contradiction, it should be very clear when, where, and why each method is used.  
    From section 2.e I understand this to mean you should change (set) a control value at application, load, start, and stop by using Property Nodes.  Thus, application, load, start, and stop shall be clearly identified within your block diagram to avoid misunderstanding.  
    From section 4.a I understand this to mean you should change (update - as you might do repeatedly within a while loop) a control value by using local variables everywhere else in your block diagram.  If I understand this correctly, there is no contradiction.  Otherwise....

 
Please advise!  Scott Pierskalla
Certified LabVIEW Associate Developer


0 Kudos
Message 1 of 5
(6,486 Views)

I agree with your interpretation.

 

Startup values/appearance should be set either (1) pre-execution from the Property Window or (2) dynamically using property nodes.

 

Local variables should be used for repeated updates (at somewhere other than startup/shutdown). This might be broadened to state that it's better to use a local variable when you're only modifying a control's VALUE rather than appearance or other settings - a property node is overkill in that case and processor-intensive.

0 Kudos
Message 2 of 5
(6,484 Views)

@spiersk wrote:

    I have a question about design practices as stated in the CLD Exam Prep Guide found at   http://ftp.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf
    Please refer to statements

2.e.1. Set the value or attributes of a control, statically using the property dialog box of an object, or dynamically using Property Nodes.
2.e.2. Initialize or set control values at application, load, start, and stop.

4.a.4. Use local variables to update controls.

    Because the words initialize and set and update all mean to change the value and two different methods are suggested to do so, I first saw this as contradictory.  Assuming there is no contradiction, it should be very clear when, where, and why each method is used.  
    From section 2.e I understand this to mean you should change (set) a control value at application, load, start, and stop by using Property Nodes.  Thus, application, load, start, and stop shall be clearly identified within your block diagram to avoid misunderstanding.  
    From section 4.a I understand this to mean you should change (update - as you might do repeatedly within a while loop) a control value by using local variables everywhere else in your block diagram.  If I understand this correctly, there is no contradiction.  Otherwise....

 
Please advise!  Scott Pierskalla
Certified LabVIEW Associate Developer



Scott,

Thank you for drawing my attention to this thread.  I understand your confussion but, there is no contradiction.  I will attempt to clairify the statements.

 

Section 2 addresses design of the GUI or, how to set up the user experience.  Several questions any developer needs to ask are:

  • Is the data represented correctly? (what data type is needed?)
  • How will the user change this data? (Enum / Ring / Combo box pull-down, maybe the increment / decrement buttons, Perhaps direct text entry from the keyboard? If so do we wish to update value while typing or end text entry with "Enter"?)
  • How can I make it "Pretty?"  (What colors are approachable, how can I present logical groupings of the data the user needs....?) 
  • ......

Section 2 is all about the user.  Your application will be used by users and, they need to interact with your product.  Design the interface correctly and they will never notice, design it poorly and they will wish to break you nose because the software just does not "FEEL" right.

 

Section 4 addresses Programing practices.

  • Avoid Localitis
  • Avoid sequenceitis
  • don't ABUSE Globals
  • use common design patterns

Basically "Write Software" not "Functional spaghetti code"

 

Writting "Good Software" in LabVIEW is one of the things that CAN BE DONE with LabVIEW.  Unfortunatly, because LabVIEW is often approached by people with no understanding of Software Engineering principals, many LabVIEW applications fall into the "Functional Code" bucket and are poor "Software".

 

The CLD exam will require you to domenstrate that you can apply software engineering principals in the LabVIEW IDE.

 

Good Luck-  Sling some wires!


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 5
(6,469 Views)

Thanks for your response Jeff.  I appreciate it.  Please pardon me as I persist.

 

Please let me address my specific concern directly as perhaps I should have the first time; limiting my question to control values.  Again, assuming no contradiction, and your support of that, now my interpretation is...  Part of 2.e.1. states you can "Set the value of a control dynamically using Property Nodes.  However, because this is part of the GUI setup, using Property Nodes to change a control value is acceptable (or perferred) over using a local variable and thus, this does not conflict with 4.a.4. which states "Use local variables to update controls".  In these sections of code the use of Proerty Nodes to set a control value is infrequent and therefore relatively insignificant so using a local variable to perform the same task is not necessary to save processor time.  
    In other words, they did NOT intend to state the following...

2.e.1. Set the value or attributes of a control statically using the property dialog box of an object, or dynamically set the attributes of a control using Property Nodes and/or dynamically set the value of a control using local variables.

    Do I understand the original intent correctly now?

 

Thanks for your time and consideration.  Scott Pierskalla

Message 4 of 5
(6,445 Views)

NO

 

Sorry to be harsh Scott (And I do admire the persistance)  But you missed the difference in the words "Attributes" and Values" (only one attribute)

 

For instance a string control may require Text.Color to change dynamically (Use a P-Node)  a DBL may need to display relative time (use the property pages)   Using a p-node to set the value of a control requires a switch to the UI thread and SHOULD be avoided as long as you are race condition safe.  If you might introduce a race condition by setting a control value property with a local your GUI is somewhat overcoupled to your data, wiring to terminals is still prefered, but Locals are not evil they are just easilly abused.   If you find yourself useing them a lot consider redesigning your data transportation.  If you infrequently update a GUI control value via Local or read a GUI indicator value via local you are not in the wrong.

 

Race Condition Safe,  very seldom happens in larger applications.  This is why we have GUI Controllers and GERMs.  The CLD is not a large application and selecting a stratagey that requires considerable effort may not be possible within the time constraint.  4 hours for a small project.  The time requirement IS a requirement-  Scalability to infinity is not a requirement (Oh, THAT lament of mine again?)  Oh well - I still got my CLD on the second attempt.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 5
(6,432 Views)