Jim Kring

QUOTE(ars_stowers @ Feb 20 2007, 09:25 AM) Aaron, Send me a message http://forums.lavag.org/index.php?act=Msg&CODE=4&MID=17' target="_blank">personal message (including your email address) and I'll send you a copy of the development version of Builder, which supports Project Libraries. We can then discuss testing issues. Thanks, -Jim

See this post for more info. I recommend considering using OpenG Builder to do what you are after, if it will do what you want. We're still polishing up some improvements for LabVIEW 8.2 compatiblity. If you would like a preview release, let me know. Thanks, -Jim

QUOTE(ars_stowers @ Feb 20 2007, 08:43 AM) Aaron, I've been working with others on support Project Libraries (as well as LVClass, XControl, and XNode) in OpenG Builder (ogrsc_builder package in http://jkisoft.com/vipm' target="_blank">VIPM). OpenG Builder does most of what NI's application builder does, but it's a bit more flexible. If you're interested in this (it does support LabVIEW 8.0), please let me know. We can use some more testers. Thanks,

QUOTE(kaarthik_kaarthik @ Feb 19 2007, 02:40 AM) The "VI Description" is a good place for this: File>>VI Properties>>Documentation>>VI Description

QUOTE(dannyt @ Feb 19 2007, 02:36 AM) Yes some things are getting better -- however, the reasons for me (personally) to not use the LabVIEW Project environment and native OOP outweigh the reasons to start using them. I'm eagerly waiting for someone to prove that it's time to make the switch. Certainly, if NI were to open up the project environment to outside developers (uh oh, Jim said "open" again) then I would be the first to start using it. And, me and my friends would probably create some very cool and useful tools that would give other LabVIEW users compelling reasons to start using the project environment. QUOTE(dannyt @ Feb 19 2007, 02:36 AM) I do think that thinks look so much better post version 8 of Labview with the introduction of Projects, better configuration control and much more. I am currently writing my own ClearCase handling VI's as version 7 has no concept of it. I used ClearCase, very breifly. I stopped using it when the system administrator told me that the only way to add files/folders recursively was through an obscure and very long command-line. Also, I did not have permission to delete or rename files. What a drag. Give me my SVN and let me get to work, already :-) QUOTE(dannyt @ Feb 19 2007, 02:36 AM) My final comment is to Jim, if there is one application I have seen that leads me to believe that Labview projects can be scaled it must be the VI Package Manager, it gives me a feeling of well thought out, planned and executed piece of work, better I feel than some of the actual part of Labview itself. :worship: . I am sure that something like this can only be created by applying a structure software engineering approch. Thanks, that's a great compliment. Actually, we see VIPM in a similar way -- we want it to be proof that you can build sophisticated, cross-platform desktop applications in LabVIEW through software engineering. If we can do it, so can you If you're interested in some statistics, VIPM (main application) has about 1400 VIs (176 vi.lib, 263 openg.lib, and 80 jki.lib), the installer+uninstaller has about 150 VIs, and the automated build process is about 100 VIs. Actually VIPM has had its share of growing pains and refactoring. It wasn't perfectly thought-out from the start (few things are). But, our team is committed to improvement and finding ways to refactor and reuse code -- that makes a huge difference. Actually, one of the best parts about VIPM is that is enables software engineering through automated deployment and installation of LabVIEW tools and reuse libraries (yes, we're doing a lot of "eating our own dog food"). Adding configuration management capabilities is next on our list.

QUOTE(Tomi Maila @ Feb 19 2007, 01:01 AM) Tomi, That looks like it will work great. Thank you! -Jim

Please don't post BMP files -- they are unnecessarily large. Here is a PNG version.

QUOTE(Mike Ashe @ Feb 18 2007, 04:03 PM) Hi Mike, We are in complete agreement. I didn't say that having better tools would be the panacea that turns every LabVIEW developer into a software engineer. (I see many "real" software developers using powerful tools every day, but nonetheless, doing poor software engineering. This is a problem that can't be solved. Some people will never be good software engineers -- if they are either too short-sighted or are unable/unwilling to think abstractly.) What I did say, is that the real problem is that we need better software engineering tools in LabVIEW and that this necessitates machine readable+writable source code (a precept of software engineering). Cheers, -Jim

QUOTE(dannyt @ Feb 15 2007, 01:32 AM) QUOTE(xtaldaz @ Feb 15 2007, 11:13 AM) I agree completely with DannyT that LV doesn't scale well when you start adding developers and complexity to a project. I'm with Mike on this one -- I respectfully (and strongly) disagree with this perspective. I feel that it's not fair to say that it is LabVIEW's fault that an application does not scale. LabVIEW applications can be made to scale just fine, but it does requires frameworks, software engineering (and team) know-how, and a lot of discipline to do so -- for example, you need some form of OOP design and framework, you need templates, automated builds, automated unit test execution, a well communicated software development process, collaboration tools, etc. Sorry if I seem a little defensive, but I'm pretty fired up about this. I love LabVIEW (and need my applications to scale well) and thus, I've dedicated a significant fraction of my career working on tools that allow LabVIEW applications to scale and trying to educate myself and others on how to do better software engineering in LabVIEW. I guess the point of my rant is that, in my opinion, we all need to focus on (and be vocal about) the real problem with the state of software engineering in LabVIEW -- that the state of software engineering tools for LabVIEW is pretty meager. And, NI isn't facilitating this, as much as they could, in my opinion. The solution, in my opinion, is an open, machine-readable/writable source code format (I vote for XML). I good first start would be to open up scripting. Cheers, -Jim

QUOTE(BrokenArrow @ Feb 18 2007, 12:18 PM) That's great! I'm sure you're going to love it here, outside of the walls of ni.com (LAVA is all about fun, which is why we love to hang out here, on the weekends). That said, make sure to keep an eye out for http://forums.lavag.org/Rusty-Nails-f87.html' target="_blank">Rusty Nails Thanks for the kind words -- there will surely be many more shameless plugs to come, but I'll always try to keep them of very high-value Cheers, -Jim

QUOTE(Tomi Maila @ Feb 18 2007, 10:43 AM) Tomi, Linker info are the path dependencies on other LabVIEW files (and non-LabVIEW files, such as DLL, help, etc). You can read this information from file, rather than trying to do it in memory -- often this is easier, for a variety of reasons. You can read the linker info by using the Application method Linker.Read Info From File. This is made available, via the SuperSecretPrivateSpecialStuff=True LabVIEW.ini key. See the image and VI, below. Download File:post-17-1171828234.vi Note: You can also write to the linker info of LabVIE files by using the Linker.Write Info To File method, but this is quite a bit trickier and has dangerous implications. Thanks, -Jim

QUOTE(crelf @ Feb 18 2007, 10:35 AM) Any relation to this person?

Richard, Welcome to LAVA! I'm sure you'll find this a great place to discuss user interface and custom control tricks. In fact, Michael (LAVA's admin) is a wizard in this area (as are many of LAVA's members) and, every once in a while, he shares some of his secrets. <shameless plug> </shameless plug>Cheers, -Jim

Does anyone know how to detect whether a VI is calling an XControlLibrary instance (an XControl) and obtain a reference to the XControlLibrary? The XControlLibrary does not show up as in the callees list. It is possible to test all Front Panel controls using the XContro::Is XControl? property but this does not give any information about or link to the XControlLibrary. It is also possible to get this info from the linker info on disk, but I would like to do this all using VI Server, in memory.

Hello LAVA'ers, There is a new version of the OpenG "Rename Folder of VIs" tool (ogrsc_rename_folder_of_vis package) available. This tool allows you to easily add, remove, and rename prefixes and suffixes to an entire folder of VIs, all at once. One installed, this adds a File>>Rename Folder of VIs option to your menu, in LabVIEW, which launches the Rename Folder of VIs dialog (see screenshot, below). Changes in version 1.6: [FIX] Added a fix for better handling of reentrant VIs in LabVIEW 8.x [NEW] Added tip strips on all Front Panel controls [New] Added an about dialog See here for more info. You can download+install this package using VI Package Manager. Just press the "Check the Network for Available Packages" button to refresh your package list. Thank you,

Hello LAVA'ers, There is a new version of the OpenG "Variant Configuration File IO" library (oglib_variantconfig package) available. This library contains several routines for writing anything (arbitrary data) to an INI file. This release... See here for more info.You can download+install this and other OpenG libraries using VI Package Manager. Thank you,

QUOTE(Tomi Maila @ Feb 14 2007, 01:20 PM) Tomi, Here is a link to a simple technique that I use for unit testing OpenG libraries: http://forums.openg.org/index.php?showtopi...post&p=1120

QUOTE(robijn @ Feb 13 2007, 02:02 PM) Hehe

QUOTE(PJM_labview @ Feb 13 2007, 12:08 AM) Maybe something like this? (still, please, no laughing) http://lavag.org/old_files/monthly_02_2007/post-17-1171355171.png' target="_blank">

QUOTE(Tomi Maila @ Feb 12 2007, 11:28 PM) I like this idea. Here is my concept (no laughing, please). http://lavag.org/old_files/monthly_02_2007/post-17-1171352804.png' target="_blank">

I don't like the DNA helix -- it signifies heredity, but not abstraction. Abstraction implies the following: indirect, hallow, empty, shell, uncertainty, dynamic, virtual. I've seen conventions where abstract class icons have grey backgrounds and concrete classes have white backgrounds. Grey signifies indirection (abstraction) -- at edit time, you don't know which implementation is actually going to be called. A cloud is another symbol of indirection (a gray cloud, even more so).

There is a typo in the spelling of the following forum name: "Other Announcments" should be spelled "Other Announcements" (it's missing an "e")

QUOTE(yen @ Feb 9 2007, 05:35 AM) Thanks, Yen! It's great to hear that it makes a difference QUOTE(Falevoz Y. @ Feb 9 2007, 03:09 AM) I'd be very interested too in a package that could be install without the Internet. QUOTE(Neville D @ Feb 9 2007, 10:07 AM) But sometimes, for whatever reason (internet traffic? our internal proxy server?), VIPM times out, when the operation worked fine on another machine a few hours ago.. in that case, it is just easier to copy over the files. QUOTE(Tomi Maila @ Feb 9 2007, 10:59 AM) Yes. You may also want to distrubute the packages with your own application and then you simply need to know how to install them to a new computer without VIPM. There is a FAQ item, here, on the jkisoft forums that describes how to use the Package>>Add Package(s) to Library menu option to add one or more package (*.ogp) files to your package list. This is another easy way to move packages between computers (the file dialog for adding packages allows you to select multiple package files and import them all in one shot). You are certainly welcome to just copy around the user.lib stuff, but again, I do not recommend it. Package files (can) do a whole lot more than just put VIs beneath your user.lib folder -- it is best to install the packages using VIPM. Don't have VIPM on your other computers? Then install VIPM on your other computers? Have good reasons not to install VIPM on your other computers? Tell us what those reasons are and we will try to address them (please, post ideas to the VIPM Feature Suggestions and Ideas Forum or feel free to post here on LAVA). We are committed to improving VIPM and we have plans for releases on regular period. Please don't hesitate to give use your valuable feedback, so that we can address your needs. Thanks, -Jim

Earlier this week, I installed LabVIEW 7.1.1 on Vista "Home Basic" edition and was able to also install VIPM without any significant issues. I installed/ran both as administrator, just to be sure I wouldn't run into any permissions snags. However, I did have some trouble with a driver for a CAN bus adaptor, so I had do "upgrade" the system to Windows XP Pro. Let me tell you, Vista is a pig (with respect to memory and CPU usage). But, the UI is pretty slick. It didn't take me much trouble to get comfortable with it.

I just learned that humans share 97.7% of our genes with gorillas. I also learned that troops of gorillas are lead by alpha males. http://freewebs.com/hiusser/gorillas.htm