Mike Matthes

Add my vote to the conditional disables being accessed by the build specifications.

Ton - nice work hunting down the conditional disables programmatically. I don't believe any of your VIs access the project level of conditionals, do they? I tried hacking around the the project invokes and properties, but I don't know what value to give to the "Section" in the Project method "Get Item", which I'm guessing accesses it. I can see it clearly in the XML of the project under the same tag "CCSymbols" that you hacked. Any ideas?

If you can access this via VIs then you have all the hooks you need to have a build vi that sets the conditionals and calls the .exe builder you want, or even the full sequence for a complete build. Sweet!

Thanks,

Mike

QUOTE (Paul_at_Lowell @ Sep 18 2008, 10:42 AM)

Hmmm... I haven't looked in detail at the issue you are facing, but I did encounter some issues with using LabVIEW classes with the Flatten to XML and Unflatten from XML functions. The CAR for this is CAR# 124834. NI traced that problem, though, to the use of Enums in the class data, not just to having a class within a class (which did work in some simple tests I did). It seems you are encountering a different problem, though.

By the way, I think this is the ability to translate LabVIEW class data to XML is a potentially an extremely powerful tool! For instance, we are interested in this as a way to share data with a Java application, and as a way to send data to implement the OOP command pattern (there are other ways to do this, of course).

Paul

Paul - do you recall if this produces error 1527 - "LabVIEW: Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW."? I'm getting this error trying to convert out of an XML string that was just saved to disk. I certainly have the class loaded in memory - there's an object sitting right next to the unflatten from XML (in fact its wired into that function). I don't think this XML is quite ready for use...

Mike

QUOTE(JasonKing @ May 7 2007, 11:53 AM)

However, I do think it's techhnically possible to add this feature (a lot has changed since I was actively involved in development of the graph, so it's possible I'm wrong), so I'd suggest submitting a feature request and detailing how you would use the feature/what problem you're trying to solve. It always helps to have concrete use cases to support the desire for a feature, and helps us make sure we get it right.

J

I'll be sure to do that (make some product suggestions) once I get a chance.

I followed the other thread and it was very interesting. In general I have to say that I ran into the exact same bugs, so it must be a fairly common thing to do to try and move scales around, graphs to different plots, etc programatically. As for use cases, in general you could take every XY graph property / method and assume that we'll want to do the same thing with the Muliti-plot. I have many uses where I just want a common X axis, and this has provided a great tool for these. I think it was one of the better additions to 8.0 feature-wise, it just has some more development to get to the maturity of the other graphs.

Does anyone know if there's a way to programmatically add a new plot area? I don't know how many graphs to create until run-time, and I want to have seperate plots for each graph, all on the same x-axis. Am I overlooking the property I need?

I'm trying to figure out if there is a fixed type descriptor for a VISA refnum type of Variant. It's easy enum to determine types that are listed in NI's documentation, such as SGL, DBL, etc, but when you get to hex 70, it is a "refnum". There are tons of different types of refnums available, but I need to know if it is a VISA refnum so I can handle it differently. I have a solution where I just try to convert the variant back to a VISA - if it works it must be a VISA refnum, if it fails it must not be. That's kindof a shotgun approach. Does anyone know the secret decoder for the refnum subtypes? I haven't been able to find a document on this.

Thanks!

BTW, these VIs are located in the OpenG package called oglib_variantconfig, which can be downloaded and installed with VIPM.

If you just have a few simple items and haven't installed the openG stuff, the NI ini functions will work fine as well. If you're already running in the openG environment, it is probably more flexible, however...

I ran into this same problem and the only real way to fix it is to install the oldest version, then copy up to any later versions of Labview on the machine, much like the threads you have posted. I think this is NI's way of saying this is legacy and you need to stop using it. Unfortunately, many of us are forced to support old code (I'm in the same boat).

By the way, the database toolkit seems to have a similar issue. I couldn't get the "complete" to work for me, as suggested in this article:

http://digital.ni.com/public.nsf/allkb/e73...6256fff0049a600

I had to manually copy it to each version. The "Complete" probably works if its the first time you've installed it, but I've had to uninstall and reinstall all my Labview versions recently due to a mishap with installing the 8.20 beta a few months back.

I agree with that. Reserve a fixed length header in the file. Files are random access, you can rewrite the header every time is is needed.

I know I can "concatenate" by opening the 2nd file, reading it, and appending it to the first. I could do this in chunks to reduce memory use, in the case that the file is huge. This will take time (one of the problems I'm trying to solve).

The "reserved" space option is also one to consider, and probably the most efficient for processing time. Unfortunately, that could leave a some dead space. I will likely have to live with that and use this solution.

So far I haven't heard an equivelant solution to "appending" a file, where you do not have to read in file chunks to memory. A file on disk is just a bunch of fragments. It seems like windows could add a new fragment and change the file table on disk appropriately. I'm 99.9% sure Labview doesn't support this. I'm wondering if somebody has tackled this some fancy way.

Thanks for the suggestions - they are most likely the easy options available at this time.

I have an ASCII file (unfortunately) that contains header information such as test parameters, results, etc. at the top of the file. This is followed by a somewhat large tab delimited data table. This is easy to do post formatting and save the file once, but now I have the need to save the data file on the fly. The problem is the header information changes as the test finishes.

Making the end of the file appends is easy - just append to the end and keep going. Is there a way to prepend a file - ie change the length in the other direction?

I'll probably have to split off a header file and a data file, but of course I like to do things the fancy hard way if possible.