shoneill

I'm sure once these ideas click, it will seem simple.

Well here's something to demonstrate (in true Quick and dirty mode - the delete button isn't coded for example) to show the idea I'm getting at.

Shane.

I actually read that topic the first day you posted it, but I will revisit it to see how it may apply. The reason I have the list box is actually so I can do configuration as you suggest. Depending on the type of test each step will be executing, there may be different parameters necessary. So, I was going to have a different self displaying object based on the type of test that was chosen, just like a configuration dialog. But, all of these different test configurations would be test steps. I wanted to put all these test steps in an array -- if the user created a new step, I would just create a new test step object and add it to the array; if the user deleted a step, delete it from the array; moved a step in the listbox, I would move it in the array etc. This is where Shaun's idea comes into play. Then, when the user saves, I would go through all the test steps and get the "next" step in the array and put it in the private data of each current step (the base Test Step class's private data because every test step will need this information).

This is all quite feasible with what I'm proposing.

Each object in the array can be of a different run-time type (but all interpreted as a common ancestor in the IDE). When you have a new element, just insert into the array. If it's selected, get the object at that index and tell it to display it's editor window in the subpanel. Each object is then responsible for taking care of its own user interaction which aids encapsulation no end. There's no problem with having different kinds of children in a dynamic array at run-time thus mixing and matching test objects as you see fit. The only difference is that instead of calling a single UI, you extract the object at the required index and tell it to show it's UI. Once you've grasped that part (and implemented some working code), the rest is trivial really.

Shane.

I also agree X Controls can be a huge pain and I have battled with them on multiple occasions. Somehow they always end up working, but are often messier than I'd like.

Amen to that.

.... but I am a bit confused how TList would handle all the adding and removing of items in a the private data of a child class? It seems I would have to provide a protected accessor method to get the array of items for every child class I make, so that no matter the items I use the TList may call the accessor, get the array of private data, and manipulate it. Is this correct, or am I overlooking something?

Well this is where I might be able to chime in. I am a firm believer in code generalisation and have often run into this "problem" of having a nice re-usable scnario which gets snagged on the nitty-gritty details fo the actual implementation. One such thing is the "How do I edit the data in my (possibly unknown) objects using a generic interface (Listbox)"?. My answer to this is that the object whould handle this itself. I'm sure I've made references before to ustilising self-displaying objects for exposing their editing capabilities (I think it was in response to a preferences dialog) and I think this is a great way to implement this problem as well.

You can either go via text (using a table) and have the object tell you if the entered data is correct or you can have a sub-panel in your XControl into which the object to be edited places its own UI for editing. This way you can mix and match objects of different types and the editing becomes mush easier. You can expand beyond the originally-concieved functionality and the Listbox XContro becomes truly re-usable. Selecting a new object int he list unloads the ond object and loads the new one into the subpanel. Easy peasy. You can retrieve the new values by either utilising DVRs in the XControl (thus ensuring automatic synchronicity) or via events or via whatever method takes your fancy. You can also just take the return value from the UI when it exits (when the user says they're finished or when another item is selected and the current object is forced to unload). Easy peasy lemon squeezy.

But that's just my opinion man.

Shane

Ps I specifically mean a link to THIS topic.

Version 1: Would a more suitable OOP approach not be to write some private class methods to pick the values out of the variant and write them to the original input class, thus not breaking the object wire between input and output? On error, values are not retained, no dynamic dispatch problems.

I find the trust level that the right input object has the right filename to output exactly the right output object type a bit too high.

Or perhaps version 2: Read in the object from file, try to convert it to the same as the input object (so that you have the input object AND the loaded object) but then transfer the data using private class functions (Accessors) instead of simply outputting this loaded class. This too prevents breakage in the dynamic dispatch wire path. In the case of an error, the input object is simply passed out as the output object, no dynamic dispatch problems.

Shane.

What happens if the GXML throws an error?

Shane.

Finally you need to bundle this xml back into the class.

The XML isn't taken from or passed back into the class, it is a different representation OF the class. i.e. it's a serialisation / deserialisation of the entire class which is being performed.

I agree though that it should be OK, you just need tobe careful not to introduce nasty run-time bugs this way. It softens up the strict typing of classes just a little to let some nasty bugs in if you're not vigilant enough.

Shane.

My understanding is that according to the wire flow LV cannot (to 100%) guarantee that the object type on the wire is EXACTLY the same (not a child, not a parent) as the input but you're basically telling the compiler "Chill bro, I've got it under control".

If for any reason (sn error for example) the object you are changing the run-time type on IS different, you'll get a run-time error. The compiler should be telling you "Pfft, under control you say....".

I may have paraphrased some typical compiler jargon....

Shane.

I've posted a simply example of self-displaying objects on the Dark side. I was actually trying something with DVRs but it shows the principle of self-displaying obejcts also.

Link: http://forums.ni.com/t5/LabVIEW/LVOOP-DVR-with-non-blocking-Dynamically-dispatched-calls/td-p/2126824

Shane.

I don't have a good answer, but my previous post does link to a couple of examples which demonstrate how this can be handled in two completely separate ways. Not having used either in an actual app, I can't add more than that.

Well it depends on the usage intended but although it's no neccessarily trivial in itself, it solves a LOT of other encapsulation problems you might otherwise have. You can create new classes after compilation and have the neccessary UI already included since it's a private class method.

Shane.

Why doesn't the XControl initialise itself. That way there's much less code on your VI Block diagram.

Why not use some self-displaying objects? Simply incorporate a dialog display routine into your class definition and you have XControl light which allows your objects to display themselves in a subpanel for editing (perfect for Preferences dialogs).

The host program simply juggles Configuration objects and needs to know nothing of the actual configuration settings.

Shane.

We are developing on RT targets using cRIO and other embedded computers. The UI runs on a touch screen panel computer. This is decoupling in the correct sense IMO. The UI and logics run on different computers (kilometers apart), with different OS'es, in fact three OSes. The same architecture could also be used on one single computer with virtually no change in the code. The main point is that the UI is the "plug-in element", not the other way around. This is straight forward RT development using standard architecture learned at any RT course by NI.

That's all fine and sounds like a pretty good way of going about things. No complaints here and nothing I have posted earlier even hints at this being a bad idea.

The only point I was trying to make was that the term "decoupling" is inherently a grey-area thing. There are pieces of software which are obviously more or less decoupled from each other but it's not a universal scale where one can say I'm 90% decoupled...... Adding to this the fact that "full" decoupling isn't achievable in any real-world sense makes certain aspects of the discussion which were going on kind of silly (regarding whether the decoupling is complete or whatever). The act of decoupling (to whatever level is appropriate for a given task) is a good thing and I didn't mean to make any negative comments regarding the efforts to decouple.

Whether you call it decoupling, cliient-server, distributed producer consumer or whatever is secondary to the fact that the foundation you're building your software on is solid.

Shane.

How do you get this to work?

AFAIK Polymorphic VI cannot have DD inputs?

Correct, my bad.

Given that an API is essentially given, the class is set for the base class defining the API but it will accept child classes no problem. SO no DD, I had a speak malfunction.

Shane

hi all,

i am rotating an image without using NI Vision Toolkit 'but

it takes more time as image size increses, iwant max 20 ms for max (1024 by 980 )

if anybody knows better technique for the same please reply.

please find the attached code for reference

Your example VI has IMAQ functions in it so I can't run it here at work.

Why don't you want to rotate it using IMAQ functions? Why do all the work yourself?

Shane

Your example VI has IMAQ functions in it so I can't run it here at work.

Why don't you want to rotate it using IMAQ functions? Why do all the work yourself?

Shane

PS YOu can also simply set the coordinates for the IMAQ functions which allws you to specify areas of interest without even having to rotate the image.....

Why are you using polymorphic VIs? They are data bound. Shouldn't you be using dynamic dispatch or some other dark magic to choose the instance at run-time?

Personally I find the use of polymorphic VIs (The ones with drop-down list, not auto-selecting ones) with LVOOP because it gives a one-stop shop for the API, not neccessarily the underlying objects.

Each element in the polamorohic VI can be a different accessor or method class which the user can use at will. The input class is obviously always dynamic dispatch, thus unifying the advantages of both. This is all pre-2010. I'm aware some of these functions are now supported in LV 2010 natively.

Shane

If you want to call the same method on the data, but you want the behavior to be different based on the type (i.e., you have a different algorithm for each), this suggests the use of the Strategy Pattern. Check out the first chapter of Head First Design Patterns.

Cheers Paul. I must order that book.

I was just thinking of a method to achieve something at work when I thought of an idea which almost certainly has a formal name in OOP. Since you guys are generally better at the formal side of things than me I thought I'd pop out a question.

If I have an architecture where I have a multitude (>1) classes which could concievably be used to process a certain input data (format the same but contents different) I don't want to limit my expandability by hard-coding which class handles which data. If I then incorporate a method into the classes to tell me how well they can deal with the data and then choose the best fit, what would I call this approach?

For example: I have a control reference. I have a class to handle digital controls and I have a class to handle Strings. If All I have as an input is "Control" I send this to a function of the objects of my different classes and they tell me if (and how well) they can handle the specific object being passed - taking care of their own up-casting and down-casting as required.)

Shane

You make a good point here. But I don't think I'd want to make a blanket statement that you never want to implement something like this in a UI. Therefore I whipped up this little VI that does what I was thinking about. It borrows heavily from François' example. Just another tool for the tool box.

Yep, I get to experience that particular joy next week when I start training operators on my new UI. It's always a bit humbling when you get to find how easily your foolproof software can be fooled.

Why not simply decouple the UI part from the Instrument part using a notifier?

Shane

Ps This way the delay is determined by the instrument and is not hard-wired in the code (I have simulated different delays for different functions in this example).

User Input Delay Example_Intaris.vi

In case you haven't heard, LV 2011 is going to be largely a stability release. The entire LV team, acting on requests from customers, is going to pull back on features, focusing on bugs, performance and integration between existing features. There will be very little that is new in LV 2011, but we think customers will want it nonetheless.

This is the best thing I've heard about LV in quite a while.

Great stuff.

I'm having similar ponderings regarding a toolkit I'm (was) working on.

I wanted to offer up basic functionality in one package and then enable building up on this for extensions to the framework. I also wanted to keep some dirty secrets for myself, so it pretty much mirrors the topic being discussed here.

IF we stick to the absolute naming, can we introduce new code levels (I'm using many classes) by allowing the declared friend also declare its own friends and thus expand the code base? I'm pretty sure I'm not expressing myself correctly...

In other words, how do we make libraries portable yet extendable. A further issue is how to provide some pseudo-private functions (by abusing the friend mentality)?

Shane

Redownloaded and got the same error. Copied the file over to my flash drive and it works. Weird.

"The new features for LabVIEW 2011 will be a handful of very cool features (including a few from the LabVIEW Idea Exchange) and a huge number of bug fixes, editor performance upgrades and compiler optimizations. This decision comes in response to your user feedback."

Kudos to NI for making this call.

So stability will improve in 2011 right? Any chances of getting improvements in the 2010 SP?

I already find 2009 to be less than it should stability-wise. This news about 2010 makes me wary.

If I may plug an idea of mine on the dark side....

Shane

So the bottom line is that it doesn't work, it shouldn't work and it won't work....

OK. Just needed to hear that so that I can accept the "constructor" way of life.

Thanks

Shane

PS Just to clarify. I wasn't looking for multiple default valeus for a single class but a different default value for each class. I see how multiple constants for a single class with different default values would be horrible, but that's not what I was looking for. I only want each child class to have its own different default values. This would have worked with the special tagged VI AQ mentioned....

You can sort of...

I remember reading about this before, but the big black border (BBB) is kinda ugly.....

Can I save this in some form to allow dropping it onto the BD via a Palette or something?

Shane