xforms-development
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]