[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
Jens Thoms Toerring
Re: [Fwd: Re: address@hidden: Re: [XForms] fl_set_input_return(ob, FL_RETURN_ALWAYS));]]
Sun, 16 May 2010 19:25:41 +0200
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
> > 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