Val Brown

QUOTE (crelf @ Jan 28 2009, 02:57 PM)

True, but then you'd need to design each little tester VI with the capability that, frankly, it shouldn't be exposed to - that's what the test scheduler is for. That said, the solution that Val has come up with might be your only hope.

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)

That's a shame - I'm sorry to hear that.

Anyway, you can run (use the VI.RunVI method) and abort (use the VI.AbortVI method, not that I think there is a reason that you'll need to do that). I'm pretty sure that pausing dynamically isn't an exposed method.

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)

I would strongly vote for getting LV scripting public and "legal". Publishing it via NI Labs could be a very good solution, also this way NI would get some feedback on stability of scripting. I guess NI would benefit itself on its own internal software development if scripting gets publicly tested via VI Labs.

Tomi

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)

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?

I solved this another way. No need for further follow up.

QUOTE (Val Brown @ Jan 14 2009, 01:47 PM)

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?

I solved this another way. No need for further follow up.

QUOTE (cosmin @ May 7 2007, 04:01 AM)

Hi,

here is a sample which looks at usb devices connected. It uses .NET.

cosmin

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)

Hi,

here is a sample which looks at usb devices connected. It uses .NET.

cosmin

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)

Oh great. I haven't even started working with Vista seriously and now I need to start thinking about (and avoiding) Windows 7.

I wonder if Vista will just be like Windows ME and we can all just agree to forget about it, eventually.

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)

Hi Guys

Paddling with my head above "lurksville" to ask of the wise ones

I have two relatively large and complex LabVIEW source code applications that we use internally with equips and sensors etc.

I just upgraded both of these applications to 8.5.1 from 8.2.1. ( and that was actually quite a ride but at least 8.5.1 seems more stable in certain areas.)

Both applications work in the LabVIEW environment however, When I try to use the build feature to get a preview, distribution or a build

I am sumarily (and rather quickly) booted out to windows on both apps, which are on different machines.

One app uses labVIEW classes the other does not yet they both crash so that notion is out.

Both apps have large number of VI's (800 to 1000+ (never counted))

Both apps were upgraded from 8.2.1 to 8.5.1 successfully, (howbeit not easily by any stretch of the imagination)

In both apps a number of VI calls are dynamic and many calls create independent instances to allow other processing dataflow(s) to continue yada yada

Both apps use dynamically called VI's, GOOP inheritance toolkit VIs , VISA and Field point resources however I am not thinking these in themselves pose any problems

that would cause the builder to crash. I just don't fully get it.

I'll admit building exe's is not something I do often yet I would have expected at least some error messages from the builder utility. Instead I cannot get a preview at all on either app.

I was wondering if anyone has

experience crashing into this proverbial wall with 8.5.1.

ANY clues would be appreciated :beer:

Thanks in advance.

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)

When autopopulating folders came out I experimented with them and found the same problem described by AQ. I promptly returned to using virtual folders and am glad I did, of course, for many other reasons as well.

I still encounter some mild frustration with projects in 8.6 with respect to saving projects. For instance, with my current project (virtual folders only!) I can save everything, close it, then reopen it only to find an asterisk on the project and a prompt to save it again if I try to close it. Showing the changes only results in the unhelpful message, "An attribute of the project has changed." This has been only a minor annoyance, though, since so far saving the project a second time has resolved the problem. Clearly there is some work for NI to do here. I submitted a request to NI on this.

Paul

I've seen the same behavior in a project that also did NOT have autopopulating folders.

QUOTE (crelf @ Jan 4 2009, 05:22 PM)

How do you all feel about online services that hold on to your backups for you? It's true that it's a convenient method of off-site-ing, but just how secure is it? How comfortable are you using it? Ten years ago, uploading all your personal files to another party online was considered madness due to the (perhaps irrational) concerns over security, so what's changed in our psychies that have made this more acceptable?

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)

...

see attached for wrapper error using the import shared library in tool menu.

It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell.

QUOTE (mattdl68 @ Jan 3 2009, 02:07 PM)

...

see attached for wrapper error using the import shared library in tool menu.

It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell.

QUOTE (mattdl68 @ Jan 3 2009, 11:38 AM)

Hi Irene. Thanks for the info.

I looked into doing a wrapper. But i don't Know c that well...

[/i]

Is this the kind of situation in which to use the DLL Wizard?

QUOTE (Aristos Queue @ Dec 30 2008, 05:22 PM)

I commonly program at 1440x900.

I assume that's because you're using a MacBook Pro with its native resolution.

QUOTE (MikePorter @ Dec 22 2008, 07:01 AM)

Basically the process is to use ADO (ActiveX Data Objects) to connect to the *.mdb file. If you are familier with using ActiveX the process is very straightforward. Plus there are free VIs available (check the NI user forum).

Mike...

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)

Where does it say that? Is that in a vision document on ni.com somewhere? I'm not trying to be beligerent - I actually want to know if that's an official mission statement from NI or not.

...and if it is, maybe it should be "as far as practical" instead

Yes, and no. When I want by-val I use LV-OOP (i have no other choice, not that I want one). When I do by-ref I use dqGOOP (code is native LabVEIW queues, so I can use it anywhere), unless I need something more beefy (inheritance, etc), then I'd use Endevo's GOOP (that does have transferability limitations).

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)

There are many examples of VIs that have been 'transitioned' into LabVIEW as a result of OpenG (fees have not been involved to my knowledge ...). So if you want to wait for NI to 'transition' VIs from OpenG, that's your choice. I, for one, am glad that I don't have to wait for NI to create every function or framework that I need or use.

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)

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)

Well, what if there were a separate, open-source library of a lot of functions which really should have been put into vi.lib in the first place?

Of course OpenG does exist, and it is your free choice whether to use it or not. It's not worth getting mad or griping about it. Just decide whether adding it to your toolkit makes sense for the realities of your situation and move on. Of course discussing that choice in this forum is just fine, I just don't get the apparent frustration you are expressing.

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)

Here, I just meant that if the by-ref implementation were part of native LabVIEW, if you tried to use a class that used by-ref, you wouldn't have to worry about which third-party toolkit was being used and whether or not you had it installed. And you wouldn't have to try to figure out some hacker's (like mine ) home-grown implementation.

Mark

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.