| Re: border around draw widget [message #50343] |
Thu, 28 September 2006 10:17  |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
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.
|
|
|
|
| Re: border around draw widget [message #50360 is a reply to message #50343] |
Thu, 28 September 2006 00:21  |
Laurens
Messages: 41
Registered: May 2006
|
Member |
|
|
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.
|
|
|
|
| Re: border around draw widget [message #50362 is a reply to message #50360] |
Wed, 27 September 2006 15:23 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
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
|
|
|
|
|
|
| Re: border around draw widget [message #50364 is a reply to message #50363] |
Wed, 27 September 2006 14:35 |
Laurens
Messages: 41
Registered: May 2006
|
Member |
|
|
JD Smith wrote:
> On Wed, 27 Sep 2006 15:42:43 +0200, Laurens wrote:
>
>> Hi,
>>
>> I have a couple of draw widgets displaying various gamma-scans. Now the
>> user has to select two of them by clicking on them; done.
>> But now I want to let the user know where he clicked, so is it possible
>> to draw some sort of red border of a few pix around the clicked
>> draw-widget? I know they have a frame property, but that's just too thin
>> and doesn't attract attention...
>
> You could make the frame thicker. Something like:
>
> IDL> b=widget_base(/ROW)
> IDL> t=widget_draw(b,xsize=200,ysize=200,FRAME=10)
> IDL> b2=widget_base(b,xsize=200,ysize=200,xpad=10,ypad=10,/COLUMN )
> IDL> t2=widget_draw(b2,xsize=200,ysize=200)
> IDL> widget_control, b,/realize
>
> Unfortunately with this setup, you'll have to kill and re-create
> everything whenever the user selects a new draw widget (since FRAME's
> are only possible when the widget is created). Not ideal. You'll
> probably want to use UPDATE=0/1 to avoid flickering.
>
> Here's a trick that avoids all that killing/recreating. Use a
> bulletin board base (no /ROW or /COLUMN), and then layer two bases
> inside it: one which holds your draw widget, offset by 10 pixels in x an
> y, and one empty base which has FRAME=10 set, whose only purpose in life
> is to display that frame. Simply map and unmap the empty draw base to
> add/remove the frame as necessary. Something like:
>
> IDL> b=widget_base()
> IDL> b1=widget_base(b,xsize=200,ysize=200,xpad=10,ypad=10)
> IDL> t=widget_draw(b1,xsize=200,ysize=200)
> IDL> b2=widget_base(b,xsize=200,ysize=200,FRAME=10)
> IDL> widget_control, b,/realize
> IDL> widget_control, b2,map=0 ; remove frame
> IDL> widget_control, b2,map=1 & widget_control, b1,map=1 ; add frame back
>
> To make it easier, wrap this functionality up in a compound
> "frame-toggle-draw" widget of some sort, and then layout as many of
> these as you need. I might instead make it an object widget for
> additional convenience (so I can pass it an image to draw, tell it to
> erase, etc.), but a regular compound widget would work as well. Then
> something like:
>
> widget_control,frame_toggle_draw_widget_id,SET_VALUE=0 ; turn frame off
>
> could be enough to "de-select" that draw.
>
> JD
>
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...
Laurens
|
|
|
|
| Re: border around draw widget [message #50369 is a reply to message #50364] |
Wed, 27 September 2006 11:06 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Wed, 27 Sep 2006 15:42:43 +0200, Laurens wrote:
> Hi,
>
> I have a couple of draw widgets displaying various gamma-scans. Now the
> user has to select two of them by clicking on them; done.
> But now I want to let the user know where he clicked, so is it possible
> to draw some sort of red border of a few pix around the clicked
> draw-widget? I know they have a frame property, but that's just too thin
> and doesn't attract attention...
You could make the frame thicker. Something like:
IDL> b=widget_base(/ROW)
IDL> t=widget_draw(b,xsize=200,ysize=200,FRAME=10)
IDL> b2=widget_base(b,xsize=200,ysize=200,xpad=10,ypad=10,/COLUMN )
IDL> t2=widget_draw(b2,xsize=200,ysize=200)
IDL> widget_control, b,/realize
Unfortunately with this setup, you'll have to kill and re-create
everything whenever the user selects a new draw widget (since FRAME's
are only possible when the widget is created). Not ideal. You'll
probably want to use UPDATE=0/1 to avoid flickering.
Here's a trick that avoids all that killing/recreating. Use a
bulletin board base (no /ROW or /COLUMN), and then layer two bases
inside it: one which holds your draw widget, offset by 10 pixels in x an
y, and one empty base which has FRAME=10 set, whose only purpose in life
is to display that frame. Simply map and unmap the empty draw base to
add/remove the frame as necessary. Something like:
IDL> b=widget_base()
IDL> b1=widget_base(b,xsize=200,ysize=200,xpad=10,ypad=10)
IDL> t=widget_draw(b1,xsize=200,ysize=200)
IDL> b2=widget_base(b,xsize=200,ysize=200,FRAME=10)
IDL> widget_control, b,/realize
IDL> widget_control, b2,map=0 ; remove frame
IDL> widget_control, b2,map=1 & widget_control, b1,map=1 ; add frame back
To make it easier, wrap this functionality up in a compound
"frame-toggle-draw" widget of some sort, and then layout as many of
these as you need. I might instead make it an object widget for
additional convenience (so I can pass it an image to draw, tell it to
erase, etc.), but a regular compound widget would work as well. Then
something like:
widget_control,frame_toggle_draw_widget_id,SET_VALUE=0 ; turn frame off
could be enough to "de-select" that draw.
JD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: border around draw widget [message #50535 is a reply to message #50343] |
Wed, 04 October 2006 02:18 |
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.
Never mind, it already works :) Thnx a bunch!
|
|
|
|
| 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 ;)
|
|
|
|
| Re: border around draw widget [message #50582 is a reply to message #50343] |
Mon, 09 October 2006 12:38 |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Thu, 28 Sep 2006 10:17:24 -0700, 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.
Yes, trivial, unless you need all pixels for drawing. Yes, you could just
draw over the top of the image, assuming the loss of a few pixels around
the edge is irrelevant. Otherwise, the base-on-base trick might be worth
it, to keep your drawing code simple (...I have a canvas which is 248x248
pixels if selected, or 256x256 otherwise...).
JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
