Leaderboard

NI SRManager is now in the iPhone App Store. You can download it here: http://itunes.apple.com/us/app/ni-srmanager/id432100096?mt=8&ls=1 View and bookmark your NI Service Requests. You can read the service requests offline including (requires a service contract) notes from our Engineers. Features: - View Open and Closed Service Requests - Bookmark Important Service Requests - Call Support Directly from the App - View Account Valid Service Contract Required: - View Notes from our Engineers

Here is my proposition. Inspired by recent LAVA activity... However I haven't read that all And alternative version for the front, which is even more pure:

Information from the developer working on this: The token 'hierarchy.stateFlags' is used to enable/disable options in the VI Hierarchy toolbar. It becomes equal to '1' when Include vi.lib is on and Include Globals and Include Type def are off. I'm not sure, as of now, why it is affecting showing the class hierarchy. I'll debug it and update the CAR notes. I just checked and the problem is present since at least LV 2009. There is a better workaround to this problem which doesn't involve having to restart LabVIEW. Class hierarchy shows up fine when I right click on a lvclass in the Project Explorer and select 'Show Class Hierarchy'. I hope that helps. I don't think we can get this fixed in LV 2011 -- the report came in too late -- but at least you have a better workaround.

<Admin>Post Merged into this Topic</Admin> I recently tried the OpenG routine "Get Default Data from TD", hoping to be able to parse a cluster all of whose elements were "simple types" (numerics, strings, paths, booleans, timestamps). I discovered that presenting a timestamp to this routine resulted in an error 1, with the message complaining about a "waveform type". I originally thought this was a "bug", but now realize that it is a "missing feature". I had considered a Timestamp as a simple type, not realizing that LabVIEW considered it as a sub-type of Waveform. While I didn't want to implement code to handle "real" Waveforms (which are definitely composite types), I decided to add an "exception" to properly handle Timestamps. The fix is simple -- add a "Timestamp" case, test the cluster element "# Elements" (which is really "Sub-Type") for 6 = Timestamp. If it is a Timestamp, handle it as with any of the other simple types. If not, generate an error message (I changed the message to refer to "Unsupported Waveform"). My code now works with this modified version of the OpenG routine. Bob Schor