From mint-bounce@lists.fishpool.fi Thu Sep 6 10:22:35 2007 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <46DFBA76.5000407@utbm.fr> Date: Thu, 06 Sep 2007 10:29:42 +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> <46DFA394.90303@utbm.fr> In-Reply-To: <46DFA394.90303@utbm.fr> 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: Olivier Landemarre wrote: > 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 > > Oups perhaps it is in fact usefull if you wan't manage edition field in html page or something like this? Olivier