MikaelH

Just Create a method called "HasGUI" and let anybody override it and return True, if they want you to call it.

This CAR has been fixed in LV 2013.  The fix should be in LV 2013 Beta 2.

 

MikhaelH: If you're part of the beta program, you can download the LV 2013 Beta 2 and test it out.  If not, PM me and I'll send you a link to sign up and my email address to get you into the beta program.

Thanks,

I have both 32 and 64 bit versions for 2013b2 and I can test it this week.

I tried it the two projects and as soon as I run the Server Example all classes becomes locked as expected in that projects

I then Run the Client-Server Examples and all classes gets locked in that Project just like it should. I did press some buttons on the client, and then closed the Client-Server VI, and all classes got unlocked.

Then I close the Server Example VI and all classes in that project also got unlocked.

So I can’t reproduce your problem, sorry.

It could be that a reference has been opened in Project Provider Application Instance.

Are you using and Project Providers, such as G#, GDS?

I'll definitley put this is a Q-Drop shutcut-VI, just have to find an avaiable Ctrl-<key> combination.

First version

Ctrl-F Norms version (slightly modified)

Ctrl-Shift-F AQ's Version

For Loop pass Through-SwapTerminals.zip

www.symbio.com/goop should be restored now

Try the links to the right of this URL: http://www.symbio.com/services/qa-testing#goop

Symbio has moved around and cleaned up there web pages, but not got it working properly yet.

I've contacted them.

//Mike

I have a very simple written an example app taken from the Head First's design Pattern book.

Look at the Command patterns here:

https://decibel.ni.com/content/message/35117#35117

But basically you have to (not maybe have to, but if you want it scalable and reusable) use the Command Design pattern, (and together with the memento pattern to get a very scalable solution).

This is just one link that descripbes it.

http://www.codeproject.com/Articles/33384/Multilevel-Undo-and-Redo-Implementation-in-C-Part

Cheers,

Mike

You should not need to call the base ancestor's implementation, if there is a sub class you inherit from that overrides a base class method you should call that.

If you don't think that is right, you should not inherit from the sub class but instead inherit from the base class.

This way every DUT owns/has a Message Class in its attribute.

A message class type (e.g. Type A) could be used by DUT Type A,B and C, and Message Type B, could be shared between DUT Type D,E,F

Look at the example to see how I implemented it.

I don't know your requirements, but this is one design I could think of.

Maybe something like this:

DUT.zip

I’m sure we’ll get interface sooner or later to LabVIEW, in the mean time we have to implement it ourselves in different ways.

Here a thread and one example I use: http://lavag.org/topic/10621-interface/

I’ve not documented the Interface class template and how to use it, that comes with GDS.

But here is a quick instruction, this design only makes sense to Referenced Objects.

Add Interface Methods

Create a Normal class that should implement the interface

Add a design pattern: Interface

This is what gets created

Interface.zip

Cheers,

Mike

You’re right the interface isn't created, and that's because LabVIEW don't support Interface natively.

Maybe a normal inheritance association will work for you.

If not, there are ways of creating interfaces.

I have a Design pattern, add-on you can add to a class to let it Implement an Interface class.

But in your case just normal Inheritance might work just fine.

Let me know how it goes.

Cheers,

Mike

It's easy to do this, just using these property nodes.

I use it to show the new connector layout I'll suggest.

Are the 3 VIs running on 3 different computers and you like to synchronize them?

I would use one master VI/state machine, which sends simple requests to the three server-VIs.

The Server VIs would create a TCP-listener and wait for commands and execute them.

But I do agree with you I would like to know which questions I got wrong

I did ask them, but of course they wouldn't tell me, but it would be good to know in what sections I missed out in.

Maybe something like this:

Software Development Process: 3/5

Testing techniques: 1/3

OO programming 5/5 (of course)

X-Controls 2/3

BTW, I've not asked my company to send me to the CLA Summit yet, what do you think I should say to convince them to send me there?

This general question is well-characterized and addressed by YAGNI.

The beauty of using good OO design in your application is the ease of modifying the software, so I almost always use the extreme programming approach. And of course with a help of some tools It’s easy to modify the design.

...or...

Result:

My rule is that if the data in the attribute is huge, I use Reference based objects, just like NI does for the NI-IMAQ VIs. It helps the user not to accidentally use too much memory.

Or sometime I use a GDS design pattern “Add reference variable to class” to a normal ByValue class.

..and sometimes I even spell ...Aray... with 2 Rs

I use my own OCR function to read the text from the icon and I use the VI invoke node to write it.

So yes there is a way, but the text for the icon is not saved as text just as an image.

Is it a good practice to keep objects as DVRs within another object as shown below

Why not.

This will help you access the same object even if you branch the HAL Wire.

Also it helps you locking the resource.

Memory Wise, I think it could be an advantage, if the Aggregated Object Contains Huge amount of data.

By replacing that with a 4byte DVR reference value, the HAL-Wire don't become so heavy.

So e.g. if you branch the Hal-wire, or when you go into many SubVIs, those SubVIs has to allocate memory for this Huge amount of data.

But should you ever branch a ByValue Wire?

If you want to run things in parallel and accessing one object, you have to go with the Actor approach, or...just use ObjectByReference.

//Mike

I came across this thread:

http://lavag.org/top...qr-code-or-not/

and decided to dust off my old QR code generator, clean it up and see if it would be useful. I had no access to the formal spec-sheet, my info came from a combination of wikipedia, textbooks on Golais fields (fun stuff), and a lot of reverse engineering. As I remember things I am trying to actually document the code this time around.

Nice Work.

//Mike

Why do you say that?

When the Application builder renames VIs and X-Controls, the X-Control gets locked as soon as the VI using it gets loaded into memory. So my guess this feature or another hidden feature is used to be able to modified/rename locked items.

My guess is to be able to build exe-files containing x-controls.

If you email goop@symbio.com they will help you, or just PM me you license key number and I'll have a look.