ShaunR

It's still not clear to me what the overall goal is.

Well. I really can't think of any other ways to phrase it that I haven't already.....

then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc).

To provide (unofficial, demonstration) LVOOP solutions of CLD example exams

for the benefit of potential CLDs

Think of it this way guys.

An architecture astronought has designed the system (no matter how crap it is) and supplied a spec for a contractor code-monkey to code against. It's not the code-monkeys remit to re-design the system and re-write the spec (that's what the astronought is paid for) - just code to spec. If you (not you specifically, but generally) cannot code to spec, then your not much use within a team of coders lead by an astronought (you could be considered argumentative). That's the first rung you have to master before you can climb to where the oxygen is thinner. That is where the CLD sits - can you follow instruction and documentation. It may not be glamorous, or exercise your artistic/thought provocative nature, but it can be hard and daunting for many-even in classical LabVIEW. When it comes to OOP, it's harder by 10-fold if you aren't of that mind-set and those that are, maybe unsure of how to achieve it in LabVIEW. Whether it is close to real or not is irrelevent. It's to help those at that level by giving examples (in LVOOP) that they can analyse and compare.

I'm just suggesting (with all the super-guru LVOOP talent in Lava) that perhaps if examples of the CLD practise exams where demonstrated with LVPOOP, then maybe a lot more people would grok and maybe ken the advantages/disadvantages and methods. Maybe on your efforts you might see all submissions in the future in LVOOP rather than classical. But if the thread goes in the direction of "it's too simple and uninteresting for LVOOP" or "it's not a real project therfore LVOOP isn't applicable" then those are just weasel words and LVOOP has already failed.

James.

The CLA exams don't target code (you can use the same UML for both right?) and I'm not sure what you could take away from it. But sure, if you have an example, post it.

Just curious... are you looking for a sample CLD solution, or a sample real-world application based on the requirements of a sample exam? They have different requirements and will result in different source code. (For me anyway.)

I'm thinking of sample CLD solutions. (i.e to the spec in the example exams). The point is to show that identical results can be achieved with both methodologies using the exisiting classical solution as a reference to understanding the LVOOP.

However. I don't descriminate between the two. The CLD exam IS a real world application (it has a spec and a deliverable).

For instance, menu buttons are not being released.

You have a race condition.

Try this.

Lava is obviously a great place to pick the brains of the Labview community elite. It is also more LVOOP centric than other labview sites and has some awsome LVOOP talent. However. Most of the LVOOP concepts discussed are very advanced for the average LabVIEW programmer and centered around a few personal projects with no real focus on deliverable code, rather frameworks and eosoteric concepts.

Quite often we see potential CLDs posting their code, for comment, as a prelude to taking the exams. All of these are written in classical LabVIEW. If the LVOOP community is adamant that LVOOP is the future, then maybe some of the LVOOP gurus could post unofficial, demonstrative LVOOP implementations of the example exams (ATM, traffic lights etc). This would then give a focus on using LVOOP to achieve specific end goals, with well defined specifications and exisiting solutions for comparison - it would allow those using classical LabVIEW techniques to comparitively understand LVOOP in context with the classical solutions.

Is anyone up to the challenge? To provide (unofficial, demonstration) LVOOP solutions of CLD example exams for the benefit of potential CLDs? We see many different approaches in classical LabVIEW to solving the examples. Would we see a similar plethora of innovative LVOOP solutions? Perhaps it could even be a collaborative effort to produce them and maybe , once refined they could be proffered to NI as a candidate for an official NI solution along side the classical one!

So you want a singleton?

I think most of our confusion (well, mine at least) arises from the fact you are trying to cast at all. I thought you were questioning why you get the parent after the cast rather than a child of the type you select.

What is wrong with

That's not exactly true in this case, yes there is a coercion dot but what you now have in run time polymorphism whereby the 'wire' is an array of Parent by the data in that array is still a mixture of Child classes.

I don't see the need for the upcast (does it generate an error when it runs?) as you can wire the output straight into the Parent methods and the Child classes and any DD methods of the children will run.

If you wanted to use any specific (static) child methods then yes, you would have to convert the Parent 'wire' to the Child.

You should check out the Factory Pattern.

Indeed. That is why the To More Specific "casts" it to the parent type (because that is what the type is on the wire, coerced by the array concatenation). The only way you can "extract" the contained class (as you point out) is via the invisible selection methods in the LVOOP system (the equivelent in my analogy of "extracting" the bits).

Hopefully the image explains my question pretty well. Can anyone tell me why this doesn't work?

Arrays have to be of a single type. The child classes get coerced to the parent since that is the only type for which they are all compatable to exist as a single type within the array (and why you have coercion dots).

If you think about adding a Uint32 to a DBL array, the Uint gets coerced to a DBL right? So do your classes.

It could be for the mouse wheel

WControl

Does the mouse wheel stop working if you disable it?

Oh. And as an after-thought (an after I can edit, thought ). The reason for posting wasn't to provide a "faster" version of the NI one (thats more by accident since I didn't benchmark it). Just a version that you could see the diagram - Jims request, Feel free to change the calls to UI if it makes you happier because with this offering you can

That would be enough to make me nervous. I consider it best practice to leave all DLL calls in the UI thread unless the call you're making has explicit documentation stating it is "thread safe". Otherwise, correct me if I'm wrong, nothing is stopping LabVIEW from making parallel calls to the DLL which might stomp on some static memory. Maybe that's just a legacy of my C days and I'm being a curmudgeon, but my understanding is that's why the UI thread is the default for CLFN nodes? Now I do trust Shaun quite a bit, but he's not NI so I doubt he knows exactly what's going on under the hood of that call...

It's a good point. I have never seen it defined explicitly that "all LabVIEW.exe calls are thread-safe" (perhaps someone from NI could clarify). Or indeed (by extension) a definition of those that were or were not. However, thread safety is usually defined on a per dll (or in this case per exe) basis. So if the LabVIEW.exe wasn't thread-safe. I think we would all be in trouble. Anecdotally, I have never run into any problems assuming it is. Thats not to say that NI have not ensured all calls are indeed thread-safe on the assumption that no-one outside of NI without the internal knowledge as to what call is and isn't thread-safe. But I would be very, very surprised if they were mixed and matched within the exe.

Saying that. Calls to the labVIEW.exe that involve the user interface I do not make re-entrant on the assumption that it is a call within the UI thread. So if any were going to be an exception, it would probably be those.

What I did with PassaMak was that the engine would exclude any controls where the caption wasn't visible (it too used the label as a tag). The user then just showed the label instead of the caption for that "ignored" control/indicator. But as Yair said, it isn't common and it doesn't really make any difference if you do add all controls since who expects a control on a preferences dialogue not to remember what you put in it?

I wonder what extra overhead is in that password-protected VI?

Perhaps it has longer wires or more wire bends restricting the dataflow

Sorry to disappoint you!

Yer, it's so you can easily build your own plugin, Preferences Dialog, leveraging the NI Framework.

I didn't mean to belittle your efforts. It's great. Just not what I originally thought.

Yes, as per the VIPM info screen in the OP there are some dependent packages.

Thats a pity since I don't use VIPM or the tools:(

Not sure what you are referring to here - can you go into detail? Thx.

Nevermind. I think I got the wrong end of the stick. I thought it was adding a page to the LabVIEW preferences (from the LabVIEW toolbar).

Still sweet though.

The This VI reference is probably also redundant - you can get it inside the subVI.

Ditto with the get config file.

This is sweet. Huge improvement on the original. Nice work.

One question. Does it need the openG tools intalled on the users machine? (i.e what about distribution of the developers toolkit that these settings apply too)

1. if i go for 64 bit compatible LabVIEW software, is this good than 32 Bit? How and why?

Install both anyway, then if you run into problems with the 64bit (tookit not supported etc), you can just recompile and continue in the 32 bit version.

Q. If I own a copy of LabVIEW 32-bit, do I need to purchase a separate license for LabVIEW 64-bit?

A. Every customer who purchases LabVIEW 2009 or LabVIEW 2010 has a license for the 64-bit version.

Source

Yes, the VIs that ship with LabVIEW do support determining if a variant contains an LVClass instance.

I'm fine using this where needed, but I'd love to have a native implementation in the OpenG LabVIEW Data Tools Library.

Native implementation, to me, means that it uses primitives other than a Call Library Function or Code Interface Node (unless it's to call to LabVIEW.exe and the code is guaranteed to work at Run Time in both desktop and real-time).

I guess I don't really trust stuff that's inside password protected VIs and that's not in the palette. It could get removed or put into an LVLIB and scoped as private

Me neither.

for a generic deveopment system this is the sort of thing I look for:

• As many slots as your desk can handle (14 is typical - mixed, PCI, PCIe of varying 1x, 8x etc)
  
• AGP graphics card and slot (don't use up your precious PCI, PCIe slots)
  
• at least 1x9-way Dtype serial port (most have two).
  
• a parallel port (always handy for quick DIO).
  
• As many USB as you can find (typically they come with 2-4 but there is usually support for more on the motherboard via a breakout to the rear-buy the breakout with the PC because they are hard to source separately).
  
• At least 2x GB ethernet ports (make sure one is a "Intel Pro 1000" so that vision can use the NI high performance driver)
  
• at least 1x RS485 port (make sure it supports 4 wire although usually you can get away with one that only support 2-wire for most things).
  
• Fastest, meanest processor that the person who owns the purse strings will let you have.
  

Wordsworth are a safe bet in terms of support and product longevity for out of the box solutions (but expensive).

Protech are where all industrial PC manufacturers get their SBCs and backplanes from if you want to build your own.

Well. In that case you have two options.

1. Use a look-up table (which you have already said you don't like)

2. Ascertain the baud characterisitc and calculate it.

Baud rate generators are a function of the processor clock. So if you find one here that closely matches your ring control, you should be able to work out a function for calculating it for that device [i.e that devices clock - most use 18.432 MHz if they have any sense, e.g. UBRR = (18432000 / (16 x Baud rate)) - 1].

Well. I think you are over-thinking it a bit. However. If you use a ring instead of an enum, you can assign abitrary numeric values to your strings (the baud rates) since a rings values doesn't have to be contiguous. You can then wire it straight into your "Config Serial Port" VI.

Using a web-server in the past has fixed my XSS issues (among other things).

I am interested to try out the switch you have posted i.e. does it allow cookies to work in chrome?

No-eyed-deer. This is purely a mismatch in the URI which chrome resricts by default (firefox, Safari and explorer don't exhibit this behaviour). I have only had this problem with websockets since I have never had the need to send cookies from labview. So I guess if your cookie issue works in the other browsers but not in chrome, then maybe it will solve it- you tell me

I noticed that you had this in your JS

top.wpSend = wpSend; //for sending webpanel msg from HTML if SVG is embedded. Firefox 4 only (no Chrome)

I'm guessing this comment is because you get a x-server script error when using chrome to access a "file://" URI (i.e a local file rather than an "http://" URI). You can override this limitation by launching chrome with the command-line switch "-allow-file-access-from-files". You should then be able to connect after opening an html file on the local file system without an error.