John Lokanis

If you are passing control refs from your UI FP to your core engine, they you have a strongly coupled UI, not a decoupled UI. The better solution would be to setup a messaging system where the core engine tells the UI what the new data is and then the UI takes that and applies it to the actual controls. That way, you could completely change the UI to display the data in any way you wish without touching the core engine.

I'm not saying I don't pass refs in some of my code, but I acknowledge this is a coupling issue I want to avoid in future designs.

I would say a truly decoupled UI would be one driven by an API that is not limited to LabVIEW. In other words, using something like Web Services, you could build your UI in LabVIEW or HTML or C++ or any other language and interface to the underlying engine via calls.

There are other options to this of course.

I think a good first start would be to separate the UI code from the engine code so your low level logic does not access any GUI elements. This could be done by using queues, events or other messages to communicate state changes and user actions between the UI code and the engine.

Next, you need to ask yourself what the physical channel will be between the two. If you will be on the same machine in the same app instance, then you can use queues and events. If you plan to be across the network, then some other method will be needed (web services, raw TCP/IP, network streams, share variables) and if your UI is not going to be LabVIEW, then you narrow yourself to web services or something like web sockets (http://www.bergmans.com/downloads.html).

Overall, decoupling now can allow you to pursue these options down the road more easily.

Lastly, you need to consider if you will build a client server model where multiple UIs can interact with a singe engine simultaneously. That is a harder nut to crack...

Any opinion on the NI Unit Test Framework vs the JKI unit test package?

(I have one licence for the NI version but need to pick one before getting everyone licensed)

Thanks for all the feedback. So very good points in there to consider.

Regarding PPLs, I currently package my plugins into an LLB using the OpenG builder. I do this to make them distributable. Essentially they become a 'dll' at this point, allowing me to install them on my target machines. The advantage of this is all the VIs used by the plugins are included and name-spaced at the time of the build so that I can never have a conflict with a similarly named file from another LLB or part of the code. The other advantage is I can pull from the same pool of reuse code for all plugins and I only get a snapshot of the VIs at the time of build.

The disadvantage is I am using a non-standard build tool (OpenG builder) and I want to separate my source from OBJ (new LV2010 feature) and I don't think that will work with the OpenG builder. I was hoping the PPLs would give me the same functionality that I get from these LLBs. For those of you who have had issues with PPLs, can you give me more details or reference some CARs so I can see if the bugs will affect me?

Regarding unit testing, my goal was to apply this to my reuse code. And I have a lackey I plan to utilize to write these. :-) The hope is this will make the reuse libraries more robust and ensures they continue to work as expected since everyone will be using them in their projects.

As for re-write vs re-factor, I plan to branch my code and develop the new version by editing the existing code. But, I need to continue to maintain the existing code while this re-factoring takes place, so I will be pulling existing code over from the branch and using it in the new version if it fits. This is not a total rewrite from scratch, all the functionality that exists will remain. Just the methods used to achieve it will be upgraded to more modern and best practices. I don't plan to release any of the new code to production until the re-factor is complete. And just so I am clear, this is not just about changing the code to use OOP but rather about changing the DEV process to project better software in a team environment instead of the lone LabVIEW ranger (me) cranking out code as fast as possible. I want to be a real CLA, not just a CLD on steroids...

And finally, I hope the end result is code that my whole team can understand and maintain, not just me. Yes it hurts job security but it allows me to build an efficient software dev environment that I and my team will benefit from for years.

I think when I am done, this will make a great case study to present at NI Week 2012.

Here't the first thing that crossed my mind as I began reading your post - Things You Should Never Do

Good point. But I don't plan to start from scratch. Just re-factor, reorganize and apply best practices. The original code works great for us but only one person really understand it and can maintain it. We started with best intentions but deadlines forced the usual shortcuts. And fixes and features were added over time but not in the most elegant way since they were not architect-ed in the first place. The goal here is to look at what we ended up with, convert it into a set of requirements and then alter the existing code (and rewrite parts as needed) using best practices and a team of developers. The end goal is a code base everyone understand and can help maintain.

Oh, and since the system is working now, we have no deadline, so we can take the appropriate amount of time to get it done right.

To that complex I'd also put in a new tool: bug-trackers. You can misuse them as feature trackers as well. Integrate them with the SCC seems important.

I like this idea. Our company uses Bugzilla. I will have to look into how that can integrate with Perforce and LabVIEW. I am sure the text coders have already sorted this out so I will have to learn from them.

I have an opportunity to take an existing large project and re-architect it from the ground up. All options are open to me. So, I want to apply all the latest and greatest tools and techniques to build an eco system for my code and my company that will make this project and all others after it easier to maintain. I would like your thoughts on what things work and what are not worth the effort. Some ideas I am considering are:

Change the code to use LVOOP design patterns.

Organize all my reusable code into distributable packages (VIPM?) that are available in the palettes.

Add unit tests to all (or most) of my code.

Integrate the Diff and Merge tools into my SCC system (Perforce).

Use the GOOP Dev Suite to generate UML from my code (and vice versa) for doc purposes.

Use Packed Project Libraries to distribute plugin code instead of LLBs.

And on a more technical note specific to my project: decouple the UI from the code. What I mean is instead of the UI being a FP of a VI, implement it as a web page (using the UI builder?) and have that interface to the code via web services. This might be too radical to do right now...

So, please let me know what tools and techniques you use that work well in large applications with multiple devs. I want to try to be as state of the art as possible since I doubt I will get another chance to do this again.

-John

Just bumping this so it get noticed. I tried to update my profile and could not select LV2010 either...

That would be one heck of a URL string for all 28 inputs. Here is a more elegant solution. In LV2010, you can create web service VIs that will persist beyond the first call in memory (when setting up the VIs as source files, there is an Auxiliary VI setting). Using this technique, you could create several VIs and split the 28 inputs amongst them. These web service VIs would be called first and would store the input values. Then the last one or a later one could be used to 'execute' the function.

I managed to get this class in Seattle next month. And, I see NI lowered the price to $1200. If you are in the Seattle area, come join us on Dec 13th, 2010. We also scored one of the best instructors.

I just released my 2010 build to production so I should soon have an answer for you. So far, so good.

try putting the DLL in the same folder as the EXE or in the data sub folder. This worked for me in past versions. Also, make sure you have the iak file included in your installer.

And replace 1 small insignificant bug with 20 whopping huge ones

Yes, well I'm not satisfied unless I get at least one CAR issued a week. I think OOP will help me out there! (And I am going to be taking the LVOOP class soon so I look forward to putting it to use)

Nope you are right (only 1/2 a rep point then ) When I launched your example (dbl clicked) it switched to 2010 instead of my usual 2009.

Doh!

Well, in the end it turns out the bug is only associated with the 'Include Data Type' setting on control references. It has nothing to do with 'Strict Type Defs' afterall. Just confirmed that with the app support people. And the CAR# is 251234 for future reference.

Hope this one does not bite anyone else. Luckily, I was able to find a workaround.

Next time I will write my app in OOP and try to avoid these issues of getting data via VI Server methods. (this app was written a while ago when LVOOP was just a twinkle in AQ's eye...)

Your example of the 2009 also fails on my 2009 SP1 (error 91). But if I remove the strict type it works again.

All I can do is show you this. Note the run continuously and that the include data type red stars are present and the version of LV is now displayed. Must be something wrong with your version of LV2009SP1 or mine. Can anyone else confirm this?

If you uncheck "Include Data Type" on the VI server reference classes ( Run, abort. Text display tree etc). It works.

And if you save it to 2009 and add the "include Data Type" it fails. A default setting has changed maybe?.

Ok, so removing the include datatype fixes the issue. And adding back the strict typedef setting has no effect. So my bug is the 'include datatype' problem. FWIW, the original with all the data types included and the strict type defs still works in 2009SP1 (this has been in my code since 8.2 and always worked until upgrading to LV2010)

Here is the LV2009SP1 version where the datatypes are included and the typedefs are strict and it generates no errors.

Variant to Data bug 2009.zip

But NI did find a bug with the strict type defs. Here is the example from NI support where they demonstrate the strict typedef bug using simple datatypes:

7299252 Variant to Data bug.zip

I might get two CARs out of this one. Nice...

In the process of investigating this, it appears that NI found another bug. If you try this with simple typedef'd datatypes, it also fails if the datatypes are strict. It works if they are not. Unfortunately, making all the datatypes in my example non-strict does not fix this. So, beware of using the Control Value.Get with strictly typedef'd datatypes.

Still no CAR# yet.

It is looking more and more like a real bug. If I get a CAR# I will post it.

Now I need to find a way to rework my app to avoid the Control Value.Get method for complex datatypes.

Just sent this one to NI but thought I would post here to in case anyone had any ideas. See the att zip for a simple example.

It appears that the Variant to Data primitive *or* the Control Value.Get method does not like to work with complex typedef'd data.

This used to work in LV2009SP1 but now give me error 91 in LV2010.

Has anyone else run into this?

-John

Variant to Data bug.zip

You should not be seeing the & replacements when calling the web service. Try calling it from IE or Firefox and see if you still get them. I don't with any of my web services. This could be a problem with the tool you are using to call the web service and not LabVIEW.

Any decent XML parser should know to convert < to a < character.

I have alway set these in my INI file:

appFont="0" 13

dialogFont="2" 13

systemFont="1" 13

HideRootWindow=True

blinkBG=000000FF

thanks for the font info. I guess I will need to find a way to detect the OS and go from there.

It appears that the font used by system controls has changed between XP and Win7. As a result, some character graphics (progress bars using ||||||||) that I used in tables and MCLB system controls no long fit the same. Does anyone know of a way to fix this? Di you even know what the font (and size) was in XP and is in Win7? I poked around but could not find it.

Sure wish we could embed data types and controls other than string in a MCLB or table.

thanks for any suggestions.

-John

thanks for the improvement ideas. I will give them a try. Perhaps this would make a good addition to the OpenG string functions?

you can import the snippet into LabVIEW and run it.

Wheel invented:

Let me know if you can improve on this.