Justin Goeres

I use a .NET Invoke node as follows: http://forums.lavag.org/index.php?act=attach&type=post&id=6785 Obviously this is Windows-only, and it requires the .NET Framework to be installed on the host machine.

QUOTE(alfa @ Aug 27 2007, 11:47 PM) If you believe that the prostitutes are after you (they are not), it leads me to question your ability to reliably detect these http://en.wikipedia.org/wiki/Microexpression' target="_blank">microexpressions. What is it that makes you concerned that the prostitutes are after you?

QUOTE(robijn @ Aug 27 2007, 12:11 PM) Do you mean that NI presents LVOOP this way, or that OO in general (in other contexts/languages) is presented this way? I, for one, don't think NI is guilty of that.

QUOTE(lavezza @ Aug 27 2007, 11:12 AM) Fair enough, but I'll take consistent, with a workaround over random chance any day, even if it's not what I think is "correct" . I would also be interested to hear if the behavior is different on platforms other than Windows.

QUOTE(lavezza @ Aug 27 2007, 10:38 AM) I added a sequence structure around the listbox terminal and forced the dataflow, and that seems to have forced the Listbox terminal to read late enough that I get the "after" value every time. I tested it maybe 10 times. http://forums.lavag.org/index.php?act=attach&type=post&id=6774''>http://forums.lavag.org/index.php?act=attach&type=post&id=6774'>http://forums.lavag.org/index.php?act=attach&type=post&id=6774

QUOTE(lavezza @ Aug 27 2007, 09:20 AM) Test machine is a Dell Inspiron 9300 laptop under WindowsXP (Dog only knows which updates). LabVIEW 8.5: "Listbox value: 2" LabVIEW 8.2.1: "Listbox value: 2" LabVIEW 7.1.1: "Listbox value: 2" My recollection is that there were some issues in the past with the timing of front panel terminal values in relation to Value Change events, but I don't remember what version(s) they existed in. That's the reason why I always use the NewVal terminal in a Value Change. That doesn't exactly apply to your situation, but it's similar.

QUOTE(tcplomp @ Aug 26 2007, 08:15 AM) ftp://ftp.ni.com/evaluation/labview/pc' target="_blank">Here is a directory that seems to still have the evaluation versions of LV80 and LV82, if you need those.

Now I know what Kara will be telling me to stop singing for the next few days. Also, I saw this the other day and it reminded me of when I used to use Global Variables everywhere. <embed src="http://www.metacafe.com/fplayer/772271/kittens_coca_cola_box.swf" width="400" height="345" wmode="transparent" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash"> </embed><br><font size = 1><a href="http://www.metacafe.com/watch/772271/kittens_coca_cola_box/'>http://www.metacafe.com/watch/772271/kittens_coca_cola_box/">Kittens-Coca Cola Box</a> - <a href="http://www.metacafe.com/">Watch more funny videos here</a></font>

I made some progress. QUOTE(Justin Goeres @ Aug 24 2007, 01:42 PM) As usual, the answer was simpler than I expected. http://forums.lavag.org/index.php?act=attach&type=post&id=6757''>http://forums.lavag.org/index.php?act=attach&type=post&id=6757'>http://forums.lavag.org/index.php?act=attach&type=post&id=6757 My problem was that Setup Camera is an Invoke Node, while I was stubbornly scouring the Property Nodes for the same functionality . I now have a couple VIs that draw a set of axes, as well. I will clean them up in the next few days and post them.

QUOTE(Ben @ Aug 24 2007, 01:47 PM) Linky? I searched before (and just now) but didn't come up with anything.

QUOTE(Guillaume Lessard @ Aug 24 2007, 12:57 PM) Yes, but part of the (perceived) problem with LVOOP is that people who (think they) are familiar with OO see it and exclaim, "But that's not OOP! I want it by reference!" If LVOOP as designed doesn't "look enough like" OOP the way lots of developers expect to see it, isn't that really just a semantic problem? QUOTE(Guillaume Lessard @ Aug 24 2007, 12:57 PM) Val, have you even looked at LabVOOP? It's Dataflow! It's Objects! It's unique! It's, well, LabVOOP. It's all those things, but at its most basic: it's Clusters. Same old same old, with a little of the new. QUOTE(Guillaume Lessard @ Aug 24 2007, 12:57 PM) I'm pretty sure LabVOOP did more to "alienate" and "disenfranchise" the users most familiar with OOP than any other group. Getting them to rally around it has obviously been a problem... The real problem, I think, is that there are 1000 slightly different, and conflicting, ideas about exactly what it means for something to be OOP. For some people, a critical component of an OOP implementation is that it's by-reference. LVOOP isn't (natively), so for those people the entire idea never gets off square one. But that's throwing the baby out with the bathwater. I guess everyone is entitled to their personal crusades (Dog knows I have mine ), but after a year of LVOOP, I like it. I have to go back to LV711 on occasion, and it's jarring because my by-value objects are missing.

I'm finally getting around to using the 3d Picture Control for something "serious," and I feel like I'm running up against a bit of a learning curve. There are two things I'd like to do, and I feel like they should be easy: (1) I would like to show a set of XYZ coordinate axes on my 3d Picture Control to show where {0,0,0} is, and which way the unit vectors point. Is there some way to do this easily, or do I have to build them out of 3d object primitives? (2) I'm confused by the ModelView Matrix and Projection Matrix properties. What I would like to do is reset the camera view to a certain position when the user clicks a "Reset Camera" button. It seems like one of these should work (and I'm familiar with orthogonal transformations, thank you very much ), but I seem to be getting unexpected results. Thanks!

Gentlemen, truly I have seen the future: http://forums.lavag.org/index.php?act=attach&type=post&id=6753 So dainty, yet such power!

QUOTE(orko @ Aug 24 2007, 12:32 AM) I hadn't heard that rumor, but my belief is that if NI is going to teach LVOOP (and I think they should) it should be taught early in the course tree. If the drumbeat of LVOOP adherents is "every cluster should be a class" (which I think I stole from AQ, but I also think is a decent jumping-off point), then I'd like to see LVOOP taught in place of (or alongside) clusters, right at the Basics level. I have a friend that I ran through my Basics books a few months ago for fun, and then at the end I showed him LVOOP. This created a great deal of confusion for him, especially since he comes from a smattering of various OO backgrounds. Early on in the tutoring he wanted to know, "Where are the objects?" and I had to tell him to be patient. QUOTE(Val Brown @ Aug 24 2007, 12:11 AM) First of all I don't know how NI would "force" anyone to use classes. If anyone has any ideas on THAT "new feature" and how it would be implemented, I'd really like to hear it. Removing our access to clusters outside of classes would be one way to do it. Even that wouldn't truly force everyone to change, but it would most certainly ruin the experience for anyone refusing to do so. (I don't think NI should, or would do that.)

QUOTE(orko @ Aug 20 2007, 12:13 PM) Go hang a salami, I'm a lasagna hog! http://phobos.apple.com/WebObjects/MZStore.woa/wa/viewAlbum?playlistId=2322174&s=143441&i=2322068' target="_blank">Source (iTunes Music Store link)

This reminds me of AQ's old story about the "feature" where LabVIEW would crash if a wire greater than 65,536 pixels in length had a bend in it (or something along those lines). "Engineers at the University of California, San Diego have constructed the highest-resolution computer display in the world – with a screen resolution up to 220 million pixels."

QUOTE(tum @ Aug 22 2007, 09:46 PM) Do you mean that you're trying to write a console app in LabVIEW? (I.e. a program you run from the command line (with arguments) that returns its output to stdout.) That's an issue I've been meaning to look into for a while, but have never found the time to do so.

As I mentioned at NIWeek, I use it in every one of my projects now. There are a few reasons for this: I forced myself to start doing that a few months ago and "got used" to it. I have not found the time to use/purchase any of the by-ref GOOP stuff in 8.2 or later, so LVOOP is my best option for object behavior. I desperately want to believe that AQ and the rest of the LabVIEW team were onto something (as opposed to simply on something) when they created it. I really like the way I organize my code when I use it. I completely agree with Jim's and PJM's sentiments, but those are things that I've either learned to live with or have structured my workflow around. That's not to say there aren't drawbacks. My ImageMagick library, for instance, throws errors if I try to build it into an application. I can't for the life of me figure out why, or how to fix it, and for now I've given up. If I had a library that large for a customer project and it did that, I would throw my laptop through the window . The solution has been to do frequent interim builds of all my software in the hopes of at least catching whatever disease the library caught. (Note that this is a good behavior to have learned anyway ) Likewise with the "whole class breaks on one broken VI" thing. I live with that, kind of like how we all learned long ago to live with the concept of the Run arrow breaking on any error in the associated VI hierarchy. It requires slightly more attention to detail than I'd like sometimes, and some judicious use of the Diagram Disable at other times, but I get by. 1 Thing I Hate About LVOOP: Not being able to have name collisions among unrelated class members in built apps (unless this changed in LV85? I haven't checked.). If I can have two VIs in two different (unrelated) classes both called "Set Value" (or something equally ubiquitous) in the Development Environment, I should damb well be able to build an app out of them. Honestly, if I'd known about that lovable little feature before I started using LVOOP, I might not have started. And then you wouldn't have me as such a big LVOOP fan . It's a game of inches, I tell ya.

QUOTE(yen @ Aug 19 2007, 11:04 AM) I tried it, and it made me feel all funny inside. I think I would need a keyboard like this one to really get used to it. As a side note, xkcd rules.

QUOTE(Ich @ Aug 20 2007, 02:30 AM) In general, yes, but only if you're on Windows. From the LabVIEW Help.... QUOTE(MATLAB Script Node (Windows, Not in Base Package)) Calls the MATLAB® software to execute scripts. You must have a licensed copy of the MATLAB software version 6.5 or later installed on your computer to use MATLAB script nodes because the script nodes invoke the MATLAB software script server to execute scripts written in the MATLAB language syntax. Because LabVIEW uses ActiveX technology to implement MATLAB script nodes, they are available only on Windows.

OK, it looks like the above site has finally recovered from all the attention it was receiving the past few days. However, the export functions don't work. I had to use screengrabs for everything. Nonetheless, this is a fairly decent likeness of me (after I added appropriate clothes): http://forums.lavag.org/index.php?act=attach&type=post&id=6462 http://forums.lavag.org/index.php?act=attach&type=post&id=6463 http://forums.lavag.org/index.php?act=attach&type=post&id=6464

With the all the recent distractions of Real Life (what's this wedding ring doing on my finger???) I've let my NIWeek hotel reservation slide and slide and slide until.... now. I've booked a room at the Omni for myself, but it occurred to me that other people traveling independently, like me, to NIWeek might benefit from doubling up on rooms, either to be closer to the Convention Center, or to save money, or both. So, does anyone out there have a room to share, or need a room? If so, post here! NOTE: I cannot personally vouch for the personal care or grooming habits of any LAVA members. In fact, I'd probably bet against them if I had to .

QUOTE(PJM_labview @ Jun 21 2007, 06:50 AM) It is now! That fixed it. Thanks!

I am developing an application (on Windows) that communicates with an industrial I/O network. The driver for the interface to this network allows me to poll the network for new messages, but I can also create an event (using the Windows API CreateEvent function) and register to have that event signalled when new data is available. This thread at the NI forums led me to use the WaitForSingleObject function to wait for the event to be set. Everything seemed to be on the way to success, until I ran some test code. It turns out that WaitForSingleObject blocks the entire LabVIEW process (menus/mouseclicks/rest of block diagram/etc.). I can't even, for instance, start one top-level VI running, then start another top-level one that calls WaitForSingleObject, because the WaitForSingleObject blocks everything! Switching the top-level VIs to different execution systems didn't alleviate the problem, either. Since the entire point of using these events is to enable parallel execution (which LabVIEW is normally pretty good at ), I'm kind of exasperated. Basically, I just need the WaitForSingleObject to not block the rest of my code. Does anyone here have any advice/experience with this? I can think of some rather complicated things to try (involving the application builder), but wanted to ask here before (or while) I go plunging wildly ahead with those.

QUOTE(alfa @ Jun 20 2007, 03:32 AM) I, for one, am interested in learning more about these armed prostitutes, so that I might avoid them if possible.