shoneill

@AlexA, no, there is no static link between the VI "hosting" the UI and the UI itself, that's the point. The VI with the subpanel (not part of any of the classes but needing to display their UI) passes the subpanel on to the object and asks it to embed itself there (which it would then do). How the rest is done depends a lot on your requirements. If the call to the UI is blocking, then it can all be handled within the single VI which also embeds the FP in the subpanel with the entered values simply contained within the object returned from the VI call. This really is the super simplest approach. The VI to place the UI int he subpanel does so and waits for the stop button to be pressed after which it retrieves the current parameter set and updates the object accordingly. You have a single VI call with an object input and output (along with a subpanel input) and the new values are simply part of the output object. If you need an asynchronous approach, then your UI will most likely need to expose a user event where each changed set of object parameters gets sent back to the host until the UI is closed. But again all communications are done on the API of the parent since we no longer have any need (for this functionality at least) to know which child we0re currently working with. It's enough that the child knows what kind of object it is and acts accordingly). The "Host" VI only ever sees a parent object since this is the interface we've programmed to. There's absolutely no knowledge of how the UI looks except for the fact that at some stage it's embedded in the subpanel. Each object has it's own UI handler. There is no showing or hiding of controls, no dynamic parsing. Each object operates in its own world and the UI can be appropriately designed and encapsulated for that specific object's requirements. Shane. PS The TCP part is a red herring, it makes no difference whatsoever. How would you send the parameters anyway? That's a problem for your object model but is not affected by the UI aspect at all.

I'll offer my 2c here. As a general solution to the problem, point 1 is simply not going to cut the mustard. As I understand it, part of the problem here is the presentation of the values on the UI and how to handle the different modes of user entered data. Try telling a user to enter data via String/variant and you might as well just quit on the spot. This also pushes a LOT of errors from compile time to run-time which is not good. The option of dependency injection works absolutely fine IF you are using the objects own methods to interface with the stored configuration data. By implementing a simple UI for each (type of) class, you can keep the UI interfaces for user data entry completely seperate from each other with zero JSON, XML or the like in sight (unless that's actually your underlying data of course ). Granted the problem of programatically setting the values of the sub-objects remains but simply pushing the UI work into the objects themselves DOES significantly improve the ability to decouple the various input methods for users at least without creating any new burdens. This is simply the same as hard-coding each and every subclass functionality into your code and has almost zero expandability in the future. As a rule, you should be asking your objects to do things for you instead of telling them what to do. As such, I find the implementation of the UI interface (for this specific example) into the subobjects themselves the most logical, most flexible and safest method. Even the required knowledge of JSON formatting or Variants so that the object of choice will understand it is, for me, not a definition of an interface, it's broken encapsulation. Wiring up a strictly-typed terminal is always better. If and only if it is impossible to get what you want with strict typing then consider going down the dynamic typing road.

Personally? Option 3: Define each signal generation method into a separate class, several of which (corresponding to each type of measurement the device supports) are contained in the parent. Then move the UI (it can be a simple FP with controls on it) into the object in question and tell the appropriate object from the parent to place their UI in a subpanel of your choice (This can be a much simpler approach than it sounds). That was each and every object only exposes the parameters which are important for it's operation and extensibility is much easier in future. Shane

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.

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.....

But.... If I ignore what everyone says, then I must also ignore what you say..... D'oh, what to do? Coffee.

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