Has anyone created a Visio-like VI app?

Question

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

Answer 1

"tst" <[email protected]> wrote in message news:[email protected]...
<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