Custom Device development does not have a very good design/develop/test work flow. To improve this, the custom device template tool needs to be rewritten so that it better incorporates design before creating the project/library/VIs.
In order to better incorporate design into the process, I envision a custom device template tool that is configuration based. From this tool, a developer would be able to specify the pages, actions, RTM, dynamic buttons, help topics, and glyphs. The developer should also be able to specify any options the custom device or a given page, RTM, or button may use such as multiple target support RT driver VIs, delete protection, rename protection, RTM/button dependencies and behavior, etc.
Once the developer finishes designing the custom device, the XML should be fully implemented and all the necessary VIs (actions, pages, RTMs, etc.) would be created in the library. This would greatly cut down on the overhead of creating new files from templates and modifying the XML over and over. It also encourages developers to do more design of the custom device up front instead of designing while they code.
For completeness, it would also be nice if the tool had the capability of linking into Requirements Gateway or something so they could do requirements tracking. I'm not sure how this would work, but it's something that maybe should be investigated.
The final aspect of this idea is that there is a need for better testing of custom device developments. I find it difficult to do good tests because my code is always tightly coupled to Item Properties or other things that require VeriStand references. I think this tool could also script some high level test code that would be able to run the pages or RT driver VIs outside of the VeriStand executable. In order to accomplish this, I think VIs could be developed that use the SysDef API to load system definition item information outside of the VeriStand executable so that the references could then be passed to the appropriate page or driver VI. I envision the test VIs are wrappers that wrap up the page, action, RTM, or driver being tested. In the case of pages, the custom device would need to be added to a SysDef and the Init VI would need to be executed. Some pages would also require the section or channel being added to the appropriate section or channel as well. If the configuration tool could script most of this work, I think it would be very helpful.
Regards,
Mike
) so there is actually no need in this particular case to span two media.
