Yes indeed. Nice to see a parent still looking over his child's
Jens Thoms Toerring wrote:
This sounds fine to me.
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.
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.
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...
Even better. This would require the addition of a single line of code
in a global routine that already exists in our code.
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.
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.
The only remaining ques-
tion then would be what we make the default behaviour;-)
Thanks for all your help Jens and TC,
Best regards, Jens
IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify DineAmix Inc. immediately by email at address@hidden.