Jump to content

LVOOP Drawing Tool


Recommended Posts

Yesterday I was giving a presentation titled Software Development with LabVIEW Object-Oriented Programming at NIDays in Finland. As part of the talk, I prepared Drawing Tool, an example application that utilizes LabVIEW Object-Oriented Programming and tries to introduce several LabVIEW Object-Oriented Programming techniques. It is a simple drawing application for drawing various shapes of different colors on a drawing area. The application is based on a state-machine where the state of the application is presented with several LabVIEW objects. The application demonstrates how a simple state machines based application can be created using LabVIEW classes as state parameters.

post-4014-1210251069.png?width=400

ALERT: The intention of the application is to show various LVOOP features and programming techniques. To make the application easily understandable to LVOOP beginners, I used architectural choices that make the application more readable rather than more sophisticated and easier to extend. So the example application is not intended as a guide how to develop LVOOP application but merely as an example introducing how several LVOOP techniques can be used in application development.

Download Drawing Tool

Download the NIDays presentation slides

  • Like 1
  • Sad 1
Link to comment

QUOTE (Aristos Queue @ May 8 2008, 04:20 PM)

Are there any objections from you if DevDays presenters in other cities use material from your presentation? If not, I'll add it to my "list of resources for presenters" that I keep getting asked for.

My general principle is that my presentation material cannot be copy-pasted to a presentation of someone else. However, under certain circumstances I can allow using my presentation material; when a clear attribution to expressionflow.com is used when the material is presented, I can consider allowing the usage of the material. However, this should be agreed with me as by-case basis.

EDIT: If you are interested in aquiring the right to use the material in NI presentations, you should contact me directly.

Tomi

  • Like 1
Link to comment

QUOTE (Tomi Maila @ May 8 2008, 09:44 AM)

My general principle is that my presentation material cannot be copy-pasted to a presentation of someone else. However, under certain circumstances I can allow using my presentation material; when a clear attribution to expressionflow.com is used when the material is presented, I can consider allowing the usage of the material. However, this should be agreed with me as by-case basis.

EDIT: If you are interested in aquiring the right to use the material in NI presentations, you should contact me directly.

Acknowledged. :-)

Link to comment

Hi Tomi,

I really have to thank you for posting this example. It is starting to make this OO stuff click for me.

I have been going over your example and re-reading the article by Aristos Queue. I am not comforatable enough with the terminology to summarize what I have learned yet. While conducting this exercise, I have asked myself a couple of questions that I can't answer. I hope they are easy for you (or others).

1) How would I modify this example if I wanted to change the color of an object already on the screen? (undraw all until I get to the one I want, fix it, and then re-draw?)

2) If I wanted to allow the user to click on a previously drawn object and change it to a different shape, how can I use the click coordinates to figure out which of the objects it goes with?

3) Your examples keeps the shapes in what appears to be a stack that you add to or remove from. How does LVOOP let me get at arbitrary shapes with out popping them of the stack?

I hope these Q's are very basic.

Still trying to "slip another tool into my bag",

Ben

Link to comment

Is there a way to view the relationships of members of a class? Something that shows what is the Parent and what is the child.

I'm trying to answer my own questions (above) so ti seems I should look for the parent of all of the objects since my "change color after the fact" change request affects all of the drawable objects.

Or am I going at this the wrong way and I should expect to (?) write a new method (?) for each of the shapes?

Still trying,

Ben

Link to comment

QUOTE (neB @ May 13 2008, 07:42 PM)

The figures on the image have a certain order as layers from the bottom to the top of the image. The figures on higher layers can exist on top of figures on lower layers. Therefore the figures need to always be drawn in order i.e. you simply cannot change the color of some figure by redrawing it and ignore all other figures as this would make the drawn figure to appear on the top.

In this example I would do the color change the following way.

- Iterate trough the Picture stack to see which figures are selected. To iterate the stack, use a method similar to Picture.lvclass:Draw.vi which iterates the stack and draws each item in the stack.

- For each selected item in the stack, call the set color method to set the color of that item

- Then call Draw method for the whole stack, the whole picture will be redrawn (do not undraw, it's more complicated)

QUOTE (neB @ May 13 2008, 07:42 PM)

2) If I wanted to allow the user to click on a previously drawn object and change it to a different shape, how can I use the click coordinates to figure out which of the objects it goes with?

Create a selection tool in a similar way to the other drawing tools. For the Mouse Down method of the selection tool, iterate the picture stack the same way as above from top to bottom to see which item was clicked. The way I would do it is to add a new dynamic dispatch method to graphics object class for checking if this particular object was clicked. Then implement the method on each of the shape classes. The method would return true if the click occurred on the item. Then when iterating the stack, class this method for each item in the stack. The first item this method returns true would be the one that was clicked on.

QUOTE (neB @ May 13 2008, 07:42 PM)

3) Your examples keeps the shapes in what appears to be a stack that you add to or remove from. How does LVOOP let me get at arbitrary shapes with out popping them of the stack?

You can use array instead of the stack. I used the stack to show how data and call recursion work in LVOOP. If your items are in a stack, you need to iterate trought the stack. There are no references. However memory wise, LabVIEW can iterate the stack in-place. However, if you use recursive calls to iterate the recursive data structure, you end up having many clones of your iteration methods in memory. At least as long as AQ decides to implement something called tail recursion. Last time I asked, the answer was it won't be implemented anytime soon.

Tomi

Link to comment

QUOTE (Tomi Maila @ May 14 2008, 06:59 AM)

The figures on the image have a certain order as layers from the bottom to the top of the image. The figures on higher layers can exist on top of figures on lower layers. Therefore the figures need to always be drawn in order i.e. you simply cannot change the color of some figure by redrawing it and ignore all other figures as this would make the drawn figure to appear on the top.

In this example I would do the color change the following way.

- Iterate trough the Picture stack to see which figures are selected. To iterate the stack, use a method similar to Picture.lvclass:Draw.vi which iterates the stack and draws each item in the stack.

- For each selected item in the stack, call the set color method to set the color of that item

- Then call Draw method for the whole stack, the whole picture will be redrawn (do not undraw, it's more complicated)

Create a selection tool in a similar way to the other drawing tools. For the Mouse Down method of the selection tool, iterate the picture stack the same way as above from top to bottom to see which item was clicked. The way I would do it is to add a new dynamic dispatch method to graphics object class for checking if this particular object was clicked. Then implement the method on each of the shape classes. The method would return true if the click occurred on the item. Then when iterating the stack, class this method for each item in the stack. The first item this method returns true would be the one that was clicked on.

You can use array instead of the stack. I used the stack to show how data and call recursion work in LVOOP. If your items are in a stack, you need to iterate trought the stack. There are no references. However memory wise, LabVIEW can iterate the stack in-place. However, if you use recursive calls to iterate the recursive data structure, you end up having many clones of your iteration methods in memory. At least as long as AQ decides to implement something called tail recursion. Last time I asked, the answer was it won't be implemented anytime soon.

Tomi

Thank you Chris and Tomi,

I appreciate your replies and will attempt to understand them. :rolleyes:

For the application I have in mind to try out the LVOOP technology, the array version rather than the stacked version will probably fit my needs better.

BUT.... before I get too carried away...

A lot of the right-ups of LVOOP make mention of in-place and by-reference features.

can anyone speak to the performance of a "well-structured-and-implemented-LVOOP" application?

THe app I want to try this one will be supporting two 24 inch touch-panel screens that will serve as arbitrary (i.e. user defined) user interfaces, where I need to provide good response times (less than 1 second 1/4 second or less would be good). So when a user touch one of the screens I have to able to quickly ID which object was clicked and perform what ever operation is appropriate for that widget. The "what ever operation is appropriate " phrase makes me think that the dynamic dispatch feature of LVOOP will be very handy and also allow for adding additional widgets to the screen as time goes on.

THis app will also have to run as an executable.

Is LVOOP solid enough to run as an exe?

Hoping I finally found a good excuse for learning LVOOP,

Ben

Link to comment

QUOTE (neB @ May 15 2008, 03:39 PM)

For the application I have in mind to try out the LVOOP technology, the array version rather than the stacked version will probably fit my needs better.

Just quickly now... The recursive case is a "must" when you don't know in advance the type of the nodes in your recursive data structure. In array case your nodes are always of the same type and the recursion from one node to next happens in the same way always. However there are cases when the recursion itself may depend on the node. Then it's easier to represent such a recursive data structure with some sort of tree or graph where each node of the tree or graph can be of different type. Only the nodes know how to recurse the tree or graph further so you cannot represent the data structure very well with any predefined format. Also recursion trought the data structure is easier with call recursion rather than any other method.

As an example think of drawing of arbitrary shapes, where some but not all shapes can contain subshapes. For example to draw a house one needs to draw many windows and a door. To draw a window, one needs to draw some squares etc. However, to draw a square, one only needs to draw a square and nothing else. The simplest way to represent a shape house is as a collection of subshapes. To draw a house, one simply draws all subshapes. As subshapes can contain further subshapes, the drawing of the house ends up to be a task where the recursive data structure "house" is recursed with call recursion of method Draw.

Ben, I'm sure you will learn LVOOP... after a year you'll be answering LVOOP questions here and on NI forums. :)

Link to comment
  • 2 weeks later...

Say I wanted to deploy Tomi's example as an exe that would allow other shapes to be added latter (example:customer wants an octogon added)...

from what I understand I would have to re-compile the library that houses the class.

Are there any other things I'd have to adjust to allow for the addtion of other shapes (aside from the menu that allows which shape to drop)?

Ben

"sneaking up on OO one concept at a time"

Link to comment
  • 7 years later...
  • 1 month later...
  • 2 years later...
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.