[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RE
From: |
Jens Thoms Toerring |
Subject: |
Re: [Fwd: Re: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS));]] |
Date: |
Sun, 16 May 2010 19:25:41 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
Hi Serge,
On Sun, May 16, 2010 at 08:59:03AM -0400, Serge Bromow wrote:
> Yes indeed. Nice to see a parent still looking over his child's development.
;-)
> Jens Thoms Toerring wrote:
> > Hi Dr. Zhao,
> >
> > what a pleasant surprise to see that you're still reading
> > this mailing list!
> >
> > On Sat, May 15, 2010 at 05:33:39PM -0700, address@hidden wrote:
> > > My 2c here is maybe adding a new flag is the best way to resolve
> > > this apparent unreconcilable difference in expectations.
> >
> This sounds fine to me.
> >
> > Yes, that would definitely be a solution. The only drawback
> > I see at the moment is that either those that expect the old
> > behaviour have to change all places in their programs that
> > rely on it or those that already expect on the new behavior.
> > And finding all the places in a lengthy program being affec-
> > ted could be a major task...
> >
> Given I have a vested interest in keeping the old behaviour I would
> be happy to parse my code and change any instance of
> FL_RETURN_END/ALWAYS to what ever you choose. Adding #defines for
> legacy systems that use the 1.0.90 library should keep them in step
> with new application development. A program was written years ago
> for this purpose and I would be happy to share it with others if
> required.
>
> > So after a bit more of thinking about it I would propose
> > to add a new function that allows to switch between the
> > two types of behaviour at any given moment. With that
> > users that depend on the non-default behavour would only
> > have to add a single line to their program, e.g. directly
> > after fl_initialize(), to get what they prefer. That
> > should be rather simple to do.
> Even better. This would require the addition of a single line of
> code in a global routine that already exists in our code.
>
> > The only remaining ques-
> > tion then would be what we make the default behaviour;-)
> >
> Keep the new behaviour as default. In this age of enlightenment we
> should move forward. As I mentioned in earlier posts I may yet find
> a use for this type of return.
Ok, fine with me;-) I'll try to come up with a new test version
with the additional function tonight. At least at a first glance
it doesn't look as if it would be very difficult.
Best regards, Jens
--
\ Jens Thoms Toerring ________ address@hidden
\_______________________________ http://toerring.de