Norm Kirchner

it had more..... she made me take it off HA! a Barbie at the barbie, clever

And just to put a 'face' with a name with a photo that Veronica says is probably 'LAVA inappropriate' and 'the most skin LAVA has ever seen' (she must never have seen the Coyote Ugly photos)....

If you have Quick Edit operational (the component that "Label Side" and "VI Properties" uses, then LVSpeak is fully operational. Did you ever install the second package that modifies the Quick Drop VI's? Flip this thread over to the LVSpeak thread and we'll figure it out there. PS: Must give credit to Chad Bailey, another RF systems engineer that came up w/ the smashy smashy combo command. -Norm

um...... You don't have to wear them. There is the stock NI Week 09 Lava t-shirt that is very plain jane and totally PC and not offensive or risky. (DISCLAIMER: Scripting4Life IS NOT an NI sponsored t-shirt. I do this on my own time and for myself....and others that like it) I agree it's a bit graphic, but you can see the original idea is not mine. I suppose I could make another one that shows people around the world and a diagram underneath that shows an array of people references w/ a connect terminals invoke node, and showing how scripting is bringing the people of the world together......but that's not as much my speed. If you want that shirt, it feels creative enough that I could be compelled to get one up for you on Zazzle.

So something I have done a few times and never questioned the 'appropriateness' of it was the usage of the "Genereal Error Handler CORE" directly on my block diagrams. Now the ONLY reason that I like to use the CORE vi is because of the access to the "Stop Event Propagated" line that is not connected out to any of the other error handler VIs on the palettes. The reason this is important, is because you can offer the end user dialog type to have the option to "continue or stop" but you have no way of knowing if they hit continue. And I know there are a variety of things I can do, but before I start to investigate making my own dialogs and such, I want to get everyone's feel on what they think of the 'appropriateness' of using this "non-palette level" vi

Wow, other than parental interaction in my life age 3 to 28, this is possibly the most misunderstood I've ever been.

Shite.... guess that's why I'm not in marketing I should have guessed as much with the way people go WTF after most things I say anyways. Maybe I should have used the Monty Python foot w/ the nail through it.... I could see where it would be very confusing w/out the caption, but usually you here somebody say "Whatever 4 Life" when it's something they're devoted to or in this case, willing to live with a rusty nail through the heart. but I know, I know, you are probably all still going WTF. I was going for something like this which is a classic Sailor Jerry style Tatoo

Rusty nail.... Loving scripting... get the rusty nail through the heart..... shit... didn't think it was that hard to get.

Cool or WTF?

My official Twit ID : NJKirchner Be sure to keep that ID handy on Wednesday of NI week as you can virtually follow me as I give a tour to the 4 lucky people who win the LAVA BBQ Door Prizes!! Don't forget to sign up early for special rates!

I can't say that I've ever tried to implement it on another language. Have you adjusted any of the settings for speech under control panel?

But have you used 'Get Pizza' yet

You're using it?!!!! Really!! I've got my first official user!!!! HELL YEAH! I'm going to give you a reputation point just for that . Yup, the alignment is about the most used one, and then probably the quick drop integration. Inside of the MS SAPI we have the ability to do this, although it requires a better understanding of it and more testing that I never got to. Actually Darren is hitting me up for this exact thing.... I just have a hard time seeing how much more that will simplify things on one side for the drawbacks I can see on the implementation side. Can you give me 3 solid use cases, because the detect 'Align' then detect 'direction' will still require a unique piece of code for each direction, and the only thing it would make simpler, is that flat top level list of commands and it would make it hierarchical. Also, unfortunately not all properties are common in the VI Server Class structure. Like label is not a GObject item, and certain things require me to detect the specific type, or iterate through the valid ones (you might see this stuff in there)

Ok, was just about to detail it all out, but head to http://eyesonvis.blogspot.com/2009/07/lvspeak-automating-vi-development.html and the newest info/details are on that there. and once that's done come back here w/ questions Thanks, Norm

Daklu, There is a bit of a different situation going on than as you're putting it. I don't plan on having the user, use user.lib as a source code dev directory. I'm merely using it as a home for files that will be copied upon the start of a new *widget*. Said widget directory, currently under user.lib, contains all files that will be copied and the new widget home will user.lib. If you have a better recommendation for where a *Widget Directory* like this should be placed on a users system, I'm all ears. Just keep in mind that it's just 3 simple stupid files that do not warrant a grand and esteemed unique location on disk. But in actuality, I'm thinking that SciWare's trick is just what I was looking for. So now, this *widget baseline* can remain at user.lib and I can start a new widget from baseline anywhere else on disk.

Understood, but at the same time, I'm looking for an appropriate single good place for a variety of tools and user.lib fits the bill, it just happens to be that this one thing (baseline template which requires 2 VIs and 1 Ctl) would have to have it's own special place just for itself which I still have not found an appropriate place for (which obviously can not be at a relative path)

From what I recall and can see, is that VIs will look for their SubVIs at the relative location where they existed at the last time the calling VI was saved. I'm messing around w/ VIs in user.lib and attempting to copy an entire user.lib directory elsewhere on disk (w/ some renaming and such) But what I'm seeing in this situation is that the VIs copied from User.lib will not look for their SubVIs in their relative location first, but rather in their previous location in user.lib. Assume for the sake of argument, that these baseline VIs must start out in user.lib. Do you feel that the presence of a SubVI in userlib in a Top Level VI in userlib should not look relative first? You can replicate this expanding the simple attached VIs into user.lib and then copying the directory elsewhere and then opening the top level vi. I recognize this is a corner case, but am trying to see if anyone has encountered this issue before or if there is a better way of working around other than loading the vi hierarchy from their new location bottom up so that the callers see them in their new location first. UserLibLink.zip

Am I missing how to do that? Not that I would just give Mike a kudos for asking for one or anything.

And improved from the looks of it! Thanks guys

Definitely hang out on the forums and ask many many questions. I would say that if you want to learn how to program LabVIEW, find something that you want to do that would be solved with a program and just program it up. An interesting example is something as simple as a contact management program. A more involved but useful program might be tracking expenses quicken like. Or if you have a few dollars to spend, grab a USB Multi Function DAQ card along with a few relays, sensors and motors and automate something in your dorm room. My personal favorite that never got implemented was just a basic door opener or re-inventing "The Clapper". Actually I did do the code for the clapper to be honest, but never hooked up the relay to my parallel port. And if you're too young to know what the clapper is, just youtube it.

Should be because I'm pretty sure you were one of the people I owed a beer to

Does anyone else see a few updates missing from this listing? I'm pretty sure I had at least 4 or 5 people on my list by now?

Mike, STFF man! (search the freaking forum) Someone came up w/ a very similar way as REx to use queues over a network or at least that's what I found on lava search. >8^}>

There is a novel technique that I have seen and done a variety of times. It requires creating a wrapper for the "Send Notification" VI like this http://screencast.com/t/zRDGaScM What the video hopefully details is that you can create a VI that is in memory on Application A. Inside of that VI is a shift register that holds the reference to the needed thing (semaphore, queue, user event and so on) Then you pass that VI the data that you want to end up in the (semaphore, queue, user event, notifier, and so on) using Call by Reference Node And then the VI fires the (Notifier, user event, EnQueue) with that data and the stored reference. By doing that, you have successfully sent data to any other LV application regardless of whether it is another Application Instance, an executable, or a VI across the world. Note: Scott Menjoulet (LAVA member w/ the Detroit Red Wings Avatar) is the originator behind this idea, and I have merely been it's rah -rah boy over the years and strange uncle to work it into a generic LVOOP based implementation in LVx See the attached file for the VI's and projects used in the video Step 1 is to open both projects, local and remote and then go from there. -Norm REx.zip

Gary, Good questions. I have one to follow it up as well that I'm curious about. I've always had an expectation of Single Element Queues to be the most memory efficient and fastest way of getting information from point A to point B by reference. And that if you do a modification of that element, by DeQ, modify, EnQ that you will be doing an in-place memory operation. This makes me think otherwise unless the compiler is as smart as we hope. AQ?