How to Polish Your Software and Development Process to Wow Your End Users
Track/Summit: Software Development Techniques
Session ID#: TS1765
Abstract: Hear from LabVIEW Champion and LabVIEW Architects Forum Founder Fabiola De la Cueva about five "little things" that can improve your application's usability and create happier, more productive end users. From easy ways for your app to look and feel like a "real Windows application" to subtle features that can make every application template easier for developers to use, explore the secrets that professional LabVIEW developers use to make their lives, and their users' lives, easier.
Speaker(s): Fabiola De la Cueva, Delacor
Video of the presentation can be found here: http://youtu.be/PzeyShod52s
Thanks to Mark Balla for taking the video.
I was recently interviewed regarding this presentation, you can hear it at VI Shots: http://vishots.com/five-ways-to-improve-your-labview-applications/
Also, Steve Watts presented a version of this presentation at NI Days UK and has been writing a series of articles related to this presentation here: https://decibel.ni.com/content/blogs/labviewramblings/2013/11/24/rapid-modification-and-debugging
And I will be presenting an updated version of this presentation in French at NI Days France: http://france.ni.com/nidays
Great Presentation! There is a reference to XX--Constant.vi in this presentation. This looks interesting, but what is it? Thanks!
Hi Michael,
Glad you liked it.
The XX--Constant.vi is the way I get around at having a global that is read only, there is no temptation to ever writing to it. On page 38 of the pdf there is an example where the Application name is saved in a Constant.vi. In my presentation I proposed that all "variable" constants should be in a configuration file (A "variable" constant is something that is constant now, but the person defining the requirements for the application might change their mind and change the value).
However, there are certain things you don't want your users tampering with or would require a change in your application. In those cases, I use a VI that all it has is the constant wired to an indicator. This has several advantages:
1) If there is a change, there is only one place to go make it. In the pdf example, the name of the application has (Beta) appended at the end. Once the application releases, we will remove that (Beta). This VI is used to change windows titles, select application files directories, in dialog boxes, etc. We don't have to go hunting down all the places that it is used at, we just modify the Application-constant.vi and we are done.
2) It is easy to find all the places a constant is used at, just right click on it in the project and select "Find callers"
3) If there is code required to modify the constant, there is only one place to do it. In the Application name constant, perhaps one would want to add the version number appended at the end. Well, there is a single place to make that change and since this is a VI instead of a Global, it can be done.
4) If you need to add error terminals, it is easy
There might be other advantages, but those are the ones I can think of from the top of my head.
Let me know if this makes sense to you.
Regards,
Fab
Fab,
Thank you, it makes sense. In my experience constants are evil as they are rarely 'constant' through the life of an application. This is a good alternative.
Michael
Michael,
Oh!, and one more thing for those who say we are taking a hit by calling a VI, just mark your Constant.vi as inlining and it is the same as having it directly in the code.
And you are right, constants are evil! When they change, they can create bugs that are very difficult to track down.
Fab
Fab"Good programming practices have nothing to do with marital status"
I will say single or not small project or large project .A Pro Developer should use Source code Control.
Thanks Fab for the Message.