Justin Goeres

QUOTE(eaolson @ Oct 16 2007, 10:36 AM)

I was thinking about that the other day and started to wonder what LabVIEW would need to do to actually become such a language Similarly, but more importantly, what will it take for LabVIEW to be viewed by non-wireworkers as a "real" programming language?

I understand (or at least I think I would understand, if I cared to delve into it ) the reasons for it, but having a http://joule.ni.com/nidu/cds/view/p/id/861/lang/en' target="_blank">runtime-engine that's pushing 100 MB is a bit of a barrier to doing any little hobby projects and distributing them. Sure, you can post a link with the download and politely ask your users to go get the RTE themselves, but ~0.1 GB for a RTE to run, say, an MP3-tagging program (just to pick an example) is rather a laugh. That prevents me from taking on some little application development projects that I might otherwise dive into for fun.

Another thing that LabVIEW needs, in the long run, to become more mainstream is better support in the schools. This is why the LEGO Mindstorms stuff is such an amazing sort of viral strategy for the language. High schools and colleges all still teach text-based programming almost exclusively, and if NI/LabVIEW/the community can dent that hegemony over the next 10-15 years, it will go a long way toward teaching all these fertile young minds to think in dataflow.

QUOTE(hskupin @ Oct 15 2007, 06:11 AM)

If you create a new VI from a static or dynamic dispatch template the grid size is not set to the given environmental value. Instead the default sizes are used and you have to manually change the VI grid settings.

I have not tried this myself, but I bet that if you find the VIT file(s) that are actually being used to create new member VIs, you could change the grid setting in the template to what you want. That would give you a workaround for the current situation.

My initial guess would be that the template you're looking for is somewhere in or near C:\Program Files\National Instruments\LabVIEW 8.5\resource\Framework\Providers\LVClassLibrary. It might be CLSUIP_MemberTemplate.vit, although as I said I haven't exactly dug into it myself .

NOTE: If you modify any files in that directory, you should fully expect them to be overwritten when you update LabVIEW in the future.

When I set the Access Scope of a folder in a .lvclass or a .lvlib to Protected or Private it gets a handy little glyph on its icon to indicate my selection. However, Public folders get no such glyph -- they look just like Not Specified folders.

I would like Public folders to have a glyph of their own, so I can identify them at a glance and so they're consistent with the other Access Scopes. I would humbly suggest a cute little green key for this purpose.

QUOTE(crelf @ Oct 15 2007, 05:03 AM)

One guy is even considering an amory of http://www.thinkgeek.com/geektoys/warfare/8a0f/' target="_blank">these...

Quickly followed, one would assume, by a related submission to the Code Repository, along with a link to both a remote front panel and a webcam pointed at your desk? :ninja:

QUOTE(Tomi Maila @ Oct 15 2007, 03:14 AM)

To make naming convention uniform, it would be natural to call these initialization methods Initialize across the hierarchy.

Generally speaking, I feel the same way you do. However, there's a benefit of not allowing colliding Static Dispatch names in a class hierarchy that I've discovered in my own work.

To work around the name collision problem, I typically name all (or most of) my Static Dispatch VIs according to the convention <CLASSNAME> Initialize.vi. For example, Kitchen Sink.lvclass would have Kitchen Sink Initialize.vi or KS Initialize.vi. The (unintended? ) effect of this is that I can usually tell whether a VI in my hierarchy is Static or Dynamic Dispatch just by looking at its name.

That having been said, just being able to call the VI Initialize.vi and be done with it strikes me as a step forward. A separate wishlist item of mine would be to have a little badge on a VI's icon to indicate whether it's Dynamic Dispatch, but I don't want to threadjack .

QUOTE(crelf @ Oct 14 2007, 04:40 AM)

My science undergrad was also a physics major.

QUOTE(Ben @ Oct 14 2007, 07:08 AM)

Chalk up another (albeit non-lurking) physics major here. I jumped the fence to study Control Theory in graduate school, though, after I realized I didn't have the kind of fire in my belly that it would take to want to pursue a PhD. in Physics. (Incidentally, that led me to teach a lab in an experimental course in Mechatronics where the professor forced me to teach it using this weird graphical programming language (v4.1 or so) where instead of typing your programs in and compiling them, you just kinda drew lines between little icons on the screen and then clicked the arrow to run the code. Totally counterintuitive .)

QUOTE(Aristos Queue @ Oct 14 2007, 11:53 AM)

UseNumbersForNewVIIconsInLibs=FALSE

Thanks! :thumbup:

I added this to the http://wiki.lavag.org/LabVIEW_configuration_file/Block_Diagram#UseNumbersForNewVIIconsInLibs' target="_blank">wiki.

(also cross-posed here in both the Lounge and LV 8xx Discussions... which confused my RSS reader a bit )

Note, also, that the LabVIEW 8.5 Help is available and searchable online.

QUOTE(Popatlal @ Oct 13 2007, 07:55 AM)

(1) How to work with EVENT Structure?..Can anybody

explain with one example.

LabVIEW 8.5 Help

QUOTE

LabVIEW 8.5 Help

QUOTE

LabVIEW 8.5 Help

QUOTE

LabVIEW 8.5 Help

QUOTE

LabVIEW 8.5 Help

Get the picture? :ninja:

QUOTE(swchica18 @ Oct 12 2007, 02:06 PM)

I'm going to ignore your last comment. I thought this was a place where people discussed LabVIEW questions and problems.

Michael replied that way because your post not only asks a very basic question, it indicates that you put almost no effort into solving the problem yourself before coming here. We're happy to help you, but you need to show some initiative upfront. The members of this community are not your personal army of tutors.

QUOTE

What inputs are you changing, and what corresponding output changes do you see? I suspect you've got a fairly basic misunderstanding of what the VI is doing.

Neville's advice is good. It will require you to write a small amount of code of your own. I would encourage you to look at the various examples included with LabVIEW, and to consult the LabVIEW Help to understand what various functions do. If you still can't get your code to work, post what you've got, and describe what you've tried, and you'll get a much warmer reception.

QUOTE(Michael_Aivaliotis @ Oct 12 2007, 12:14 PM)

It seems that based on http://forums.lavag.org/VI-icon-template-overwritten-t4690.html' target="_blank">AQ's earlier post, there is no solution other than to create 9 VI's.

Crap. yen & Tomi got my hopes up.

QUOTE(Tomi Maila @ Oct 12 2007, 05:35 AM)

Actually I think NI is mixing two different concepts here, namely protecting the VI and locking the VI context.

<SNIP>

There could be new security options...

:thumbup:

QUOTE(martin@aerodynamics @ Oct 12 2007, 05:00 AM)

I have a workarround...

Yeah, those are all what I currently live with (actually, I also create a lot of my icons from templates in http://gimp.org/' target="_blank">The GIMP -- Choose Layer Visibilities >> Copy Visible >> Paste into LV icon).

But "a few seconds" times "almost every VI I create" equals a lot of menial labor and a lot of context switching. And besides, the library/class/etc. icon templates in LV85 are supposed to mitigate that thrashing, but they don't because the auto-numbering mangles the template icons. The new feature is being hamstrung by the old one. (Unless there's a way to turn it off, which is what I'm looking for... )

EDIT: Just to re-emphasize, I'm talking about LV85 here. The workarounds you mentioned are greattolerable for LV821 and below, but in LV85 there are new icon templates you can use as overlays in library & class development, and that's where the problem occurs .

I was hoping maybe there was a super-secret INI setting for this, but I couldn't find any information about one...

I would like to have LabVIEW stop automatically putting those little numbers in the lower-right corners of the icons for the VIs I create:

Is there a way to turn that behavior off?

I'm trying to get the hang of the new icon templating features in LV85, but the little numbers get in the way. I'm removing them by hand, which mostly ruins the benefit of using the icon templates in the first place.

QUOTE(Tomi Maila @ Oct 10 2007, 11:27 AM)

I guess it would. But I understood the problem was to fix the library by removing an unnecessary VI from the library. So it doesn't matter if the VI still thinks it's part of the library as it's no longer used. And the library doesn't think the VI is part of it. This can be achieved to my knowledge by editing the lvlib/lvclass/xcontrol/xnode file.

Good point. What I left out of my example was that I wanted to remove the VI from the library, but actually wanted to continue using it outside the library.

QUOTE(silmaril @ Oct 12 2007, 02:04 AM)

But what about the case where you might want to distribute a password-protected VI and allow users to put it in an .lvlib? For instance, my original example was a GOOP 1.0 class. The objectRepository.vi file for a GOOP 1.0 class is always password protected. That means that with the current implementation, you cannot put a GOOP 1.0 class inside an .lvlib!¹ Can that possibly be the one and only correct behavior? "Ability to view/edit the VI's block diagram" and "ability to organize the VI in an .lvlib" strike me as orthogonal goals.

I agree with Tomi. This feels like a bug to me.

¹Or, alternatively, you can't get it out once you manage to somehow get it in.

QUOTE(Michael_Aivaliotis @ Oct 10 2007, 01:56 PM)

http://podcasts.odiogo.com/labview-advanced-virtual-architects-lava-forums/podcasts-html.php' target="_blank">LAVA RSS feed Podcasted.

I like the semi-neurotic way it says "L-V-L-I-B". And it pronounces my last name correctly! :thumbup:

Unfortunately, it doesn't read all of some posts. For instance, in the post above this one it only reads as far as "... 04:29 AM" and then stops.

Also, it reads some characters as their decimal escape codes. E.g. the ":" character is read as "Number 58". I assume this is because of the way they're formatted in the raw RSS. Nice gimmick, though! :beer:

I was going to post that later today.

QUOTE(Tomi Maila @ Oct 10 2007, 01:03 AM)

Then for hackers a quick solution to solve the problem. Open the lvlib file and remove the password protected VI with your favorite text or XML editor. Save the lvlib file and close it. Then open it with LabVIEW and the VI should no longer be part of your library nor your life.

But then when you open the VI later, won't the VI still think it's part of the library? My understanding is that it will, at which point LabVIEW will present you with the password dialog, because updating the VI to no longer belong to the library counts as a "modification."

I would test this myself, but I blew away all the evidence already .

QUOTE(Aristos Queue @ Oct 9 2007, 01:06 PM)

But -- here's the joke -- it's actually great considering that before I changed that code, each one of those messages was, get this, a separate dialog requiring you to hit "Ok." :headbang:

Well, it does save me a trip to the Task Manager, since the likelihood of me sitting through all 40 (or whatever) of those dialogs is pretty much zero.

QUOTE

Yes, for the Love of Dog, please. (Although I'd settle for an upstream fix for whatever weirdness in the dev environment or the app builder causes me to run into that dialog in the first place )

Thanks, Christina.

QUOTE(Christina Rogers @ Oct 9 2007, 01:55 PM)

LabVIEW shouldn't have let you add the VI to a library without providing a password. That was a bug.

Like I said, I'm certain it happened back in the days of LV82 (or LV821). I wish I remembered the circumstances better. It appears that LV85 enforces that a little more strictly .

QUOTE

Yeah, I pulled an old rev out of the repository from 12+ months ago, before my little .lvlib experiment.

This concludes today's lesson on "Why Source Code Control is Important, and Will Quickly Pay for Itself in Ways You Didn't Specifically Anticipate".

Tune in again for tomorrow's episode, "Don't Worry That LabVIEW Corrupted Your Project, You Can Just Revert It". :ninja:

I have an old GOOP 1.0 class that I implemented a long time ago. At some point (during 8.2.x) I put it into an .lvlib, because that seemed like a good way to manage it.

Now, however, I need to remove all the VIs from this .lvlib, but LabVIEW 8.5 won't let me, because the objectRepository.vi is password-protected! (because it's part of a GOOP 1.0 class).

My question is two-fold:

1. How do I get the VI out of the .lvlib? Is it even possible?
   
2. How did I get myself into this mess? Is there some restriction on password-protected VIs vis-a-vis .lvlibs that LV85 enforces but LV82 didn't? (FYI, trying to backsave it to LV821 crashes LabVIEW, so that's nice, too. :headbang: )
   

QUOTE(yen @ Oct 8 2007, 01:32 PM)

Episode of Dinosaur Comics

Hehe, Dinosaur Comics is my most favoritest webcomic! :thumbup: I even gave sexy exciting merchandise to my groomsmen at my wedding.

Also, Dinosaur Comics in fact did an episode related to text adventure games back in 2005. Thus, the circle is complete!

P.S. XKCD, which I think you've posted links to before, is my 2nd favorite. It seems there is some kind of synergy in our webcomic interests here....

QUOTE(Aristos Queue @ Oct 3 2007, 11:28 AM)

I LOATHE THAT ERROR MESSAGE.

At the risk of taking the discussion too far off-track, where does this one rank in comparison?

http://lavag.org/old_files/monthly_10_2007/post-2992-1191863686.png' target="_blank">

This one also appears after trying to launch an EXE that both runs fine in the development environment and seems to build OK.

QUOTE(digital19 @ Oct 5 2007, 06:36 PM)

My first adventures in programming were parsing strings like "attack orc with old sword" for home made text games we'd come up with.

Same here. Ah, the good old C64.

Interactive fiction taught me:

• What a credenza is, and that you can hide important items in one.
  
• The word petulant, as in "A petulant werewolf sits at the bar, morosely nursing his drink."
  
• The phrase "Abandon all hope, ye who enter here."
  
• To love spoonerisms.
  
• That you literally cannot put toothpaste-like material back into its tube (this lesson occurred in the control room of Flood Control Dam Number 3 )
  
• Techniques for finding my way through mazes of twisty passages, all alike .
  
• and so much more....
  

BTW, here is a nice scan of a really great hand-drawn map of Zork I that I ran across the other day. My old maps are long gone, and of course they weren't very good in the first place.

QUOTE(Jim Kring @ Oct 5 2007, 01:09 PM)

Use the Application::Get VI Version(<path>) method.

Yeah, hoo-boy, wouldn't that've been fun! :headbang:

Maybe you could've egged me on to do a whole library for the Code Repository, and then once I submitted it you could post the method node in the comments thread. That would have been AWESOME. Whee!!!

I would like to determine which version of LabVIEW a given VI was saved in, but not by opening it in LabVIEW. I just want to look at the raw hex of the file on disk to determine it. Does anyone know the key(s) to accomplishing this?

I messed around a little by saving an empty VI file in LV85, then backsaving it to LV821. The files are the same length, and are virtually identical (I think) except for some data at the end of the file (roughly the last 0x01E4 bytes). The whole thing looks vaguely like an old MacOS-style resource file (which I think should not be surprising), but nothing jumped out at me.

And while we're on the subject, any recommendations for a good graphical diff utility for binary files? I've never come across one.