jgcode

[INSTALLDIR]myApp.exe "%1"

Hi Martin

LabVIEW help says to use two hyphens - have you tried that??

Cheers

-JG

hmm, maybe Jim would love such right-click-menus? :D

lol

Good news is the Activation Server is now up - I have been trying all day

Do any of you recommend this book? The amazon site has some pretty negative reviews but all dealing with poor print quality. One of the more recent reviews said that this has been fixed. My biggest concern is that the book seems old. I think it predates LVOOP.

My prints fine. I have heard of those issues, but never seem them so I can't comment.

However, in terms of the content, I recommend this book, it was a fundamental text when I was learning and I am actually keen to re-read it soon.

It does predate LVOOP and I read it before I was using LVOOP but it talks about OOP and how they implemented those concepts using what they had available in the IDE at the time to create components\modules\MFVI's using LCOD.

In summary, a good read if you ask me.

Don't tell me. Let me guess. You can only use their search if you have a paid subscription

Bingo!

Shouldn't the software work under evaluation mode at least? Also, there is offline activation that is possible.

It depend what you are doing.

As per the cross post - you cannot build and deploy any applications.

At the stage of commissioning that we are in, that is a critical requirement.

Also, there is offline activation that is possible.

Each type of activation requires some-sort of connection.

Anyways, if the Activation Server is down for me, I am sure the local AE's are not going to be able to connect either.

[/font]

Making customers pay for bug fixes is indefensible. Making a bug fix release that trashes your installation because you haven't paid is just plain boorish.

I have made a similar gripe here as even someone with a paid subscription could get stuck if e.g. NI's Activation Site was down (or e.g. local internet connection was down etc...).

Hey, its better than NI's search function right now

In the past, NI usually uploaded the updated versions a few days before publishing it, presumably to make sure everything is fine with all the files and pages

Well, the Drivers link is pointing to the wrong file.

Reported here.

It is has been repeatedly posted that the LAVA search engine is not the greatest - so I don't see the point of posting about it again*

Just use google??

*I mean, you searched first for that, right?

Having a user navigate through 1000-5000 menu items in a right click menu seems prohibitive from a user-experience??

Yer, it's pretty similar.

This link is still working:

http://digital.ni.co...19?OpenDocument

Doesn't help as I want RIO 3.6 drivers

The 2010.SP1 site seems currently down.

Luckily I grabbed most stuff this morning

<edit> The whole site is down! </edit>

It was presented as a question rather than an idea. I agree - the IE is the best place.

Yes, AFAIK that is common behavior.

Why don't you write code that flattens the menu data to disk so it's persistent, then read it back on startup (or whatever)??

Thanks for the quick feedback Greg. I actually like the feature and looked forward to it being fixed for builds as I like to force the poly as the API (and only API) of my module\component.

I am curious how you became aware of this service pack? The date on NI LabVIEW 2010 Service Pack 1 Development System says 2/17 was the release date and your post was on 2/15.

Thats 2/15 - 2010

The title of this thread is LabVIEW 2009 SP1

It just so happens that the original link is redirected to the 2010 SP1 page!

So I make the methods Private Scope and the Polymorphic VI Public scope... ...everything is all good running from source.

Build time comes around and I start getting build errors (see below of the description), it doesn't point to the Class Library directly, but as it turns out, the calling VIs of the Polymorphic VI.

Unfortunately this also breaks the build when using non-Class VIs

(LV 2010)

Great job on the release

You can create similar protection for string/variant messages by building creator vis for the various message types, but I've never seen anybody actually *do* it. For that matter, I don't think I've ever seen anybody even suggest doing it.

FWIW I like using events most of the time, but I have been creating API's for the messages since I can remember - I agree that the process/object should not expose the message

In terms of the structure I started using what Justin presented after seeing it a@ NI Week, it was close to what I was doing but more defined/refined.

When I don't need multiple instances, a few examples API's looks as follows:

@Shaun R - exactly!

Hope we didn't scare Cat off! (I am going to blame you if we did)

I guess my original point is not getting across.

Yes it certainly is, as I stated this:

Given you have stated that your requirements are absolute decoupling, I still wanted to point out...

Because I agree with this:

"Decoupled" isn't a binary attribute--it's a gradient.

yepp. that structure you describe is called a "distributed software".

And because we do a lot of this stuff too, a distributed system that has multiple instances of client UIs that communicate with (usually NI Targets e.g. cRIO). Comms is either TCP/IP or OPC etc..

So I know what your requirements mean.

I just think, there is validity in discuss various options or gradients given the OP's question (and that the topic is interesting).

Because even when you write the distributed UI, if you choose to implement it in LabVIEW, then you still have the choices to decouple that code, so talk of references is relevant!

I'm not saying you should always decouple your UI from the core engine of your code. I'm just saying that if you are passing FP refs to low level code, you are not decoupled.

I do this all the time in many application. And I know full well that I am essentially tying these two parts together in a way that would not be easy to separate in the future. So, while this might be the right approach in many cases, it cannot be called 'decoupled' if you do this.

Given you have stated that your requirements are absolute decoupling, I still wanted to point out that I disagree somewhat with the above - somewhere in your code you need to communicate with the UI. If you encapsulate this code e.g. in a Class, then you could override it for different methods of communicating with the UI.

This may not be the best example but I have it lying around at home.

It was a small app and I decoupled the screen as to separate the code for ease of programming rather than any other reason.

For the most part I program in LabVIEW, so the FP is usually going to be LabVIEW.

It goes something like this:

Send the references from the UI to the controller via a message on startup

Set the UI references in the Class (that's it - they are never exposed outside of the UI Class again)

Controller pokes data from the Model (in this case a Map) into the UI Class.

Now my screen is just a bunch of UI Elements with no code behind them. I can change this with little fear of messing up underlying code.

Check out the LAVACR. Vugie and Franswa have already nutted out the VI Scripting.