Has anyone created a Visio-like VI app?

[tdurand]

I'm interested in creating a Visio-like app, where I can pick from a predefined set of objects (square, circle, etc.) and place them on a palette (Picture control).  I'd like to be able to use the mouse to select placed objects, either to move them, or to right click on them to look at / modify their properties.

Has anyone done something like this?  I've created an app like this, but without any mouse interaction on the palette.  The user positions and resizes the object through a cluster control.  It works nicely, but using a mouse would be more natural.  And more user-friendly, especially for those not used to LabView.

Bonus features that I'd like, but can't imagine that are feasible:  to use resizing boxes (e.g. at the corners of a square, to resize the square), and a ghost outline of the object when dragging it accross the pane or resizing it.

I've played a bit with incorporating the mouse -- looking up which object is selected, drawing the ghost outline, adding the resizing boxes.  But it seems that I'm trying to make LabView do something that the OS is probably better suited to do....?

The end goal is to be able to create a Visio-like screen made up of mostly-but-not-completely graphical objects and save its description in a proprietary format.

I've got LV8, though I'm more familiar with LV7.1.  And I've been a proud user since LV3.0.  If this can be done, I think I can do it. ...   Help?

Thanks!
Tom

[tst]

You're already using the picture control, which is a step in the right direction. The closest thing I can think of (which I know) is the UML modeller which was made for one of the GOOP toolkits.

While you're right that the OS should do this, this is not possible in this case, since all LV front panel objects are handled by LV and not accessible to the OS (because LV runs on multiple platforms). LV can't do it either, since you're creating your own interface, so it's up to you.

Processing mouse events is relatively easy using the event structure. You can get Mouse Up, Down, Move, Enter and Leave events and write a few subVIs to convert their coords to work with your interface and identifying which control you're on and so on. Creating a ghost outline should be relatively easy if you know the size and shape of a control and keep redrawing over a base picture instead of using a shift register to keep the latest picture.

The cursor stuff (like resizing handles) can be handled by using the cursor VIs (in the Application Control palette).

In short, this is definitely doable, but you need to handle all the corner cases (like the mouse leaving the picture control) to avoid getting stuck with a weird image and you need to remember that the picture control is not the best performing display out there. As long as you keep to vectoric data, you should be alright, though.

Here you can find some examples of picture control (ab?)use.

[Jarrod_S.]

I rather doubt this will be too terribly beneficial to you, since it doesn't solve your biggest issue. It may, however, help you figure out some procedural issues along the way. And what the heck, it's fairly cool.

This is an XControl I wrote with LabVIEW 8 that allows users to paint images onto an picture control. It has standard images like a square, circle, line, text, etc. It also goes along with what tst said about keeping a previous version of your image while you manipulate it. I do this in two ways:

1. To implement an Undo feature.
2. To allow the user to see the square or circle images as they click and drag to place it on the control.

Anyways, this is a really interesting problem and I hope you get something working! If you solve any mini-puzzles, feel free to wrap that up and post it! This XControl doesn't, however, allow users to click and move or edit images after they've been placed. It's fairly static at that point.

[tdurand]

Thanks for the replies.

Jarrod -- I like the Paint Demo.  I need to study it more, but it quickly told me I'm behind the LabView times again.  A control that has its own block diagram?  Wild!  That must be why it's named as an "Xcontrol"? ...  Something for me to look into some time soon, I think...

Many months ago, I had just started the creation of a top-level VI somewhat similar to your Facade.vi -- an event structure where I looked for mouse movements, button clicks, etc.  I think I was able to move a particular object around too, but I started to feel overwhelmed by the task.  I kept thinking -- today, the users of my tool wish they could use mouse input instead of using this "wacko LabView cluster control thingie".  And if I were to incorporate the mouse, I fear they would say -- wow, this program updates the palette very slowly, and/or lags behind the mouse movement/events.  And there's just too much coding to do for the potential flop.

If you had to start this from scratch, would you consider LabView as the tool to write this app in?  Or would you  prefer Visual Basic / Microsoft Net?  I've used LabView with lab equipment for years.  It's also very handy to use it for lots of everyday tasks.  But this one?  I'm not so sure.

Well, I guess my original intent in this post was to see if someone else had done it already.  I'll make myself some free time to see how feasible / user-friendly it could be.

Thanks again,

Tom

[tst]

I don't have any real experience in VB, but I can tell you that things which require dynamic UIs are not supported in the current state LV is in, because there is a very tight coupling between the UI and the code. There are ways around this (like creating "enough" controls and manipulating them or using the picture control), but they are ultimately not very efficient (the picture control, for instance, is simply a string describing how to build the vectoric elements and describing other stuff on a pixel-by-pixel basis and to change the image the string has to be modified).

So what you want is feasible (as long as the graphics demands are not too high), but you would have to create your own infrastructure and so it might be better to use another tool. As for whether someone has done it, as I said, I believe one of NI's (Endevo's, actually) GOOP toolkits has a UML modeller which basically does this, so I would try searching for that.

[Wiebe@CARYA]

"tdurand" <x@no.email> wrote in message news:1152592806736-389341@exchange.ni.com...
I'm interested in creating a Visio-like app, where I can pick from a predefined set of objects (square, circle, etc.) and place them on a palette (Picture control).&nbsp; I'd like to be able to use the mouse to select placed objects, either to move them, or to right click on them to look at / modify their properties.Has anyone done something like this?&nbsp; I've created an app like this, but without any mouse interaction on the palette.&nbsp; The user positions and resizes the object through a cluster control.&nbsp; It works nicely, but using a mouse would be more natural.&nbsp; And more user-friendly, especially for those not used to LabView.Bonus features that I'd like, but can't imagine that are feasible:&nbsp; to use resizing boxes (e.g. at the corners of a square, to resize the square), and a ghost outline of the object when dragging it accross the pane or resizing it.I've played a bit with incorporating the mouse -- looking up which object is selected, drawing the ghost outline, adding the resizing boxes.&nbsp; But it seems that I'm trying to make LabView do something that the OS is probably better suited to do....?The end goal is to be able to create a Visio-like screen made up of mostly-but-not-completely graphical objects and save its description in a proprietary format.I've got LV8, though I'm more familiar with LV7.1.&nbsp; And I've been a proud user since LV3.0.&nbsp; If this can be done, I think I can do it. ...&nbsp;&nbsp; Help?Thanks!Tom


Some experiences...


I used this strategy before:


Draw all objects on the screen.
Create a unique ID for each object (a counter, or something would do)
Draw all the unique ID's as color values in a offscreen buffer (picture control)
Use an event to get the mouse down.
Lookup the pixel color in the offscreen buffer
Convert it to object ID.


You can (or rather, you have to) make two draw routines for each object. The benefit is that you can draw lines thicker in the offscreen buffer, and you can draw a simple rectangle while the real objects are very complex. It might seem a bit complex, but if you have a lot of different objects, it pays off. Imagine writing a hitdetection for a bezier curve... That's no problem using this technique.


Also, the picture control is just a string. If you dig into this string, you'll notice that you can make a buffer. In this buffer you can replace one single picture object. So you don't have to redraw all the entire picture. This way you can get a real performance boost. It's convenient to store object info in the same buffer.


Draw the ghost outline in a separate picture control. Make this picture control transparent, and set it to the same size and position as the "real" drawing. Don't forget to use the events of the top level picture control! This way, you don't have to redraw the entire picture when you move only one object.


Regards,


Wiebe.

[tst]

---

Wiebe@CARYA wrote:

Draw all the unique ID's as color values in a offscreen buffer (picture control)
Use an event to get the mouse down.
Lookup the pixel color in the offscreen buffer
Convert it to object ID.

---

That was my method until someone posted the VI shown in the attachment (I cleaned it up a little, documented it and added an example).

If you have a series of points for your shape, then this should be a better method.

---

Also, the picture control is just a string. If you dig into this string, you'll notice that you can make a buffer. In this buffer you can replace one single picture object. So you don't have to redraw all the entire picture. This way you can get a real performance boost. It's convenient to store object info in the same buffer.

---

It would seem to me that it would be better to have a buffer of the picture itself (the blue wire) which will depend on the z ordering (i.e. everything "under" the currently selected element will be the base picture and all the other stuff would be redrawn). I haven't done any real examining of the picture control VIs, but I would rather avoid manipulating the string myself if only for the reason that NI might (please?) change the implementation to something more efficient.

---

Draw the ghost outline in a separate picture control. Make this picture control transparent, and set it to the same size and position as the "real" drawing. Don't forget to use the events of the top level picture control! This way, you don't have to redraw the entire picture when you move only one object.

---

That's an interesting suggestion.

Tom, if you do create something, it would be nice if you post it. Maybe we can improve it and make it into a general template.

[Ben]

Just another thought....

Rather than doing all of the drawing work from scratch (ouch), if you develop all of the basic shapes as customized LV controls, a "proto-type" of each can be used to do the dynamic dragging and re-sizing stuff and only when the the object is "dropped" grab its image and stuff it in the picture.

I am thinking the prototypes would be hidden and off-screen. When the use indicates they want a "square" the "square control proto-type control" is made visable and positioned over the picture control where the mouse is.

Ben

[Jarrod_S.]

That is an awesome idea Ben, and solves a lot of the problems involved here. I did something similar in my Paint XControl demo attached above for adding text to the picture. When the user clicks on the picture control with the text tool, I place a string control that was hidden at that point and allow them to type in some text. As soon as the value changes or the string loses focus, I take that text and paste it into the picture control at that point.

If we combine this idea with some of the ideas above for keeping track of object locations, this could be a very effective solution.

[Wiebe@CARYA]

"tst" <x@no.email> wrote in message news:1152715210744-390310@exchange.ni.com...
<a href="mailto:Wiebe@CARYA" target="_blank">Wiebe@CARYA</a> wrote: Draw all the unique ID's as color values in a offscreen buffer (picture control)Use an event to get the mouse down.Lookup the pixel color in the offscreen bufferConvert it to object ID.



That was my method until someone posted the VI shown in the attachment (I cleaned it up a little, documented it and added an example).
If you have a series of points for your shape, then this should be a better method.




That *is* a nice VI.


But it's not better if you have a lot of objects. The InROI has to be called for each object, so the search time will grow with the number of objects. The offscreen buffer only doesn't have this problem. The InROI method will also be hard to use with lines. And with larger circles you have to use a lot of points, or you'll get incorrect hits or misses.


One benefit is that you are still able to select objects even if they are totally covered by other objects. Guess a requirement specification is needed to make a choise. Switching from one to the other method will be terrible.





Also, the picture control is just a string. If you dig into this string, you'll notice that you can make a buffer. In this buffer you can replace one single picture object. So you don't have to redraw all the entire picture. This way you can get a real performance boost. It's convenient to store object info in the same buffer.



It would seem to me that it would be better to have a buffer of the picture itself (the blue wire) which will depend on the z ordering (i.e. everything "under" the currently selected element will be the base picture and all the other stuff would be redrawn). I haven't done any real examining of the picture control VIs, but I would rather avoid manipulating the string myself if only for the reason that NI might (please?) change the implementation to something more efficient.



Well, the picture (blue wire) is a string with the length of the string as the first 2 bytes (perhaps 4, I'm not sure). So you can store each object's picture, and replace them one by one whenever you need to. Then, if you need the picture, remove all the sizes, concatenate the string, and put the total size before the string (then cast to picture).


Or you can remove the size, and store the string, then concatenate, etc. and attach the total size.


If NI changes the way it works, you only need to remake the "remove size.vi" and "concatenate.vi" (provided that concatenation is possible).


The principle of the picture control is a virtual machine. The virtual machine itself is not that slow (unless you compare the 3d stuff to serious 3d stuff). It is slow because the subvi's that build the string are slow. Even worse, you need to call them each time anything in the picture changes. It is also slow because each time you draw anything, the pen is set (even if it hasn't changed).


With the buffer you get a trade off. It will require more memory, but it can be much faster depending on the situation.


With the standard picture control vi's, you are forced to build slow programs...







Draw the ghost outline in a separate picture control. Make this picture control transparent, and set it to the same size and position as the "real" drawing. Don't forget to use the events of the top level picture control! This way, you don't have to redraw the entire picture when you move only one object.




That's an interesting suggestion.


Tom, if you do create something, it would be nice if you post it. Maybe we can improve it and make it into a general template.



InROI.vi:
http://forums.ni.com/attachments/ni/170/194933/1/InROI.vi



ROI test.vi:
http://forums.ni.com/attachments/ni/170/194933/2/ROI test.vi