From mint-bounce@lists.fishpool.fi Tue Jul 5 18:31:05 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] usage of wind_calc() From: Evan Langlois To: Arnaud BERCEGEAY Cc: MiNT List In-Reply-To: References: <42BB46F0.4090206@chello.nl> <1119599743.15790.284.camel@linuxbox> <1119718803.15790.339.camel@linuxbox> <1119779027.15790.442.camel@linuxbox> <1120071508.19330.55.camel@linuxbox> <1120086064.11804.57.camel@taro.coolrunningconcepts.com> <20050704223006.kwfxlp92qs8cg4g8@coolrunningconcepts.com> Content-Type: text/plain Date: Tue, 05 Jul 2005 11:28:17 -0500 Message-Id: <1120580898.11436.13.camel@taro.coolrunningconcepts.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - esc14.midphase.com X-AntiAbuse: Original Domain - fishpool.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com X-Source: X-Source-Args: X-Source-Dir: X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Evan@CoolRunningConcepts.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: On Tue, 2005-07-05 at 07:59 +0200, Arnaud BERCEGEAY wrote: > have you ever wrote a GEM application ? Yes, but not in a long time. Sorry. > ok, let's take an example. A text viewer. > > The top left corner of the WORK area is x=50 y=200. > > The first line of text is displayed by using > v_gtext( vdihandle, 50, 220, line[0]); /* 220 = 200 + height of the text > */ Ah yes, direct screen positioning - the origin of the graphics to be drawn are dependant on the window position. I had forgotten about that since I'm more used to other systems. That does indeed require knowing the origin of the work area. You could just remember the window origin when you open it and update it when moved or resized. This would save you from having to get the working area at every redraw (possibly faster) and work around the bug pretty easily. Although I do suppose that this would still require using wind_calc since you dont get the working area during moves and resizes. > With buggy AES, wind_get(WF_WORKXYWH) returns the area from y=150 to 500+, > which include the area where the AES toolbar is drawn (this is the bug). Apparently documented as behaving that way, but I'd agree its a bug. In the case of the bug, I guess the only accurate way to get the working area is to start with the full area and then use wind_calc() and then add the toolbar area. Seems like a good reason for not supporting buggy AESs and adopting the WCOWORK mode as you always have the working area. Either that or movr to a system that uses relative coordinates, but I don't think anyone wants to do that. > If application get the WORK area that way, the first line of text will be > displayed at y=70 (50+20). If the WM_REDRAW message is correct (do not > contain the toolbar area), then the 3 first lines of text will never be > displayed by the application (text hidden by the toolbar). the REDRAW message isn't guaranteed to have anything to do with the window area, only the dirty area of the screen. > > Hope it clearer now... If so, please read again the quote. Yes, thanks.