Rick

QUOTE (Aristos Queue @ Sep 30 2008, 02:41 PM)

Try this: Write a dyn disp function on the parent class that takes in the object (the dynamic input) and an array of parent, and outputs an array of parent. The parent implementation does nothing. The one child that you're interested in does a Build Array to put the object onto the end of the given array.

Now call that subVI in a loop to build the desired array.

I can see how that will build onto an array of parent, given an instance of child, via dynamic dispatch. But my goal is a bit different.

What I want to do is essentially "find and extract" instance(s) of child XYZ from an array of parent, via dynamic dispatch. I currently have this working via brute force downcast type-testing, but I had hoped to use a more elegant solution.

QUOTE (Aristos Queue @ Sep 26 2008, 02:02 PM)

Using a dynamic dispatch method in every class is the recommended way of handling this, although the recommendation is to create a method that does whatever it is you're trying to do. I'm guessing that you're thinking of a dynamic dispatch method that returns a name or ID of the object so you can say, "Is it equal to this? Ok, then it must be this class..." and then you do Action X if it is that class. If you write a dynamic dispatch method ActionX.vi and then override it appropriately, you'll save yourself on performance and have much easier time for code maintenance in the future.

I have a question regarding a specific use of dynamic dispatch that is related to this discussion:

I want extract only one specific child class (call it XYZ) from an array of parent class, populated with multiple different sibling children classes. Is it possible in some way to use a dynamic dispatch parent method that is overridden by *only* a method of child class XYZ and use that dynamic dispatch strategy in a loop on the parent class array so that I end up with only the child object XYZ?

I can easily envision ending up with an array of parent objects intermixed with my child XYZ object, but I am looking for a way to avoid type-testing altogether.

Any hints/suggestions very appreciated.

-Rick

QUOTE (Antoine Châlons @ Sep 10 2008, 01:59 AM)

...having wire labels...

I third this! Votes++

An intrinsic tool that encourages (coaxes?) users/devs to document code is long overdue. Plus, it would solve the current auto-cleanup shortcoming regarding documentation placement.

QUOTE(Tomi Maila @ Mar 14 2007, 12:23 PM)

You should call your NI app engineer again and ask him not to provide you with wrong information

Could you elaborate on this? Do you have other info?

I *hope* there will be updates to LV8.2, but this info came from an NI rep....

QUOTE(JohnRH @ Mar 13 2007, 04:11 PM)

I am possibly (hopefully!) making an incorrect assumption. I inferred this from a recent post by an NI member regarding one of the recent bugs discussed in the LV8.2 bug forum. They mention that the specific bug mentioned will be fixed in the next major LabVIEW release. (I think it was the TDMS file reference bug)

I also wonder if the fact that they are already looking for beta testers for the next major release means anything regarding their intentions for interm releases.

I really hope that I am wrong, and that there will be an interm bug fix release. In the interest of not spreading incorrect rumors it is probably good that you questioned me on that. Perhaps it would be appropriate for an NI member to respond?

For what it's worth, I spoke with an NI app engineer trying to recover from the bug-induced: "bookkeep.cpp", line 887 error (mentioned elsewhere on this forum; more below) , yesterday. During that conversation I asked about the eminent quarterly service release (shipping very soon) and was told that there are NO LabVIEW-related fixes in this service release. The primary update being NI-DAQmx 8.5.

BTW, my fix for the bookkeep.cpp error was indeed (following the advice from this forum) to force the mass recompile by holding ctl-shift while clicking the run button. I believe this was caused when a typedef mysteriously lost it's link to the custom typedef control (it became greyed-out) and I couldn't get it to relink properly. NI is aware of this bug and noted that all reports of it had in common the use of dynamic-dispatch terminals in the project...

Rick

QUOTE(Herbert @ Mar 7 2007, 03:59 PM)

No, that's a rather embarrassing bug in the TDMS File Viewer. The good news is that you can fix it really easily. It's in a subVI called loadAndFormatValues.vi. This subVI contains a loop that first gets the NI_DataType, correctly as a U16. I think I must have copy-pasted this in order to read the NI_ChannelLength right after that, without changing the data type to U64.

All you need to do is go into this subVI, right-click the integer constant that determines the data type for "Get Properties" (the one that gets NI_ChannelLength) and switch the representation to U64. Obviously, this will be fixed in the next LabVIEW release.

The reason it works on the "Properties" tab is that we get the properties for this tab as variants. These are then converted properly. The "Get Properties" we use for the dialog that configures how many values you can see in table and graph have the correct U64 constant wired.

Hope that helps,

Herbert

Thanks, Herbert. Of course that did it and it was a very simple fix. Thanks, this viewer just became much more useful to me!

I figured that the use of variant was the reason that the properties tab was working, but didn't know the NI_ChannelLength value was U64.

Since you seem to be the author of this fine utility, here come a feature request:

It would be great if there was the NI-supported, intrinsic ability to view the data in an vector X vs. vector Y format, rather than waveform only. One obvious use of this would be plotting processed frequency domain data against a frequency vector. This would take the usefulness of this utility to the next level.

Thanks again for the support!

Rick

QUOTE(Herbert @ Feb 21 2007, 09:22 PM)

First of all, thanks a bunch to everybody for digging these issues up and giving all this feedback :thumbup: . I was out of office for a conference in Orange County :beer: so sorry for not answering right away ... but here we go.

1) TDMS refnums are supposed to behave like any other file refnum. The fact that they return "true" almost all the time is a bug. For further reference, the issue is filed as CAR# 46KIDFWJ and can be expected to be fixed in the next major LabVIEW release. There is no great workaround for that, the best you can do is using a function like "Get Properties" (without group or channel name wired) or "List File Contents" and see if it errors out.

2) The "Refnum to Path" issue indeed is a nice catch. Again, TDMS refnums are supposed to behave just like any other file I/O refnum. CAR# 46KII9WJ. Sorry for the inconvenience.

3) Casting the TDMS refnum into an integer and checking for not zero will not work just like that. The list of files can be sparse, so a non-zero number wouldn't necessarily mean that the refnum is referring to an open file. On top of that, the 2 issues mentioned above might get fixed in a way that breaks this workaround, so I would rather not recommend using it.

4) TDMS functions are primitives. TDMS functions and refnums are implemented on the same core level as the normal file I/O. No XNodes or something.

5) I can see how a delete function would come in handy. We had even more requests for a merge function, I think someone actually programmed it and put it up on the ni.com discussion forums (http://forums.ni.com/ni/board/message?board.id=250&message.id=27470' target="_blank">link).

6) The rules for opening a TDMS file have been subject to some confusion. It has been a key requirement that TDMS files can be transported as one file (as opposed to TDM, which always needs 2 files). Hence TDMS is implemented so the index file is optional. However, we do prefer to have the index file, because it allows for quick random access into the TDMS file without loading much information. So when we find a TDMS file without index, we will generate the index from the TDMS file. Now, if you have the DIAdem DataFinder running on the folder that your file is in, the DataFinder will be the first to open that file and hence generate the index file.

Files that are completely empty will be deleted on close. This requirement stems from people complaining about empty files on their disc after doing a simple open and close. Valid TDMS file created by LabVIEW, CVI or DIAdem should never be empty though. Again, if the DataFinder gets a hold of your file, that's how it will magically disappear.

Warning: If you have a TDMS and TDMS_INDEX file [same names, same folder] that are not matching, you will likely get some kind of error. You will not be able to read data from that file. Workaround is deleting the TDMS_INDEX file. We're working on preventing this kind of problem.

7) The panel close thing on the TDMS Viewer is a known problem that has been addressed. I don't have the CAR# handy. Workaround: Use the "Quit" button :headbang:

I hope I addressed all the questions you guys had in this thread, please don't hesitate to throw more at me. Thanks again for putting this together.

Herbert

Herbert,

Thanks for the good info and acknowledgement of outstanding bugs vs. expected behavior.

I've found another problem with the TDMS File Viewer that I'd like to throw out there:

The TDMS File Viewer doesn't load group/channel values that contain very large value length (haven't tried determining the failure limit) data arrays/waveforms. I've written a DAQ application that streams time data to disk and also makes that raw time data available to post processing routines, the output of which is appended to the same TDMS collecting the streamed raw time data. In my case, the streamed time data can easily contain well over 100,000 continuous time data points.

In trying to use the TDSM File Viewer to inspect my data file, I find that all the groups/channels entries and data is there. But, the data values are tabulated and graphed (as inspected using the tab control) ONLY for all of my post processed channel groups which contain ~20,000 data points. For the raw streamed time data channel group, the "Properties" tab lists correct information (including e.g. Property name=NI_ChannelLength with Property value=327680), but the "Values (table)" tab & "Analog values (graph)" tabs contain no data.

With some inspection, I've traced this to the "Get TDMS Properties" primitive (in the "loadAndFormatValues.vi" _{) that is returning info on the "NI_ChannelLength" property name. It seems this property is found, but that this length is returned as 0 (zero) for sufficiently large data sets. This is especially strange since the data length is correctly indicated as 327680 in the "Properties" tab.}

_{Is this a known fundamental limit of the "Get TDMS Properties" primitive?}

_Thanks,

_Rick