From fnaumann@mail.cs.uni-magdeburg.de Wed Apr 28 00:04:14 2004 Date: Tue, 27 Apr 2004 23:57:36 +0200 To: MiNT Mailing List Subject: Re: [MiNT] AES editable field extension proposal Cc: windom@ml.free.fr References: <1082957640.12302.4.camel@pikachu.atari-source.com> <20040427131355.M72044@antyk.obta.uw.edu.pl> From: Arnaud BERCEGEAY Content-Type: text/plain; format=flowed; charset=iso-8859-15 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera7.23/Linux M2 build 518 Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: arnaud.bercegeay@free.fr Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by prinz.cs.uni-magdeburg.de id i3RM4BO05808 Hello, It seems that i wasn't clear. IMO, the password stuff is something AES related, and the AES should provide a way to type password in editable field. It's the AES aim to provide such feature. About windom: yes this feature will be included in windom. If the application (compiled against windom) has the password feature, then windom will let the AES manage this. In other case (old AES), the editable field will be replaced by a userdef etc... by windom. Another point: from the application side, it's not "just" a userdef... it's much more ! First, the application has to replace the FTEXT object by a userdef object, and this userdef object shall be an editable object, but the AES is not able to manage editable userdefined object, so the application has to have its own objc_edit() function too... and as consequence, the form_do() function from the AES could not be used: the application has to manage by hand the whole formular. It's far from "just a userdef". Implementation of this feature in the AES is the good way because (IMO) modern AES should has natively that kind of feature, and furthermore, i don't think it's so hard to implement this is the draw subroutine of FTEXT objects. I think FTEXT drawing function doesn't use pe_tvalid (it should only be usefull for validating characters in objc_edit), so maybe a flag or an extended ob_type is a better design ? To simplify, we can only check the 1st character of pe_tvalid (other characters are not relevant if the 1st character is "*"). My aim is to find a "not so bad" design for this feature. Then windom will adopt this design, and i hope some AES will do too... and because it's not a windom-only feature, i'd like to hear opinions from AES authors. Best regards, Arnaud.