From mint-bounce@lists.fishpool.fi Thu Sep 6 09:52:15 2007 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <46DFA394.90303@utbm.fr> Date: Thu, 06 Sep 2007 08:52:04 +0200 From: Olivier Landemarre X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] form_button in XaAES References: <48722117.51061189015097128.JavaMail.adm-moff@moffice11.nsc.no> In-Reply-To: <48722117.51061189015097128.JavaMail.adm-moff@moffice11.nsc.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: olivier.landemarre@utbm.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: 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=BAYES_00 X-Spam-Level: Jo Even Skarstein wrote: > According to newcalls.txt it's strongly recommended to use form_button > and form_keybd in non-modal dialogs to allow XaAES' keyboard > navigation to work. However, as neither of these functions (together > with objc_edit) doesn't have a window context, they all ignore the > rectangle list. The result is that other windows get dirtied unless > the processed object is on top. > > This is normally not an issue, as most windows doesn't process > keyboard and mouse events unless they're on top. There are currently > two situations where they do: > > 1. The dialog window has the WF_BEVENT attribute set. It's possible to > process mouse button events even if the window is not on top. > 2. Another window has the "always on top" flag set (XaAES). > > I'm working on a project where (1) is getting a bit of a problem. I've > tried some other applications (qed, artworx, smurf and toswin2) and > they all behave similar to my app, so I assume that there's not a > solution for this problem yet. > > My suggestion is to add tree new functions in XaAES, xform_button, > xform_keybd and xobjc_edit. These have the same functionality, but are > extended with an additional argument - window handle. They will then > be able to observe the window rectangle list when redrawing, and it > will be possible to create non modal dialogs the proper way. > > I haven't looked at the sources though, so I don't know if this is > possible. If not, perhaps these functions could be identical to the > old functions but not do any redraws. Then the application can do this > itself using obcj_draw. > > Jo Even > > Hello Really I think some software are a little bit complicated, in my opinion this functions where sub-function of the very old form_do(), with theym a lot of developpers have done dialog box in window, this was interesting, but now really I think it's obsolete because there is a very simple way to do this, without programming anything: wind_create() wind_set(WF_TOOLBAR,...) wind_open() And thats all, only manage messages, no redraw to manage, non-modal window etc... This is quite cool and so easy. Olivier