Val Brown

Thanks for the link. It's always good to have such tools "on hand", esp where Microsoft is involved.

QUOTE(PJM_labview @ Aug 29 2007, 04:32 PM) I agree with this and with Ben's point -- so I always disable the alignment grid and use, instead, the alignment tools in a more ad hoc fashion after the fact.

QUOTE(Justin Goeres @ Aug 28 2007, 10:27 AM) OK, thanks for the suggestion. I'm also wondering about whether there are any options that are available more directly from within LV itself?

In re: to another thread about determining whether or not a built application is running, Jim wrote: QUOTE(Jim Kring @ Aug 27 2007, 10:33 PM) On a somewhat (??) related note, I'm wondering how to get the version information of a built application during run-time. Any good ideas? I'm I just missing something simple and ovious -- an event that has been known to happen on any number of prior occasions, BTW.

QUOTE(i2dx @ Aug 27 2007, 01:15 PM) Yes but it is not an uncommon sentiment, usually stated in at least somewhat different language.

QUOTE(Justin Goeres @ Aug 27 2007, 12:43 PM) No I don't think NI is guilty of that YET but, my concern was provoked a bit recently by a thread here on LAVA that implied that NI might COMPEL the use of classes at some point in the future. To my way of thinking that would be an incredibly stupid and misguided thing to do. But my sense is that there are people "out there" who do present "OO uber alles"...

Joris: I think we agree on a number of points but also disagree on a few, or at least draw somewhat different conclusions from points on which we disagree. Yes, OO is, as you put it "a proved concept" in CS but, as you also point out, parallelism is a real problem for "traditional CS". It not only is NOT a problem for LV; rather, LV has been developed from the ground up with the seeds of true parallelism built right in. This is part of the reason that dataflow has been so fundamental to LV -- the way it is implemented in LV but allows for parallelism but also for determinism, and there are multiple means to implement these possibilities. A big concern I have for NI is that the desire to "bring in" the traditional OO-based CS-educated groups may seduce NI -- or others! -- into simply "leaving out" dataflow and the kinds of by-value OO that are -- and have been! -- possible for quite a while in LV. Adding in OO -- including by-reference -- is a wonderful idea. Implying that such an "addon" is the always and best way to program -- to make it into an implicit or explicit "best practice" -- is to do a profound disservice to the community of LV programmers, IMO. I'm glad to hear you also agree with that, while OO can be very useful in many instances, it is not only not the best approach in every situation, it is actually a less than ideal approach in a number of situations. That message needs to also be posted along with the efforts of the many dedicated and highly talented folks who have done so much to implement OO in LV, and who continue to refine and extend its capabilities.

See. I think you've really stated the issue very clearly: QUOTE(robijn @ Aug 27 2007, 10:28 AM) Essentially what is being asked -- to say it in this precise way -- is to make LV work like OO does in Java and C++. This means basically making LV be and IDE for OO as implemented in Java and C++. Now I have no problem with this KIND of goal -- as long as it doesn't become mandatory in ANY WAY. I think co-existence is fine but dominance or demand for the "pure" OO implementation AS IF it were inherently superior doesn't really jibe with reality and it esp doesn't jibe with LV and it rich history of dataflow programming.

QUOTE(Aristos Queue @ Aug 24 2007, 08:38 AM) Wow, the "I'm being repressed" refrain is what I was hearing for the "we NEED by-reference" OOP crowd. I'm all for co-existence -- I was responding to the SPECIFIC */ Comment /* that NI might COMPEL classes. Re: Tangent A: Of course not and that's part of my point in re: to the above as well, but I wouldn't call USING C -- ANSI C -- as "backsliding". I might actually describe it more like "returning to the source...", esp in re: to C++. Re: Tangent B: Yes, my point exactly -- it's a TERRIBLE, horrific image that G might only be seen as and IDE for the "real code". As for how much I might "eventually _want_ classes", I have to say: I don't really think so. But what I do think I want -- and already have access to (and have had for quite some time) is Private Cluster Libraries". Now THAT makes direct sense, in terms of LabVIEW itself, for what "classes" are meant to do, at least as far as I understand them. "Classes" always seemed to me like it was precisely the wrong term -- Class DEFINITIONS perhaps but not just "Class". One other footnote FWIW -- I've liked the internal, native to LV implementations -- ie the by-value implementations. But what I've also picked up in many of the discussions is that the by-reference adherents are really NOT happy. My other major point is that I really hope that NI doesn't try SO HARD to reach out to the "by reference" crowd that it loses touch with its core, historical community of users.

QUOTE(Justin Goeres @ Aug 24 2007, 06:30 AM) You've hit the nail on the head. The ONLY way(s) that I can think of to FORCE everyone to use classes would be for them to remove one of more central components of LabVIEW and, thereby, kick their most dedicated and long-standing customers right in the teeth. That would be the most classless thing that NI could, no matter how good the overall implementation was and how comfortable it made the transition for current C++ and JAVA users. If I'd wanted to have been COMPELLED to use objects I would have simply used C++ from the beginning. I really do NOT want G to simply become a "pretty" IDE for C++. It doesn't NEED to happen; doesn't bring ANY real benefits; violates the central design and organizing principles of LabVIEW; and is an affront to those who were not only "early adopters" of LabVIEW, but have used it consistently for years.

QUOTE(i2dx @ Aug 23 2007, 10:35 AM) I hope that Michael was using hyperbole -- it's not on any of the pallettes but I think it ought to be. 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. Second though I really don't see that using classes IS inherently any particular advantage -- not to mention the various competing "flavors" of OO implementation that are currently banging heads. As you point out, without CLEAR advantages to a new feature, most programmers doing real work won't -- and can't -- take the time to "play around" and see how it goes. In one very fundamental sense this is a kind of engineering in the sense that we are involved in "building" "devices" that actually "perform work" according to "specs and reqs". Third it really doesn't make sense for NI to alienate and disenfranchise its long-standing, advanced programming community that has "come up" using dataflow. Why have dataflow-based programming precluded by enforcing classes? That may appeal to some who've "come up" using classes but it really deprives LabVIEW of one of its most definining attributes. LabVIEW without dataflow -- but with enforced use of classes -- is really just a "pretty face" on Visual Studio. If this idea of compelling classes has any cogency at NI, I'd really like to know; and I'd really like to know who to talk to about making certain that this really BAD idea does NOT get implemented, even "accidentally". Third

QUOTE(David Boyd @ Aug 20 2007, 06:52 PM) I think that should be: lysdexics of the world untie! OK, but did you hear about the agnostic dyslexic who stayed awake all night worrying about whether dog exists?

QUOTE(NormKirchner @ Aug 20 2007, 02:18 PM) I can't even really reply -- I use a trackpad as I only work on laptops and refuse to carry anything extra. Plus, that keeps my hands right at the keyboard for making comments, etc.

QUOTE(NormKirchner @ Aug 20 2007, 11:55 AM) Is ALL of that on the back? Seems that would make if a very long...uh....shirt.

QUOTE(TG @ Aug 17 2007, 07:47 PM) It allows for a conditional stop, pre-empting the index count number of iterations given to it. So you could index the for loop to iterate 10 times but have a test for the first TRUE value (as in the example). In 8.5 the loop will stop whatever regardless of how many iterations it has completed whereas in prior versions, the for loop would continue to iterate all 10 times regardless of the test value.

QUOTE(David Boyd @ Aug 17 2007, 07:47 PM) Right, the retort might be: But isn't WiFi better?

How about (on the front): LB 8.5 -- More class than ever and on the back: It's a real V-choker! [V == down arrow]

QUOTE(jaegen @ Aug 17 2007, 02:19 PM) Excellent idea.

QUOTE(Michael_Aivaliotis @ Aug 17 2007, 03:01 PM) ANd the back would show the echo from the scream???

QUOTE(Aristos Queue @ Aug 17 2007, 01:46 PM) Hence the subVI approach -- encapsulate the kludge and at least give the appearance of an elegant else-if construction.

QUOTE(Aristos Queue @ Aug 17 2007, 01:29 PM) Nicely done summary. It's helpful for me to hear it -- and see it! -- again, and again, and again. Having worked as a single developer -- and essentially on a single project -- for a number of years, I know the various shortcuts that I've developed to implement these ideas. It's really great to see the support from them being implemented directly within LV.

QUOTE(Daklu @ Aug 17 2007, 01:06 PM) There are any number of ways to go about this and that partly depends on the data type of your A variable. One option is to "hide" all of your "dirty laundry" comparisons in a subVI. That subVI would output a typdef'd enum that resolved the operations on A (which would be input to the SubVI using an appropriate control. Keeps the kludge limited to a single subVI that is scalable by adding to the typdef'd enum output.

QUOTE(Daklu @ Aug 17 2007, 12:57 PM) Yes this is quite easy to do. If you want to implement precisely what you've written, use the Less Than function from the Comparison pallette and wire its boolean output to the input of your Case Structure.

My vote is also for the ToughBooks. If it's really a rugged environment, they are the best.

QUOTE(eatherto @ Aug 16 2007, 10:42 AM) It actually went very well for me and I've already deployed my latest release using 8.5 for the build, including the installer. I had some challenges with the migration but those were semi-intentional as I wanted to see just how robust the Project Explorer's Conflict resolution process was. Migrating toolkits was interesting -- esp DCT -- but that was also because of how I did it (viz brute force copying of the relvant \vi.lib\addons\... folders. This is NOT recommended procedure so the problems that arose were of my own creation. Even the legacy serial i/o functions are working in connection with serpdrv (for those of you who remember that!). I'm really loving 8.5, esp the extensions to Project Explorer.