| Re: testcase [message #30035] |
Thu, 04 April 2002 05:37 |
btupper
Messages: 55
Registered: January 2002
|
Member |
|
|
On Wed, 3 Apr 2002 20:50:38 -0700, "Pavel Romashkin"
<pavel_romashkin@hotmail.com> wrote:
> "Ben Tupper" <btupper@bigelow.org> wrote
>
>> I just ran through a number of resizes using your program. What you
>> describe does not match the behavior I see on this machine.
>>
>> IDL> print, !version
>> { x86 Win32 Windows Microsoft Windows 5.5 Aug 28 2001 32 64
>
> Ben! Win 32?! What's that, treason? I thought you were a Mac guy.
> Ok, that leaves just myself I guess. I might as well follow Thierry to
> Luxemburg.
> Cheers,
> Pavel
>
> P.S. I ran IDL today on a PC too, but for the sole reason of having no
> serial port on the Mac to connect the prototyping board to. My colleague has
> just tested tis new G4 to run some code in 12 min that his Sun took 1.5 hrs
> to finish, so Macs are not out of the picture.
> Disclaimer: this is NOT an invitation to a processor speed fight.
>
>
Hi Pavel,
No, not treason. We have all the flavors here, but I have Windows at
home... I suppose that voluntarily operating Windows is a spritual
quest, something like wearing a horse-hair shirt.
Ben
|
|
|
|
| Re: testcase [message #30043 is a reply to message #30035] |
Wed, 03 April 2002 19:50  |
Pavel Romashkin
Messages: 166
Registered: April 1999
|
Senior Member |
|
|
"Ben Tupper" <btupper@bigelow.org> wrote
> I just ran through a number of resizes using your program. What you
> describe does not match the behavior I see on this machine.
>
> IDL> print, !version
> { x86 Win32 Windows Microsoft Windows 5.5 Aug 28 2001 32 64
Ben! Win 32?! What's that, treason? I thought you were a Mac guy.
Ok, that leaves just myself I guess. I might as well follow Thierry to
Luxemburg.
Cheers,
Pavel
P.S. I ran IDL today on a PC too, but for the sole reason of having no
serial port on the Mac to connect the prototyping board to. My colleague has
just tested tis new G4 to run some code in 12 min that his Sun took 1.5 hrs
to finish, so Macs are not out of the picture.
Disclaimer: this is NOT an invitation to a processor speed fight.
|
|
|
|
| Re: testcase [message #30044 is a reply to message #30043] |
Wed, 03 April 2002 18:38 |
btupper
Messages: 55
Registered: January 2002
|
Member |
|
|
On Wed, 03 Apr 2002 18:56:24 -0400, Ted Cary <tedcary@yahoo.com>
wrote:
> If your computer is like mine, TLB_SIZE events will
> always generate WIDGET_DRAW expose events, and the X field in the expose
> event structures will not depend on the viewport position at all, but
> will always be equal to the draw widget's screen y size.
>
Hi Ted,
I just ran through a number of resizes using your program. What you
describe does not match the behavior I see on this machine.
IDL> print, !version
{ x86 Win32 Windows Microsoft Windows 5.5 Aug 28 2001 32 64}
Here's an example from the output log.
TLB_SIZE_EVENT!!__________
EXPOSE EVENT!!__________
EVENT.X: 0
VIEWPORT X: 0
SCR_YSIZE: 327.000
I notice that the X and Y fields of any expose event contain 0
regardless of the postion of each slider. The sliders usually snap
back to the left and top when I resize.
Here's output,slightly modified from yours, that prints the entire
event structure. I labeled the X and Y fields (kinda). Note that X
and Y fields are returned as zeroes in the expose event.
VIEWPORT MOTION EVENT!!_____X_______Y
{ 10 9 9 3 470 346
0 0 0 0}
VIEWPORT MOTION EVENT!!_____X_______Y
{ 10 9 9 3 914 346
0 0 0 0}
TLB_SIZE_EVENT!!__________
EXPOSE EVENT!!_______________X_______Y
{ 10 9 9 4 0 0
0 0 0 0}
I changed the GUI so the draw widget didn't have scroll bars. Zero
values are returned in the expose event.X and event.Y fields, too.
The online docs about draw events says, 'The X and Y fields give the
device coordinates at which the event occurred, measured from the
lower left corner of the drawing area. ' I suppose an expose/resize
event does have a position in that sense. It's wierd that the Mac
puts the scr_ysize in the x field... but that doesn't make it any less
useful that what the Windows version is doing.
> Drawing a
> larger image in an object graphics hierarchy to a scrollable window takes a
> long time--noticeably longer than drawing a smaller image.
Could you use direct graphics in this case? The DEVICE, COPY = ... is
some wicked fast, as we say here Down East, event for 1500x1500 pixels
(or a subset thereof.)
Ben
|
|
|
|
| Re: testcase [message #30045 is a reply to message #30044] |
Wed, 03 April 2002 17:35 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"Ted Cary" <tedcary@yahoo.com> wrote :
> Just run the program, resize the window a few times, and watch the
> command line. If your computer is like mine, TLB_SIZE events will
> always generate WIDGET_DRAW expose events, and the X field in the expose
> event structures will not depend on the viewport position at all, but
> will always be equal to the draw widget's screen y size. What am I
> doing wrong?
Nothing, as far as I can tell. Your program seems to work fine on IDL 5.5,
Win2k.
Resizing the draw widget returns the scroll bars to their 0 positions and
event.x returns 0 as it should. Moving the X scroll bar and generating an
expose event other than resize shows that event.x returns reasonable values.
-Rick
|
|
|
|
| Re: testcase [message #30046 is a reply to message #30045] |
Wed, 03 April 2002 17:48 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ted Cary (tedcary@yahoo.com) writes:
> Just run the program, resize the window a few times, and watch the
> command line. If your computer is like mine, TLB_SIZE events will
> always generate WIDGET_DRAW expose events, and the X field in the expose
> event structures will not depend on the viewport position at all, but
> will always be equal to the draw widget's screen y size. What am I
> doing wrong?
Well, on my Windows machine I don't see this behavior at
all. But on the other hand, what I do see makes about
as much sense as what you see. If I run the program in
Windows IDL 5.4, then event.x after the resize/expose
event is always set to 0. But the scroll bars are
obviously not set at zero. In Windows IDL 5.5, event.x
is always set to 0, but the scroll bars have now been
reset to the zero position, so this makes mathematical
sense, even if it would cause a user to tear his hair
out in frustration, since his view changes every time
he touches the damn program!
If you want my opinion, I'd stay as far away
from the APP_SCROLL keyword as possible.
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
