shoneill

The idea with the dialogs is good assuming you don't have the option active that any overrides of the abstract method are required to call the parent method!

I, personally, would NOT use a VI reference inherited from the parent but would provide each and every class with its own reference which can then be strictly typed and does away with the variant altogether.

I would also create a method in the parent class calles "Insert into subpanel" or something similar which takes a subpanel reference as an input and puts the appropriate VI in the subpanel.  Extracting the reference is breaking encapsulation.  Also, if the VI launched is actually part of the class, code from outside the class actually doesn't have permission to put it in a subpanel, or so I thought at least.

I can only speak for myself but I'm really willing to invest time in getting people sorted with problems like this.  It took me about 20 years between my last OOP class in college and actually finally understanding what was going on (it took LV 2009 to get me that far).

As  such I'm very much a n00b in this regard.  But once the <click> has been made, it totally changes your perception.  The <click> also can't be forced, it must come from within.

I have to admit I don't understand your points fully.

• What disequality are you talking about?  What kind of class type change do you want to detect?
• Again, I don't understand what you are bundling and unbundling in relation to the desired functionality
• I personally find launching a single clone per object and storing the reference within the object a much cleaner way of going about what you want to achieve.   It also pretty much removes the possibility of having a mismatch between input parameter data and object type (possible related to your first point?)  Each clone can be set up to display exactly the configuration data you require.

I've done this as an experiment in the past and once you realise that that correctly defined boundaries greatly simplify how you can work with the objects it's a lesson you'll find hard to forget.

Like drjpowell says, the idea is completely compatible with what you're trying to do.

You're so close....

Why don't you include the VI for the configuration panel in the class definition.  You can call a method of any given object o launch it's configuration panel (it will know which one to call) and then it can automatically pass back the correct data for the correct object type.  Expanding the class boundaries to incorporate the UI precludes many of the problems you are currently encountering.

Your object can maintain a reference to the control and read it out (strictly typed) as required.

I also had trouble in the beginning understanding the difference between what the IDE told me was the type of a wire and what was REALLY on the wire.  Using heterogenous collections like this, it's best to include as much of the object manipulation you can IN the object in question, UI included if possible.  You're already most of the way there with subpanels.

I would welcome the ability to guarantee race-condition free code but it must not replace the ability to do otherwise.

Breaking a VI because of race conditions is allowable only if the programmer has explicitly told the IDE that this code MUST be race-condition free.  Otherwise the effect on us poor mortal programmers will be a major burden.

Given the idea of being able to declare specific behaviour for certain VIs (as I would propose it) what else could we force? No data copies? No UI Thread? What else would be enforcable down the line in several years?

Your methodology in the picture you have provided is flawed.

You write that the type of your object is only known at run-time yet you want to set a very specific parameter which is not present in the parent class.  These two options cannot coexist without making some choices.

1) The object you want to work on is of type "Single Filament" or one of its children.

2) You only want to write the parameter IF the object of of type "Single Filament" or one of its children.

I don't see how you can have both at the same time.

If you NEED an object of the type "Single Filament" then you need to make sure of this at the point where you read it from the array.  The function "To more specific" has an error out which can let you know if a required type is compatible with what is currently on the wire or not.  Use this to your advantage.  Either write a routine to retrieve the first element in an array of a given type or do the cast to more specific BEFORE you want access your parameters as in the lower portion of your picture.  The code then operating on the parameters can go about its business in confidence knowing that the object is the right type because the cast was successful.

Note that such a cast does NOT change your actual object in any way.  It's not an expensive check.

Shane

I see some other posts have been made.

To further explain: Writing a piece of code to extract ALL objects from an array which adhere to a specific type (i.e. the objects are all of Type X or it's children or grandchildren etc.) is a perfectly legitimate way of doing things.  It's important to be prepared for the case where zero objects of that type are present.

I do this as follows:

Define a method in your class hierarchy called "Extract" and make it Dynamic dispatch.  Pass to it a parent object and do your checking in the method against the current type (DD terminal should suffice).  All the objects which do not throw an error on calling "Preserve Run-Time Class" are compatible with that object type. It can then output the newly tested object which is now of the correct type.

On your BD (outside your class boundary) drop a constant of the types of objects you require from the array (this constant simply defines the DD type), wire it up to an instance of the method you just created and pass the parent object array to it via a for loop with conditional indexing and there you have your fixed type array.

Which order did you install the drivers and LV IDEs?

Maybe try re-installing the CAN drivers after installing both versions of LV?

Charles,  Have you tried my version?

I have seen discrepancies between the "Input" VIs and the built-in LV event structure before.

I connect to my work PC via VPN and quite often after working from home for a day I'll come back to my PC in the office and find out that the mouse button information is not working via the "Input" VIs (mouse AXIS information is fine funnily enough) but they work absolutely fine everywhere else (Including LV itself).

I've often thought there must be some kludgy code down in the depths somewhere.  Or it could be a M$ problem with switching of contexts or something... I actually have absolutely no idea.

I like this toolkit but as with so much software, after peeking under the hood, there are some other things I'd love to be able to do with it.....

We want to be able to autocreate buttons with decorations for the frame so that scaling can be maintained.  I presume the trick lies in the Resource_Load and Resource_Save files which read and write the actual control file data.  One of these references must be for a decal whereas others must be for the vector graphic frame.  I would be very interested if anyone knows these indices and / or the format with which the frames are saved.  We would (in an ideal world full of chocolate) love to be able to modify the frame slightly to have a smaller radius.

Wishful thinking perhaps but it would be nice.

Current version (Downloaded on 22.October 2014) has an error in the filenames for the 6-state button PNGs.  I had to rename the PNGs to get it to work properly.  The preview of the button states doesn't find any images and produces an incorrect image preview.

your app is using more CPU but is it running as fast, faster or slower.

I mean... ok it takes twice as much CPU but you don't say anything about what it does and if it runs faster.

Reminds me of early SSD benchmarks which were surprised that the drives were using more power than expected and were disappointed until someone realised it was important to look at the power / GB Transfer number which suddenly looked much better since the drives were MUCH faster than traditional HDDs.

Scales are not labelled or with units, no perticular benchmark is mentioned, you don't give any information really.

Are you using some deprecated methods?

Won't a single Queue do what you want?  Your Queue represents a pool of available references and the consumer can remove one from the Queue, leaving two for your acquisition to re-use until your consumer is finished.  When the consumer is finished, it places the item back in the Queue and then the acquisition again has three available for storage.

You could theoretically run into the situation where the consumer gets the same image twice if the timings are just right.  To overcome this, perhaps implement a return Queue so that the acquisition, when choosing a reference for storage, first sees if there's anything in the return Queue and if yes, use it first (thus ensuring that the same image is never received twice by the consumer).  If the Queue is empty, take an item from the queue as in the original example.

This is very similar to Shaun's proposal except for the fact that the producer actually consumes the same queue it is filling in order to keep things fresh.  We don't refresh any reference which has been "locked" because this item is no longer in the Queue (we can treat this as an effective "Lock").

Shane.

8 Gig, Win 7 64-bit, LV 2012 SP1

I have found that artificially pinning the FPGA compiler to a single core really speeds things up (up to 50% faster).

I've never had FPGA code compile in 5 minutes......  Even simply benchmark tests take upwards of 30 minutes for me.... I'm jelly.

Just be careful with Symlinks.  Many Microsoft tools don't realise that these aren't real file or folder locations.

You can force MSBackup to its knees by putting a recursive NTFS symbolic link from C:\Randomfolder to c:\  The backup program will keep indexing the files until you press cancel.  At least this was true of all versions I had ever used, I haven't tested in Win 7 or later.

Lots of my code has a developer it's ashamed of.....

Hi Barlaw,

 

it is possible in LabVIEW and you do not have to use OO (LabVIEW is not really good at OO). The keyword here is asynchronously calling VIs. It does exactly what you do in your JAVA example:

 

Sebastian

It's actually much easier than that, it's simply two while loops in parallel.

Done in two minutes.

Shane.

Yeah but the setting is made in the STRUCTURE which is not yet executing but still blocks the UI thread.

I wish the Event structure had the option to ignore events which are raised before it actually starts executing.

What can really make things odd is when "Lock panel (...) until the case for this event completes" is enabled in an event structure that doesn't run, and it receives a UI event. Even though that ES isn't running it'll still lock the FP from seemingly far away... There's no way to probe your way into this. I set up stuff like that to test potential employees, to see if they have the LV skills to fix such a bug.

Now that's frustrating behaviour.  I ran into this once.  Once.  Never again.

What is not clear and unintuitive is what happens if you place two event structures and connect them to the same FP control. This is THE rookie mistake, after all, I just wanna add another function to operate in parallel when I press that button, right?

That works fine.  The static events do not share Event Registrations if they are in different structures.

It all depends on what the functionality is.  If both try to affect the control based on a new Value for example then you have a race condition but otherwise it works fine.

 It is my understanding that a structure will act similarly to a subvi in that *nothing* inside it will execute until all the inputs to the structure are available.  However, this is the only sane explanation I can come up with to describe this behavior. 

I know this thread has gone in a completely different direction but there IS a subtle exception to the structure behaviour and that is in a sequence structure each frame acts as its own structure meaning that the first X frames can execute before all inputs for other frames are available.  Depending on how you look at it ( or expect things to work) it could be a problem.  With things like globals, this can end up producing some counterintuitive behaviour.

I don't think this is part of your original problem but it HAS caught ME out on the odd occasion.