| Re: border around draw widget [message #50536 is a reply to message #50343] |
Wed, 04 October 2006 01:09   |
Laurens
Messages: 41
Registered: May 2006
|
Member |
|
|
Rick Towler wrote:
> I think we have strayed way off on this one... While JD's suggestion is
> clever, from a usability perspective I don't think it is as effective as
> a colored border or a color shift of the image. And adding a border is
> trivial.
>
> If you haven't done this already, you'll want all of your draw widgets
> to share the same click event handler. You mention in your original
> post that your displaying gamma-scans. I'll assume these are images of
> some sort. I'll further assume you are using direct graphics and are
> displaying the image using TV (I know in reality you are using one of
> David's or Liam's improved versions).
>
> The one thing I don't know is how you are storing your application data.
> You are going to need to keep the selection state of each draw widget
> and a copy of the image displayed in the widget. In my example I put
> them in a structure with the fields "image" and "selected" and store
> that in each draw widgets UVALUE. You may already have this data stored
> someplace else.
>
> pro drawClick_event, ev
>
> WIDGET_CONTROL, ev.id, GET_UVALUE=thisData, /NO_COPY
> WIDGET_CONTROL, ev.id, GET_VALUE=thisWindow
>
> if (thisData.selected) then begin
> ; window is currently selected, deselect
> WSET, thisWindow
> TV, thisData.image
> thisData.selected = 0
> endif else begin
> ; window is currently not selected
> WSET, thisWindow
> OPLOT, [0,0,1,1,0], [0,1,1,0,0], COLOR=255, THICK=4
> thisData.selected = 1
> endelse
>
> WIDGET_CONTROL, ev.id, SET_UVALUE=thisData
>
> end
>
>
> You'll notice that the border isn't perfect but it is close. Also,
> you'll want to modify the COLOR value accordingly.
>
> -Rick
>
>
>
> Laurens wrote:
>> JD Smith wrote:
>>> On Wed, 27 Sep 2006 23:35:34 +0200, Laurens wrote:
>>>
>>>> Thanks very much for that explanation!
>>>> Could you tell me how to make such a widget-object? It sounds like
>>>> something I was already thinking about...
>>>
>>> It sounds fancier than it is. It's basically an object, which:
>>>
>>> 1. Sets up a widget heirarchy in the normal way (usually in its Init
>>> method).
>>> 2. Saves its "state" information not in a structure in a UVALUE but in
>>> the class data itself (e.g. self.*).
>>> 3. Calls XManager (often, but not necessarily, in its Init method) to
>>> generate events on that widget heirarchy.
>>> 4. Uses the trick I outline to inject the events flowing forth from
>>> the widgets created to some class method (often named "Event").
>>>
>>> The main advantages of this method:
>>>
>>> 1. You get state information "for free", quite nicely mapped to class
>>> data.
>>> 2. You automatically avoid common blocks for state info, with their
>>> associated collision risks if multiple identical widgets run at the
>>> same time.
>>> 3. You are never left with state information "in the air", if you use
>>> /NO_COPY to be efficient when retrieving your state structure from
>>> a UVALUE. This greatly aids debugging, since crashes to the code
>>> usually can be recovered from with a simple RETALL.
>>> 4. You quickly realize that the normal event flow embodied in "normal"
>>> widget prgramming is limiting, and can roll your own communication
>>> among objects that suits your needs. This is particularly useful
>>> if you have many different perhaps unrelated application components
>>> that need to communicate with eachother.
>>>
>>> A schematic usage would be:
>>>
>>> oDraw=obj_new('SelectableDrawPane',base)
>>>
>>> which would place a new compound widget into base. It might implement
>>> some methods "Select" and "DeSelect", or you could have it trap the
>>> selection "clicks" and automagically select/deselect itself. Once you
>>> have the apparatus in place, you can then have fun implementing other
>>> methods for your object, drawing and erasing, etc.
>>>
>>> I should note that none of this is necessary to use the "base on top
>>> of a base" trickery I outlined before, it just makes it easier and more
>>> powerful.
>>>
>>> JD
>>>
>> err...well, I'll try hehe; If I understand it correctly, this implies
>> writing code in the GUI.pro file, with as disadvantage that I can't
>> use my .prc file to regenerate GUI?
>> That's some strange behaviour I noticed earlier...if you change
>> position of a widget and save the GUI, all self-written code is simply
>> gone :S
>>
>> If I've created that object, where could I change its structure, like
>> the select and deselect functions?
>> Sorry for the quite explicit way of asking, but hey I'm not as
>> experienced in writing IDL as you guys huh (will one ever be haha), so
>> I'm just trying to learn from it...
>>
>> Thanks though for what you've brought up on ideas so far...
>>
>> Laurens
>>
>> Cheers David :) It's quite funny, I live in the Netherlands and when
>> we use the word "cheers", its when we take a beer haha; so every
>> "cheers" underneath your msgs lets me think you're having quite a good
>> time lol.
Thanks very much! That was more about was I had in mind... since I only
work once a week on this program I happened to have made nothing yet...
I use a class-object to store values like which one is selected. For
what I understand, the
OPLOT, [0,0,1,1,0], [0,1,1,0,0], COLOR=255, THICK=4
line draws a rectangle around the object, but how do you remove it when
its deselected? the "TV, thisData.image" command only draws the actual
image, it seems.
Thanks again, and yeah, of course I'm using david's TVimage function :)
in fact, the original TV function didn't work for me ;)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
