Val Brown

Definitely. And no matter what else, do NOT keep it under THAT hat. Sartorial Splendor just brimming over.

I'm drval both here and there. The original post was as a comment to the web article posted by Eli re: his OO example -- the example which was used in the NI Week hands on sessions about OO Design Patterns.

Omar, I think I must not be explaining this process clearly enough. UNTIL I did the download AND stated to use the VIPC file, there was NO mention ANYWHERE that ANY OpenG tools/VIs/etc would be needed. There SHOULD have been some mention of the need for OpenG -- beyond VIPM itself -- somewhere in the documentation online, the printed materials for the "Hands On" session at NI Week, by the instructors, and on the BD of the main.vi. We used the code during the hands on session with no direct awareness that OpenG was being used. Is that clear enough? val

CRELF, Yes I appreciate what you're saying here and it was appropriate to migrate this hijacked thread here, away from the example posted by Eli. My original point was simply that it wasn't announced -- or indicated -- anywhere that the example included OpenG. I was in the Hands On session at NI Week that featured it and no one there mentioned it either -- but did give instructions on how to download the example for our own use. Had Eli documented somewhere obviously that OpenG was not only used but necessary to run the example code, then I might have had somewhat of a reaction -- "Oh no, OpenG again and I have to download it...." -- but then it would have been my choice to continue BEFORE investing time and energy into an example that was supposed to show a Design Pattern, not just "how to do OO". All that having been said, my preference is to have parts of OpenG integrated into the distro LV so tat we can all be clear about using at least those parts of (what had been) OpenG and do it transparently. Or, if that isn't done, then let's at least have all of us post somewhere on a FP or in the documentation or, or, or about what the dependencies are, esp when one is OpenG -- or a special NI Toolkit like Sound and Vibration. It's just good style. val

Good questions.... Re: the first one I have to say I'm not entirely sure but perhaps SOME degree of phone support (perhaps only for PLatinum certified addons????) not just a blanket: "Sorry that's not our problem." Now that's not a literal quote but it was clear that there was no possibility of further information from NI and, frankly, I didn't blame them at the time. It was just unfortunate given my predicament. So that brings us to the second question. I could look up the exact dates and the exact LV versions involved but I believe it was during the transition to v7. The critical marker was that the "Legacy I/O" VIs in the serial palette were all deprecated and replaced -- internally -- and replaced with code that called VISA instead. That caused ENORMOUS problems for me -- it was essentially unworkable -- so I started looking about for a substitute and find the OpenG Serial library, which also didn't work. Follow up with NI was completely useless -- VISA was not workable given the prior working code. And the author of the (then) OpenG serial library couldn't offer any help either. It was a terrible couple of months because I couldn't go forward and, for a number of reasons, couldn't revert the code to what worked in the prior version of LV. Fortunately I did get some absolutely fabulous backdoor support (thanks to bp ) that arose out of conversations on LAVA -- so thanks to LAVA as well . That workaround persisted through another couple of versions of LV and it really saved me. Now one could say that NI dropped the ball first because it was how they did the deprecation of the prior Legacy Serial VIs that caused the fundamental -- perhaps. And I did give NI a lot of grief over that but also I didn't really know enough to develop a better work around and I also didn't know enough to make VISA work -- and that is now the basis of our hardware interface code. But the suggestion from a number of sources was to migrate to OpenG and that certainly didn't help in this instance. Now I do want everyone to be clear that I highly respect all those involved in OpenG. The work is exemplary, well organized, thorough, etc. But it didn't work for me back in the day. Today is another day and now, I'm looking into it, because of this OO Design Pattern example and because VIPM has now been introduced into LV. I just think that process should continue. val

I wasn't suggesting that NI should OWN OpenG, just that it should "live" in vi.lib and be officially supported by NI in addition to the support given by the OpenG community. My less than optimal experiences all occurred a number of years (and versions!) ago -- way before VIPM was available. VIPM does make a difference re: migrating code to newer versions and that would ease the pain, but it wouldn't have solved the specific problem I had "back in the day". And I agree that the Open Source community is an incredibly valuable community -- but I also lived through the C/Pascal/etc "wars" of the early days -- before C## was developed. I saw the battles and fights for control over unix and its variants and ALL of that was incredibly challenging to active programmers: just when you'd get a "complete" system approach going, new versions would come out and, like spring flowers and weeds, bugs would pop-up everywhere. One of the big plusses for me in moving to LV when I did (back in v4) was that I could essentially and almost completely avoid those kinds of problems: because I ONLY used code that was supported by NI. Now that's not entirely true because, in the early days of my project, I had to deal with legacy VB and C## code leftover from other consultants who "knew that was the better way to go" when it DEFINITELY wasn't. But it did serve THEIR purpose of trying to maintain value for themselves, as well as not having to deal with the fact that they didn't know how to make LV work, and also were embarrassed by what I (with no CS degree and "just" a domain expert) was already doing with it. The first several years were largely spent by me removing that crap from the project so that it was ultimately all native LV. The only thing now that remains non-NI has been the Blowfish implementation -- and I do so wish someone would update that. It's still got CINs in it! And we all know they are . So, no, I don't want NI to OWN OpenG -- just include it in vi.lib or, since it appears that won't be happening (at least "not yet") then I want NI to and the OpenG community to not ever move it to vi.lib. If it's home is going to be -- and remain! -- user.lib then that's fine and makes some sense for reasons others have stated, esp backwards compatibility. And it was developed by users, so of course that location makes sense...

OK, to be clear (CRELF because he asked it) I was definitely NOT suggesting to not include the appropriate info if OpenG is in your code. Rather I was asking for clarification from those who do it routinely about what specific info needs to be put into my code to be fully compliant. I'll follow up on the refs -- thanks! Jgcode, I appreciate that OpenG is Silver Certified. I didn't know but that alleviates that level of concern for me. And as we all know LAVA is the "gold standard" of highly talented, well-seasoned LV architects and aficionadi who give us all the benefits of their experience by giving us their time: and that is the single biggest gift anyone can give you. I think if (and I really hope it's WHEN) OpenG is fully integrated into LV "officially", it should then be in vi.lib as it should be part of the default instll: ie available to all users. But that's probably just simply an IMHO kind of statement.

nilib_rectangle is now available as a sub-palette in OpenG Picture Library (from a post further up on this thread).

Because it's not (yet????) an officially supported re-use library -- not officially supported by NI that is. But at another level you ARE right -- it should be there because it should be "adopted" by NI. Well at least that's my perspective on it. How many here use OpenG in their commercial products? Do those who do that include the appropriate EULA in the installer for their product? What is the proper way to include OpenG in a released commercial product? I'm sure these have been responded to in the past but they are now coming up as real questions for me, given the changes at NI (like including VIPM in the startup to manage addon tools). Any help would be appreciate, including refs to useful prior posts here on these issues. For those who are interested in what I've written most recently about this issue look at: https://decibel.ni.com/content/docs/DOC-15014#comment-17128. Thanks. val

My point exactly -- and why have to keep ALL of that detail in your head? If you're developing code for others all day long then, that could be a time saver, of course, but you then have to keep a lot of details in your head. Yes, that's probably true. And they might even have been WordStar fans...... Seriously though, it's a brilliant tool Darren it just doesn't (yet??) fit into the way that I work but, thinking about the cert exams.....hmmmm.

Yes, this is an aspect of the kinds of confusion raised by thinking this is "wrong" behavior and should be "handled in the background" by the structure itself instead of explicit programming actions on the part of the programmer.

FWIW I'm with you on that because I prefer to use the pallets. It's a consistent interface and I don't need to keep a lot of stuff in my head. Why do that when the resource is right there, just a click or so away? But that's me. I also only use a track pad -- never a mouse.

Posted Today, 02:41 PM Val Brown, on 09 August 2011 - 03:26 AM, said: An event is an event and, while each event will have a timestamp, none are polled but all are received -- regardless of the action taken by the structure. Exactly! Val Brown, on 09 August 2011 - 03:26 AM, said: An unregistered event is STILL an event -- and can't NOT be an event. I agree with that, as long as I can change it to: Val Brown misquoted by crelf said: (Hey! I did NOT say that the damn IDE did) An unhandled event is STILL an event -- and can't NOT be an event. My comments begin here: I think what you might mean -- to be precisely accurate linguistically -- is that an event is STILL an event -- and can't not be an event. AND a REGISTERED event is not JUST an event. It is an event that has an additional component (viz the "registration") and should, therefore, expect some additional response, such as to be received by some event handler in a way that doesn't just get "lost in cyber hell" if the programmer falls asleep at the wheel. Yes, I understand that argument and it's the basis for a great architectural discussion -- one that already happened about 30 years ago in some circles, but that's another story for another time (if you're not already yawning....). Now regardless of that history, it is exactly that extension that I object to -- because an event is an event. Even registering an event shouldn't have an influence on the event per se, nor it's overall construct unless it's an object and being an object becomes an intrinsic attribute of an event; or else the default IDE behavior should be to populate a case SOMEWHERE that explicitly receives that (now) registered event and forces an error if not explicitly handled by the programmer. Now the argument could be made that the event handler could have some other facility for handling registering events that do not have an explicitly declared interface; and essentially that is what is being argued here by those saying "isn't this a bug?". And perhaps that is an attribute that even should be integral to a well designed IDE but I'm not so sure about that -- at the conceptual level. And, yes, all of these various ideas would make life easier in some ways. So, in the end, it's frequently expediency that prevails.I just think that the philosophical issue -- history aside -- remains important, regardless of how it is answered in a particular IDE like LV. OK, back off the soap box and time for more beer...ah actually single malt. FWIW as a user I say: NI make it easy for us. At another level though I think these various changes are a problem waiting to happen down the line because they break (OK bend) the purity of the IDE at the abstract level.

The hot flow to where no one has gone before.... Slogan the Next Generation (and gender neutral)

The deeper we go, the better it gets...

Venting the frustrations and hopes of all users....

These shouldn't remain unregistered but acted upon....definitively!

I'm coming to this discussion after NI Week and having listened to the topic reverberating off the walls post Stephen's session. FWIW, I think those who think this is a bug or "should be changed anyway" are confusing the concept of timeout with the concept of "Default (Case)". Timing out the Event structure is not a guaranteed method to "catch" any and all unspecified events and why should it be, esp if a timeout is given to constrain it. An event is an event and, while each event will have a timestamp, none are polled but all are received -- regardless of the action taken by the structure. It's up to the programmer to "clean up the mess" he/she creates in registering the event. An unregistered event is STILL an event -- and can't NOT be an event. It's just not a very wisely programmed event: like an uncaught setjmp() back in the REALLY old days always "set your gets before you get sets into your code".... Ok so that's just two cents worth from a non CLA who is, in many ways, really old school so this is text and not in cool graphics.

I understand that point, however, IMO this wasn't a "bug fix". There are new features, and several are really outstanding. There are speed improvements (most notably for FPGA but nonetheless elsewhere as well), and functional extensions re: how the Project works to support builds, etc. As I say, one can always find things to complain about but FWIW I'm very happy. Then again a lot of people in the NI community do see me as being just a bit odd. In any event, now it's time for maybe or .....

That an interesting perspective -- and exactly the opposite of mine so far, esp around the user experience. All of the features from the Idea Exchange that were implemented were great improvements and I really love the Asynch Call functionality. It's always easy to find stuff to be disappointed about but I'm very happy with 2011 so far, esp knowing what R&D has been up to for the last development cycle. Time to start finding and submitting "bugs", Idea Exchange items, etc so that they get considered for the next go round. NI has shown that they are responsive: MANY users wanted "stability" over "new features" and IMO that is what they got in 2011, and still got some important new features. But your mileage may vary...

A graph was presented at NI Week. I'll see if I can dig up the reference or maybe someone else here knows. I just got in from my flight back home and it's REALLY late....

The food service at the party vividly demonstrated the inherent limitation of a single-threaded apartment model...

And can be pasted into the documentation area of VI Properties as a "summary" of what the entire VI is meant to accomplish...

Or just do that in the BD as your initial "sketch" of what you'll be actually coding and use your pseudocode as the comments...

Each version will look for relevant DLL from NI in the resource folder under the version's executable path -- unless you've specifically set any of the Call Function Nodes to other particular locations for the DLLs. If you use SVN you can always commit the 2010 version and name that rev accordingly the, when you want to open THAT rev in 2010, open 2010 first, then load the lvproj file from within that interface. If you just double click on the lvproj or VI file the last loaded version of LV will load and try to open the file.