Jim Kring

Sounds like a good coding challenge to me. > I'm fairly sure that you can use XML to represent almost anything, but you would need an editor. As Chris said, we already have a G editor: it's called LabVIEW. > In any case, as Chris said, to convert an LV diagram to XML, you need code for every class and that's a lot of work. As with most things it's good to take small steps. Just take a subset of G, define an XML schema, and build the import/export tools. I've also toyed around with the idea of building a dataflow execution system (G engine), written in LabVIEW -- I know it can be done. :thumbup:

It's officially 2007 and NI Week 2007 is coming around the corner. Since I've heard a lot of people complain about NI Week being in August, I'm curious (based on scheduling and ability to travel) which month people would change it to, if given the choice. Thank you,

If we could represent VIs as XML, then we wouldn't need LabVIEW to create/edit VIs

I heard that the "mx" in "DAQmx" stands for "Marketing eXtension"

From what I think I understand, the Database Variant to Data primitive handles the ActiveX Variant "Null" value in a special way (basically, it doesn't barf as the Variant to Data primitive would). This is important, since database records can have null values for fields.

Here is a document that has some info on variants: http://www.openg.org/docs/LabVIEW%20Data%2...01%20of%202.pdf

Michael: Yes, will probably work. Don't forget to save the VI and the XControl afterwards. You should probably save the VI first, so that the XControl "senses" the new file name/path of the VI.

Hi Ton, Nice job. I guess great minds think alike ;-) BTW, in your download description you mention dependencies to many OpenG packages. Can you put a link to VI Package Manager (or OpenG.org), so that people can easily get them? Thanks,

Have you tried this?... 1) Load the VI into memory (open a VI Server reference to the VI) 2) Add the VI to the library/xcontrol while the VI is in memory 3) Save the VI 4) Close the VI Server reference to the VI I believe that the VI will "sense" that it has been made a member of the library if it is in memory when the operation is performed and that this "sensation" will be persistent if the VI is saved. I hope it works...

You can give feedback and suggestions to NI via their Product Suggestion Center.

Nick, There is an unreleased http library in the OpenG CVS repository which uses TCP-IP to perform an HTTP GET. Info on how to do a CVS checkout: http://sourceforge.net/cvs/?group_id=52435 Browse CVS Repository (ViewCVS): http://opengtoolkit.cvs.sourceforge.net/op.../http/http.llb/ The http library depends on some other OpenG libraries, so you should install VI Package Manager in order to download+install the OpenG libraries. -Jim

The Mac version doesn't use on-line product activation, so a serial number for LabVIEW for Windows will (technically) work on LabVIEW for Mac (or Linux). However, there is no downloadable version of LabVIEW for Mac (or Linux) -- you get the installer on CD's from NI when you purchase LabVIEW for Mac (or Linux).

You should make this into an XControl. Then each path could resize itself, even at edit-time. :thumbup:

I'm curious if and how people are using the new LabVIEW 8.2 native object-oriented programming features. Have you been able to integrate these into your day-to-day programming? If you are using native OOP, which features do you find the most useful? If you're not using native OOP, what is preventing you from doing so? What features do you really need that you do not yet have? I really love object-oriented programming in LabVIEW (I've been using traditional GOOP for years, now, and couldn't live without it) and want to see the native OOP framework continue to evolve as a powerful tool. The features that NI has already implemented the first iteration of native OOP (8.2) are a great start, but there is certainly ways that it can evolve! So, please help by sharing your thoughts and don't forget to keep your feedback constructive -- NI's developers are working hard to give us great tools and we want to make sure that they know we appreciate it! Thanks for taking the time to take the poll and and tell us your thoughts.

We want to help, but you have to help us to help you. You need to ask your questions the smart way.

What problem are you trying to solve? Your question makes it sound like you are a...

Give yourself the gift that keeps on giving, all year long... a LAVA :thumbup:

The user can only change the column size as a result of moving the mouse. So, you could monitor the Mouse.Move event and check to see if any of the column positions have changed. You would probably want to send this to a notifier, rather than queuing up the events (since there will be a lot of them) and you generally only care about the current (latest) state.

Moore Good Ideas has a VI that reads the icon from the VI's binary in their MGI Freeware VIs. Also, In LabVIEW 8.2 (and maybe earlier) you can use the VI Icon methods of the VI class (see below). Cheers,

Stephen, Is there any way to inspect the object version the flattened data (either on disk or after reading it into memory)? This would be nice, since it would allow us to implement our own upgrade logic, on top of what LabVIEW gives us for free. Also, how does this feature handle modifications to type definition elements of the object data? For example, if my object data contains a sub-cluster which is also a type definition. Editing the cluster will effectively edit the object data. This sounds like a very nice feature! I'm looking forward to giving this a try. Thanks, -Jim

maximus: Does the VI have a window title that differs from the VI's name on disk? The help server uses the window title of a VI for referencing the VI in the palette (similarly, the palettes display the window title of the VI as it's name in the palette menu). This property is available from VI Properties >> Window Appearance >> Window Title.

I am not sure exactly what the problems are with the code. I would suggest comparing the original code with the version you have. You can find the originals, here (click on the "5 attachments" tab to view the page's attachments or download the SMTP directly from this link). It is possible that the changes are simply a result of the up-conversion to 8.x and then the down-conversion to 7.1.

Jose, Here are the converted files. Please note that this is not executable, due to the fact that some of the File IO primitives to not map directly into 7.1 functionality. Download File:post-17-1166124556.zip Also, jhoskins mentioned that you should download the OpenG libraries using VI Package Manager. Unfortunately, the SMTP VIs are not yet available from withing VIPM. Cheers,

I think that it's wonderful that people can't unbuild executables. I believe that those people who were complaining about not being able to access the VIs inside of EXEs were probably just using this distribution technique as a kludge to make up for a lack of features in the LabVIEW application builder. :2cents: