What is the best way to handle having a Pre and Post Install VI call, that has dependencies on other VIs that either might not be installed yet, or other subVIs that aren't part of a reuse library?
For instance I have a Pre-Install VI and it uses some OpenG functions. The problem is I suspect it is possible that the user hasn't installed the OpenG functions yet. It might be a dependency of this package being installed, but I assume it can't be guaranteed what the order of install is, but maybe I'm mistaken and this isn't a problem.
But the second issue I have is my Pre-Install VI has a few subVIs, that aren't a part of the project. When building the package I don't think these subVIs are included, and when the package is being installed the Pre-Install VI is called and I see the searching dialog trying to find the subVIs in a temp folder which is where I assume the Pre Install VI was extracted to and ran.
Should subVIs in general be avoided in Pre and Post install VIs? Should they work as expected but for some reason mine crapped out for an unrelated issue?
So at my previous company we made our own QMH+. I thought about using the JKI but at the time I thought arrays were superior to a string that has return characters in it. My reasoning for this was figuring a delete from array would have less over head than the Parse State Queue which has lots of string manipulation. I'm not sure I care so much and a single string is probably just fine. But for the record I'd prefer an array of string.
Another difference I had was all state machine loops pushed data to a central DVR in a functional global. This of course could have a taste of OO but at the time it didn't. What this allowed me to do is have a way to access all loops in an application that were running. So when my VI was running I could go to Tools >> Debug QMH and a window would come up showing me all state machines being ran, what states were being enqueued and dequeued, along with the delta time between each step. This way I could see how much time each state machine was in each state. This helped improve speed by finding where the states taking the most time were.
This DVR Global also had the ability to log this state changing data from state machines. Then even if my application crashed I'd have a log of what states each loop went to leading up to the crash.
The ability to log, or probe a state machine could be turned on and off using that same DVR global. By default both log and probe were off for efficiency. But this could be turned on from the built EXE by going to Help >> Debug Application >> Debug QMH which called a VI that I made to enable or disable these debugging features.
The JKI state machine is simple by design. So I'm sure it is difficult to say how many features you want to pack into it. And some of the ones I mentioned might not seem like a good fit. But I just figured over the last 7 years the state machine could use some kind of tweaks or improvements.
It is a known issue that the current JKI state machine uses deprecated functions for the Front Panel Open? Is this an issue that needs fixing?
The latest version of the state machine was released in 2008 according to the copyright on the package information. So is there plans to update this state machine to use non-deprecated functions for modern versions? This would also be a good time to add any features and updates in a new release.