> code. I could use a sub vi as you suggested which would remove my > problems - but I was looking at creating a generic vi which developers > could use - clearly a sub vi could only contain 'generic code' and not > code specific to user requirements. As a first example I could provide > users with a sub vi approach - but only as an example as how they > could develop their own system. I am currently looking into geeting > the callback vi to generate a user event to signify that the event had > been handled which could be picked up by the main vi ... >
Sorry if my initial feedback was too abrupt. This additional info helps a bit with understanding what you are needing to do. You mention that a subVI could only contain generic code and not code specific to user requirements. I'm not sure I follow. Using the VI Server, you can load and execute dynamically loaded VIs from either LV or through ActiveX. This can allow for synchronous code that the user drops off by placing into a directory or registering through some other manner. Of course you can also use this as a way to synchronize with VI wrapped synchronization objects built into LV, or you can call system or third party synchronization from both LV using the DLL node and from your C++ code. Personally I'd go for the call unless you need notification during their execution and not simply at the end of the VI. Greg McKaskle
