Date: Sun, 18 Jan 2004 00:04:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 290 ************************************************** Saturday 17 January 2004 Number 290 ************************************************** Subjects for today 1 Y conversion routines : Dave Webster 2 Re: Y conversion routines : Illya Vaes 3 RE: Y conversion routines : Dave Webster **= Email 1 ==========================** Date: Fri, 16 Jan 2004 08:12:27 -0600 From: Dave Webster Subject: Y conversion routines After much digging I found these two UNDOCUMENTED Gpi calls that convert HPS Y axis to a WIN32 Y axis (namely where 0,0 is the TOP left, not the bottom left). BOOL APIENTRY GpiEnableYInversion (HPS hps, LONG lHeight); LONG GpiQueryYInversion(ULONG hps); Parameters should be obvious. You only have to do it once for each HPS. How to import it: IMPORTS GpiEnableYInversion = PMGPI.723 GpiQueryYInversion = PMGPI.726 Wondering if anyone has ever heard of these and if there are corresponding Win calls. These could be key to fixing the excessive repaint needs (all done to map wxWindows screen coords to OS/2 PM coords) in wxOS2. **= Email 2 ==========================** Date: Fri, 16 Jan 2004 21:20:34 From: Illya Vaes Subject: Re: Y conversion routines ** Reply to note from Dave Webster Fri, 16 Jan 2004 08:12:27 -0600 >After much digging I found these two UNDOCUMENTED Gpi calls that convert HPS >Y axis to a WIN32 Y axis (namely where 0,0 is the TOP left, not the bottom >left). How did you find those??? Do you have any indication on which versions of OS/2 this is supported? If I had to wager, I'd say from the version including OPEN32 (the Win32 API support intended for SmartSuite). >BOOL APIENTRY GpiEnableYInversion (HPS hps, LONG lHeight); >LONG GpiQueryYInversion(ULONG hps); > >Parameters should be obvious. Well, the lHeight isn't _entirely_ obvious to me. Doesn't the GPI itself know the value for that? Can I just give any value there? Shouldn't the hps for the query be HPS instead of ULONG (which boils down to the same thing, but is more consistent)? Isn't there a GpiDisableYInversion? Is one supposed to "enable" it twice to get rid of it again (assuming anyone would want to)? >You only have to do it once for each HPS. OK. >How to import it: >IMPORTS > GpiEnableYInversion = PMGPI.723 > GpiQueryYInversion = PMGPI.726 Thanks. >Wondering if anyone has ever heard of these and if there are corresponding >Win calls. Nope. They are very welcome though (at least, if it's widely supported), since I have to translate the Y coordinate all the time in my OS/2 port of Tcl/Tk (www.vaeshiep.demon.nl). It's not just Windows that has Y=0 at bottom left, but the X Window System (and AFAIK the Mac) too, so I get that dialect all the time ;-\ >These could be key to fixing the excessive repaint needs (all >done to map wxWindows screen coords to OS/2 PM coords) in wxOS2. I'm not sure I understand why you need _repaints_. I do _translations_ all the time, from X Window System Y's given to me in OS/2 PM Y's for feeding to the OS/2 PM API and from OS/2 PM Y's to X Window System Y's when notifying the generic part of Tcl/Tk of messages and such. It _is_ pretty error-prone though (especially the border conditions), so I think there's an error or two still in... -- Illya Vaes (illya at vaeshiep.demon.nl) "Do...or do not, there is no 'try'" - Yoda **= Email 3 ==========================** Date: Fri, 16 Jan 2004 15:03:13 -0600 From: Dave Webster Subject: RE: Y conversion routines -----Original Message----- From: Illya Vaes [mailto:illya at vaeshiep.demon.nl] Sent: Friday, January 16, 2004 3:21 PM To: os2-unix at mail.warpix.org Subject: Re: Y conversion routines ** Reply to note from Dave Webster Fri, 16 Jan 2004 08:12:27 -0600 >After much digging I found these two UNDOCUMENTED Gpi calls that convert HPS >Y axis to a WIN32 Y axis (namely where 0,0 is the TOP left, not the bottom >left). How did you find those??? From an exIBM er via an e-mail archive from 2000. Do you have any indication on which versions of OS/2 this is supported? If I had to wager, I'd say from the version including OPEN32 (the Win32 API support intended for SmartSuite). Warp 4 or later (Toolkit v4.5 or later) >BOOL APIENTRY GpiEnableYInversion (HPS hps, LONG lHeight); >LONG GpiQueryYInversion(ULONG hps); > >Parameters should be obvious. Well, the lHeight isn't _entirely_ obvious to me. Doesn't the GPI itself know the value for that? Can I just give any value there? Shouldn't the hps for the query be HPS instead of ULONG (which boils down to the same thing, but is more consistent)? Not sure. I have not used this code yet. Isn't there a GpiDisableYInversion? Is one supposed to "enable" it twice to get rid of it again (assuming anyone would want to)? Don't know, these things are undocumented so grep the gpi headers and find out. >You only have to do it once for each HPS. OK. >How to import it: >IMPORTS > GpiEnableYInversion = PMGPI.723 > GpiQueryYInversion = PMGPI.726 Thanks. >Wondering if anyone has ever heard of these and if there are corresponding >Win calls. Nope. They are very welcome though (at least, if it's widely supported), since I have to translate the Y coordinate all the time in my OS/2 port of Tcl/Tk (www.vaeshiep.demon.nl). It's not just Windows that has Y=0 at bottom left, but the X Window System (and AFAIK the Mac) too, so I get that dialect all the time ;-\ >These could be key to fixing the excessive repaint needs (all >done to map wxWindows screen coords to OS/2 PM coords) in wxOS2. I'm not sure I understand why you need _repaints_. I do _translations_ all the time, from X Window System Y's given to me in OS/2 PM Y's for feeding to the OS/2 PM API and from OS/2 PM Y's to X Window System Y's when notifying the generic part of Tcl/Tk of messages and such. It _is_ pretty error-prone though (especially the border conditions), so I think there's an error or two still in... The problem is in resizing and in wxWindows sizers code which required a lot dynamic resizing until the final layout is renders, and scrolling. The conversion you need is always something like # define OS2Y(y, objy)( m_vRclPaint.yTop - m_vRclPaint.yBottom) - (y + objy) Where y is y coord you desire and objy is the height of the object and m_vRclPaint is the HPS rectangle. It gets to be a real problem on complex controls like radioboxes where you have a client window that contains a radiobox which, in turn, contains radiobuttons. You have to calculate the proper positions of each layer, the radio buttons inside the radiobox, the radiobox on the frame client window, etc... every time the thing scrolls or is resized. Much of the OS/2 code in wxWindows is a total kludge anyway, so no matter what, the resizing code needs revamping regardless of the coordinate system. In fact all of wxWindows across all ports has repaint problems. -- Illya Vaes (illya at vaeshiep.demon.nl) "Do...or do not, there is no 'try'" - Yoda