@dotNet_to_LabW: thank you RB for your sympathy and kind words. I don't want to waste your time but I'll just answer the few little questions in your reply.
I said "It's not easy", what I meant was that digging into the DLL to find a low-level function like, say, "SetGainForAnalogueInputPin0 and then don't let anyone else touch it before I make an acquisition" would not be easy. I was trying to describe the effort of calling into NationalInstruments.DAQmx.dll directly from TestStand.
"not documented" means that the documentation exists for the functions which NI wants us to use, but the really low-level ones are keps internal, so that they can be modified (for example to suit updated hardware) without breaking the documented functions/classes.
"not easily maintainable / re-usable" means that somebody coming after me would have to climb up the same learning curve that I did. (If I write some Step which calls a really obscure function in the driver I mean.) They may not be able to just look at my code to understand how it works, or what it is supposed to do, or that NI has just changed the class name. This is an important part of my work, because I am contracting, so I need to leave the project where someone else can pick up easily from where I finished.
My "choice of tool" has essentially been made by my situation. I am currently with a high-tech company which uses C# for most things so it would be easy for any of them to come along and fiddle after I have gone. I am one week from the end of a 2-month stint here, and I need to "get the job done". Without these constraints, I would be using LabWindows, but I am grateful for the chance to get to grips with TestStand: I intend to follow your advice and persevere with it in the future. I appreciate your comment "there is a level of inacceptance in the beginning".
Thanks again for your support,
James.
