NI Home
Cart Cart | Help
Hello Events Academic NI Developer Zone Support Solutions Products & Services Contact NI MyNI
You are here: 
NI Home > NI Developer Zone > NI Discussion Forums


Reply
Member
Scott.Pierskalla
Posts: 8
0 Kudos

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


Member
Mike_Le
Posts: 71
0 Kudos

Re: design practices from the CLD Exam Prep Guide

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.

-----

CLD 2012
Proven Zealot
Jeff·Þ·Bohrer
Posts: 5,318
0 Kudos

Re: design practices from the CLD Exam Prep Guide


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!


"All shall be well and all shall be well and all manner of things shall be well" -Julian
Member
Scott.Pierskalla
Posts: 8

Re: design practices from the CLD Exam Prep Guide

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

Proven Zealot
Jeff·Þ·Bohrer
Posts: 5,318
0 Kudos

Re: design practices from the CLD Exam Prep Guide

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.


"All shall be well and all shall be well and all manner of things shall be well" -Julian
By using this web site, you accept the Terms of Use for this web site. Please read these Terms of Use carefully before using any part of this site. Please go here for information on ni.com's copyright infringement policy.
My Profile | Privacy | Legal | Contact NI © 2011 National Instruments Corporation. All rights reserved.    |    E-Mail this Page E-Mail this Page