Val Brown

QUOTE (crelf @ Jan 28 2009, 02:57 PM) Understood and, in principle I agree, but I thought that the OP indicated Test Stand was not an option so.... And, yes, queued messaging would be a good way to implement the "accounting" system, esp in terms of scalability. However, it seems that retrofitting is the name of this game and generally scalable solutions don't scale too well to such unique retro situations. At least that's been my experience.

QUOTE (crelf @ Jan 28 2009, 11:25 AM) I may be misunderstanding the application context but I believe that by using the same VI ref as for the VI.RunVI method you can also then use Invoke Method of VI.Control Value.Set to programmatically set the values of controls in the called VI. If there is, for instance, a Pause control (with that name) in the called VI, then specifying that name to VI.Control Value.Set would allow the caller to Pause the called VI.

QUOTE (Tomi Maila @ Jan 20 2009, 11:27 PM) One wonders what the reasons are for NOT doing this. It really does seem to be a "no-brainer". Perhaps if NI has a good reason to not do this and would actually disclose that reason (or reasons), it would be easier to accept that it would/should (maybe!) remain an "in-house treat", not for general consumption. I would certainly like to see it and have stayed away from using it -- even though it IS available -- simply because I ONLY want to deal with "official" releases. NI Labs is definitely a great way to go.

Here's a starting point that I hope is helpful. If you're using v8.6 on the FP use Controls/.Net & ActiveX/Windows Media Player. This will give you a container that support the functionality of WMP. Using Property and Invoke Nodes with the Reference it provides gives you complete access to WMP. If you're not using 8.6 -- but an earlier version -- some don't have this container pre-defined for you but that's not a problem. Just drop an ActiveX container and then point it to WMP. There are a number of examples available online.

Here's a starting point that I hope is helpful. If you're using v8.6 on the FP use Controls/.Net & ActiveX/Windows Media Player. This will give you a container that support the functionality of WMP. Using Property and Invoke Nodes with the Reference it provides gives you complete access to WMP. If you're not using 8.6 -- but an earlier version -- some don't have this container pre-defined for you but that's not a problem. Just drop an ActiveX container and then point it to WMP. There are a number of examples available online.

QUOTE (Val Brown @ Jan 14 2009, 01:47 PM) I solved this another way. No need for further follow up.

QUOTE (Val Brown @ Jan 14 2009, 01:47 PM) I solved this another way. No need for further follow up.

QUOTE (cosmin @ May 7 2007, 04:01 AM) If one were to use a version of this in a deployed, built EXE, what dependencies would need to be included in the build spec?

QUOTE (cosmin @ May 7 2007, 04:01 AM) If one were to use a version of this in a deployed, built EXE, what dependencies would need to be included in the build spec?

Yes, that's what I understand as well. In particular the File System that was supposed to be part of Vista is apparently a centerpiece of v7. Were that to happen, it would likely resolve a number of the issues plagued Vista, at least technically. Consumer confidence is a very different issue and, come to think of it, the real issue for MS was a decided lack of BUSINESS confidence in Vista.

QUOTE (Jim Kring @ Jan 12 2009, 05:37 PM) Forget about what?

Yes, actually I have but that was probably something like 24 years ago. And, yes, what's impressive about the failures of that Wizard is not so that they occur -- of course they do! -- it's really that the code is apparently officially supported etc. How it got to be officially supported and have that much challenge remaining in its deployed form is what is really impressive. And, yes, it's a definitely difficult challenge to craft such a Wizard. And knowing all of that made it that much more interesting to have it released.

QUOTE (TG @ Jan 5 2009, 12:56 PM) FWIW, I'm now using 8.6 having migrated code (over the years) from LV 5...through 8.5.1. My app is over 1400 VIs, with dynamic VI calls, VISA (now starting as of 8.5.1) but no Field Point and no use of GOOP inheritance. I have no difficulty with builds although, in the past, there could be problems related to specifying the dynamic VIs correctly, esp in including them in the build EXE or by other reference processes. I include everything in the EXE for security related reasons and you MIGHT want to try that just to see if you can do the build or at least force an error message. Another difference between your situation and mine is the use of FP and GOOP but why those would make any difference isn't at all clear to me (esp since I don't use them and don't know them). What problems did you have in the translation of the overall code? That may be where things are falling down a bit and might point to some issues for further follow up. I hope this helps.

QUOTE (Paul_at_Lowell @ Jan 5 2009, 09:19 AM) I've seen the same behavior in a project that also did NOT have autopopulating folders.

QUOTE (crelf @ Jan 4 2009, 05:22 PM) I still think it's madness and don't use such services but, then again, maybe I'm just really old school.

QUOTE (mattdl68 @ Jan 3 2009, 02:07 PM) It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell.

QUOTE (mattdl68 @ Jan 3 2009, 02:07 PM) It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell.

QUOTE (mattdl68 @ Jan 3 2009, 11:38 AM) Is this the kind of situation in which to use the DLL Wizard?

QUOTE (Aristos Queue @ Dec 30 2008, 05:22 PM) I assume that's because you're using a MacBook Pro with its native resolution.

QUOTE (MikePorter @ Dec 22 2008, 07:01 AM) It is also possible to use the Database Connectivity Toolkit that NI makes available. Like other toolkits there is a charge involved so check with NI about specifics.

Right OOP's not in RT -- yet -- and there are at least three different versions that you use (kind of like McCain's multiple houses I guess) and, yes, I understand that LV-OOP will "probably" handle "almost everything" (it's the "probably" and "almost" that bother me) and it will also prepare you for other flavors in the future (back to McCain's houses again), and, yes, it's very clear that OOP is a paradigm that doesn't fit for every use case or every application (and for some it's a particularly awful "force fit" but somehow these issues seem to be downplayed a bit in the discussions I've seen) and, if you haven't seen or heard the "OOPs the best" notes then, hmmm, your hearing aid has been turned down, and yes I will specifically report problematic posts whether from God or mere mortals. And no I don't ONLY use code that has been officially released from NI or that I write myself. But, when I have used OTHER kinds of LV-based code, it has frequentlyled to some form of long-term problem, limitation, etc. A good case in point for me is one of the implementations of blowfish encryption that was released for LV a number of years ago. Based on zlib.dll, it used CINs (a great advance at the time) but unfortunately that creates a number of ongoing issues, esp in terms of project management and such. One assumes this is at least one small part of how CINs have become, well de-emphasized shall we say, over the years. However, that implemenation was the only option available at the time, rather robust and full-featured; moreover, it was presented as if it would "probably" address "almost everything" related to encryption that you'll need, etc, etc. And now it hasn't been updated (so far as I can tell) for quite some time and, at some point, I'm going to have to switch off of it completely -- because of the CINs among other reasons. And BTW I was VERY happy with it for quite a long time -- thanks to whoever it was that created and released it! IMO it was yet again another thing that NI should have included in some form within LV. So yes I know that OOP is a tool and has nothing to do with being a "real" programmer or not. Having done some form of programming since the advent of PCs -- and even before that with PL/1, FORTRAN, etc -- I have no concerns about not being "real" -- nor about not being a programmer -- let alone about being a "real programmer". And, yes, I do talk with my wallet. I stopped paying for the Mac version right after SPT was released Windows only. Now that Mac is "coming back" isn't it about time to just recompile the code for SPT, etc and release those toolkits to a far wider market??? Or, wait a minute, is this an "OOPs" on my part because maybe I'm forgetting that even C/C++ may not migrate cross platform... And FWIW I've had customers who wanted Mac versions from the very beginning of my work with LV. That's ten years and counting. I've also had others who've wanted Unix versions as well. No requests for Sun yet though. And, yes, I know about http://www.info-labview.org/ but stopped browsing it because I really (also) don't want to hear more renditions/versions of "Mac vs Windows". I had enough of those kinds of discussions back in the Pascal vs C days. La plus ca change...

QUOTE (crelf @ Dec 18 2008, 02:43 PM) I'd have to look at my legacy materials from my initial purchase of LV back in 98 but, if I'm not mistaken, there were statements to that effect at the time. Until the SPT came out my application was entirely Mac/Windows transparent -- same LV code worked completely cross-platform (for instance) and that was one of the big motivations for using LV at that time. Dataflow, graphical interface, etc were other obvious reasons as well. I understand that you have three choices you use depending on context and again I think it's great that options are present. For me that simply complexifies the issue, esp in terms of portability of code. Yes there are lots of good reasons to make those choices -- as you and others have done -- but they're not universal solutions and for some -- like me -- those course create some problems. Maybe it's partly an "...old dog, new tricks" kind of issue but, if so, I'm still barking FWIW.

QUOTE (Omar Mussa @ Dec 18 2008, 01:22 PM) I don't think I've ever said that OpenG shouldn't exist, just that I choose to not use it. QUOTE (mesmith @ Dec 18 2008, 01:56 PM) Where I work one isn't a real programmer unless they do embedded development in C or VHDL! So every community has its bias. But I do fail to see where the OOP push in LabVIEW makes it less cross-platform compatible - is the LabVIEW OOP implementation (the native one) not supported on Mac and/or Linux? Mark Yes, every community has its biases. I'm not sure about the native OOP going cross platform but isn't it interesting that we even have to ask when a fundamental mission statement of LV was to be transparently cross platform "as far as possible"?

QUOTE (jdunham @ Dec 18 2008, 11:08 AM) Part of my frustration is over the continuing "by-ref" vs "by-value" discussions and the implications that, unless one uses OOP etc, then one isn't a "real" programmer. BUt the essence of my frustration is with how NI has, IMO, gone off mission in dropping over the years true cross-platform development in favor of a Windows-centric approach that again, IMO, takes them off mission in additional ways. Yes, it's my choice and I've made my choice -- which I've also discussed in some other threads. And, yes, my situation is different from others, perhaps even the majority of others, here; however, I think it's important to at least voice the other perspective. Re: open-source, I'm not a big advocate of open source. Having come up through the "unix wars" of the early 80s, I'm not at all interested in having to balance so many different distros and versions within my overall code. I know that's also an unpopular perspective here -- and it isn't meant to imply ANY criticism of OpenG or the efforts of JKI and others who have truly done marvelous work -- but it is what's so for me. Perhaps OpenG could be transitioned INTO the overall NI distro -- with appropriate fees involved, etc -- and then I would be happy to use the code. At this point, as a single developer, my choice is to remain with the corporate profile of NI supplied/supported code, with the added support of all of the knowledgeable folks here at LAVA!

QUOTE (mesmith @ Dec 18 2008, 10:12 AM) Yes, and again, to be clear, this is one of my biggest gripes in all of this. WHATEVER is not native LV, is no longer (as) portable across all LV implementations. It would be as if someone created their own Signal Processing Toolkit and started pushing for it to be used as "a standard" because it "seemed better" in some ways.