IBerg

As one who has grown to love endevo's GOOP tookit and recently disappointed after re-acquainting myself with LabVIEW's native oop features (which still seems like illegitimate OOP to me, but I am biased due to coming to OOP from C++ background), To put it mildly I was dismayed by the native default by-value behavior but like teh by reference capabilities of this DVR Active Object architecture much better. Thank you for posting it! One thing I noticed about the pump example is if you follow commanding the pump to pump a volume by any other action on the front panel which invokes another command being sent before the pump finishes, the timeout set in Process.vi won't have time to expire. Not having had time to expire is maybe ok if the next action was turn pump on, or turn pump off, but problematic if the user had simply hit 'Pump volume" again. Did you really intend for a double-use of either pump's "Pump volume' button to effectively turn the pump on indefinitely? If not, we get to the real question i am wondering about... what is the best way to fix it and yet preserve the elegant simplicity of this example? Handshaking (: i.e. disable and grey the "pump volume" button until a message comes back to say the time out has been reached sounds ... I guess within "process.vi" if the most recently executed command was "Pump volume" then the return message that triggers the re-enable would need to be sent as soon as the dequeue times out or returns any newly sent command (getting another "pump volume' would then be ruled out).

Note: I have removed my earlier attachments on this topic ... thinking that those interested in "Get LocaleInfo" or an example where "GetLastError" has been made to work, or an example where a dll function specified to pass multiple types of pointers is successfully called from LabVIEW with different argument types in different places in the same block diagram (hmm wonder why I couldn't find an example like that in NI's example finder? ), would rather see the cleaned up version of what works rather than the somewhat messy version of what didn't work. E-mail me if you really want to see the earlier attempts. (and consider getting psychological help :laugh: ) Download File:post-1165-1102611339.llb

But to get back to the original Wish, it would be nice (although probably difficult to design and implement) if it were possible to specify one (or more) "mappings" of where wires were connected on the original connector pane connections on the VI to be replaced with where the same wires should be connected on the new replacement VI's connector pane, so that using this replacement technique successfully would not be restricted to VI's whose connector panes matched perfectly. For each connector pane input on the old VI, the user could choose "Unspecified/None" or any of the new connector pane's inputs as its future connector pane connection on the new VI. Wires connecting to old points for which "Unspecified" was selected would be broken wires after the replacement was made. A case in point for the use of such a feature would be where I recently discovered near the end of a large project that I wanted to replace all instance of "Format To String.vi" with a floating point input with my own wrapper VI so that I could more easily make changes to future versions -- for example to specify that a user-specified decision could be used as the basis for the decimal point character selection, at least in certain components of the project, (rather than the Windows region and language setting). But there was no connector pane pattern that matched "Format To String" so the technique I outlined above would not work smoothly... every instance of of "Format To String" with a floating point argument had to be manually fixed. One might say that I should have wrapped "Format To String.vi" in a wrapper VI straight away, as soon as I saw how often it was being used.. but it seemed such a solution would have forced the computer to use a lot of data to variant to data conversions... or several seemingly unnecessary wrapper VI's for the various types of input argument lists.

Yes, this can be a valuable technique... especially when you have 1000+ Vi's in your project and then find that you need to make a change to something found in many of them! Of course, by carefully using an intermediate step, you can replace multiple instance of a VI with a VI that did not originally have the same name.. 1. Open the VI you want to replace, and all VI's on whose block diagrams all instances of that VI should be replaced. (If you only want certain instances to be replaced on the same block diagram, you have to make the changes manually) 2. Choose "Save As" to save it to the same name as the VI you want to replace it with, but in a different directory. 3. Next, open the VI you want to replace all instances of the VI with, and choose "Yes" for the "Replace VI's in memory" dialog. 4. Now if you didn't originally still want the old VI name, open the VI you have now replaced all instances of the old version with again, and save it to the actual preferred name and directory you actually want the calling block diagrams to look up when they attempt to load the replaced VI. 5. If you are aware that no other un-intended changes have been made on any block diagram (Check the list of Open VI's under "Window" menu item for any names with an asterisk indicating changes in progress), you can now use "Save All" to preserve all the changes to all the VI's! Success of techniques such as these often hinges also on maintaining a well-organized project file folder hierarchy and on knowing and understanding the option settings for the search path.... When working on large projects or especially when making a backup copy of a large project I typically remove all the default search paths such as <found vi> so that I can ensure that I am only working in the latest build's copy of the VI's ....not making changes in this month's revisions of the project that will cause last month's working version to break. I leave only the top-level folder of my folder hierarchy for the various components (collections of VI's in the project). I would recommend not using this technique unless you have an effective VI management backup/scheme in place and/or understand the consequences regarding how your VI hierarchy will be distributed on your hard drive before and after these changes.

There are many functions in the Win32 API for which error information is supposed to be retrievable via "Get Last Error". Is this do-able from a LabVIEW block diagram? Case Study: I have been able to call into the Win32 API for "Locale" information in order to retrieve such infomation as "What is the user's region?" "What is the name of the local currency?" "Does this locale use metric?" "What is the name of the user's language setting in their own language? in English?" etc. This was done by a simple wrapper VI to call "GetLocaleInfo" within "kernel32.dll" found in Windows\system32 ... well-documented on MSDN. But as with many functions in the Win32 API, an incorrect call's error information is to be retrieved via a call to "Get Last Error"... which supposedly (from my understanding of the documentation for "Get Last Error" stores the error information placed there when a function being called uses "Set Last Error" to retrieve a numeric error code, which can then be passed to "Format Message" in order to retrieve a string describing the error. The documentation cautions that "Get Last Error" should be called "immediately" after a return value from a function call indicates that an error has occurred and that error information should be available. But when I try to do this from the block diagram, the GetLastError always seems to return 0, for the cases where I purposely make the inputs invalid (such as inputting TRUE for "return number" with an LCTYPE input beginning with S --- (only LCType inputs beginning with "I" are allowed to return numeric inputs). :headbang: To me this suggests that either LabVIEW itself makes another call to kernel32.dll (and/or other system dll's?) which succeeds, (thus clearing the error info) between the call to GetLocaleInfo and the call to GetLastError. Is this the best explanation everyone else has also? Has anyone come up with a work-around to help LabVIEW compile in such a way that these two calls occur more closely to one another so that the proper error information can be retrieved? The VI submitted seems to work adequately if it is reasonable to assume there will not be an error, but if LabVIEW could call GetLastError and have it work correctly, would this not make a lot of tasks easier to implement in pure G? :thumbup: Maybe it is not worth worrying about, since one of the advantages of pure G ideally should be platform independance which has already been lost the minute we use a Win32 API. But on the other hand, while platform independance would be nice, to date my application has not been targeted to non-Windows NT-based platforms anyway. Or maybe someone else has used "Get Last Error" in another context in which it works like it should, providing a useful point of comparison? Is it perhaps safe to say that the only solution to make a Win32 call with a GetLastError error output interface is to write a dll (or .NET assembly) in another language and call into that from LabVIEW?