Omar Mussa

Elijah Kerry created a great post about how to setup SSL for Web Services here.

I'm using Data Value References to my LVOOP objects and finding that one major pain point is that I can't dynamic dispatch using Data Value References. This results in me creating a lot of public byRef VI method wrappers to protected byVal methods in order to get the dynamic dispatching benefit of LVOOP. I asked Stephen about this at NIWeek and he mentioned that the rationale for not allowing dynamic dispatching was going to be updated on the 'Decisions Behind the Deisgn' document -- but I couldn't find the rationale so I'm basically asking again here for public benefit. Is this a feature that could be implemented in the future or is there something fundamental that prevented this from being implemented?

Congratulations!

I have some suggestions. One thing you may want to look at is Endevo's UML modeling tools. They have some interesting ways to document state machines, but this is more useful for modeling state transitions as opposed to state inputs. Another thing you should consider is the design of your actual states. I may have just not looked hard enough, but it looks like you evolved into a pattern where you are passing your entire state machine data cluster in/out of each state VI. This is actually contributing significantly to the complexity of documenting your API. I would suggest that you consider changing your API to VIs within each state in some way such that you are no longer doing that. You might consider moving to a different state machine template. I will make a shameless plug for our own JKI State Machine as its free and has received a lot of praise by the LabVIEW community (although it may not help you solve this particular aspect of documentation, you will find it has a lot of nice self documenting aspects related to state organization and it integrates with the Endevo UML tool as well).

Nice work!

You actually could make a RCF plugin for this one

It depends... Is your cluster also a type def? - if you edit the type def, you may lose the string array constant data. Even if it is not part of a type def, editing the cluster could result in your string data being lost. You may want to change the way you are initializing the data -- either loading it from a file or manually bundling in the data to prevent changes in your cluster from affecting the string array values.

Unfortunately, we don't have anything to show yet because mostly we have design patterns that still need to evolve a little before they can become 'tools'. Generally, what we have done is utilized Windows API calls for keyboard and mouse emulation and used control references to validate the properties of UIs that we care about.

Part of test driven development will always come back to design. One of the key benefits of unit testing in general is that it forces you to think of your code in terms of APIs. Your unit tests are actually testing the API to your internal code. If you can't test your code without hardware, you don't have a good API to your application logic code. There are different ways to enable simulation: Adding a simulation input (or property), using LVOOP and inheritance to create a simulation implementation of an abstract class, etc. Creating unit tests forces you to think about your code's interface at an early stage (or even at a later stage when you may need to refactor code and want to validate that it isn't broken). One thing that I think works particularly well in VI Tester is the ability to use the test harness (VIs that are called before and after each test) to do things like set a simulation flag so that your tests run your VIs in simulated mode. At JKI, we currently are able to do UI testing using VI Tester and are running these tests to validate certain VIPM features. Adding UI testing capabilities to VI Tester is on our roadmap. I really recommend that you investigate whether VI Tester would meet your needs, trying to create unit tests without a framework is a fairly arduous task and will ultimately cost you more time than investigating tools that already exist. You may as well leverage the years of effort that have gone into the existing tools rather than start from ground zero. Besides that, VI Tester is free, so there really isn't a barrier to entry

Maybe I should have had 2 options -- 'None' and 'What's a unit test?' ... polling is a tricky thing to do right I guess.

Here's a reference on what unit testing is all about: http://en.wikipedia.org/wiki/Unit_testing My summary is this: unit testing is a software engineering process for validating that your code functions as expected. You basically write tests to validate that your code works as expected, if your tests fail then you update your tests or your code until they pass. If all of your unit tests pass, then you have a level of assurance that your code works as you expect (as defined by the unit tests). What is useful about unit testing is that if you need to change your code (say, to make a sequence into a state machine), and you have created unit tests, you can validate that none of your changes have caused you to 'break' your previous logic simply by re-running your unit tests. In order to make you application logic more easily testable from your hardware interfaces, you may need to consider how you will test your code when you design your code. For example, you may want to create a simulation mode or abstraction layer that lets you test your application logic with unit tests, independently from your hardware interface code.

Just wondering what kind of unit testing frameworks LAVA members are using.

Looking at the Skype model, the user only enters text into the input box, the graphic is only rendered in the chat/history.

And now you're waiting can end http://decibel.ni.com/content/groups/jki-right-click-framework-for-labview

Congratulations!

Your best bet may be to use a listbox instead of a string indicator. This would make coloring each line trivial. Check out our JKI tutorial based on how we alternated colors for VIPM.

I never really posted in the LAVA Lounge before, but since its LAVA 2.0, I decided that I need to reinvent myself as well http://www.collegehu...m/video:1913584

QUOTE (Val Brown @ Jun 5 2009, 11:00 PM) It is a JKI Product, it is separate from OpenG. You can find the requirements here. The tool does require that you have VI Package Manger installed. The installation instructions for the TortoiseSVN tool are here.

QUOTE (Ic3Knight @ Jun 5 2009, 12:55 AM) We don't use locking at JKI and we haven't had any issues - whenever there is a conflict (which is fairly rare), we manually resolve the conflict. Generally, the best way to avoid conflicts is to be careful about doing mass compile save all type of operations that result in a ton of VIs that have *changed* because it may interfere with other developers when you commit. Also, in case you haven't noticed, we just released a new http://www.jkisoft.com/tortoisesvn-tool/' rel='nofollow' target="_blank">TortoiseSVN tool for LabVIEW. It provides really tight integration of TSVN with LabVIEW and is really well suited for the update/commit SVN model.

QUOTE (Yair @ Jun 4 2009, 11:23 AM) JKI started recording our presentations last year and will definitely be doing so again this year. Here's a link to last year's (2008) JKI presentations at NI Week: http://jkisoft.com/niweek/2008/

There is actually a method for updating cell data for a table. Use an invoke node and you will find it. It allows you to update a single cell without updating the whole table.

I added my response on the JKI Software Forums.

QUOTE (ShaunR @ May 9 2009, 03:37 PM) While you can choose to wrap every function into class methods, that is not usually an abstraction method that works well. What you should do is consider what things you tend to do over and over again and create abstractions for those items. For example, let's say you want to create a DMM class that supports Agilent and NI DMMs in your application. Both of these DMMs have completely different drivers required for configuring a voltage measurement, but essentially, they both perform the same operations. You can create a DMM.Configure Measurement method with an Agilent (Agilent.Configure Measurement) and NI (NI.Configure Measurement) implementation (and Simulator, and future hardware you haven't yet purchased, etc). What's nice is that you separate your application logic from your instrument specific drivers that 'implement' that logic. This is what object-orientation is all about -- irrespective of Daklu's 'Extraction Architecture'. Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

QUOTE (hooovahh @ Apr 16 2009, 05:37 AM) I'd have to say that NI has done a decent job lately (last few years) of creating tools that are aimed at their existing customers. I'm not actually using these toolkits right now, but if you look at the state-charts, execution-trace, unit-test, etc. they are not targeting any of those toolkits at "new" users of LabVIEW.

The easiest way to do this is to use the JKI EasyXML toolkit. You will save yourself a lot of time. You can find more info here: http://jkisoft.com/easyxml/ Let us know if you have any other questions.