Not agree here, a "compability flag" is as I see it a good choice.
If you have a program that uses compabilitymode=1 (default) will run OK, as
long as you don't want to use "new" stuff, that is at compabilitymode=2 level
(.singleSelection sample, just change mode to 2 in new program , old program
still work as before unchanged (default mode = 1)
other times if one want to utilize new "stuff" in old programs, because of
changed/added functionallity to classes/routines/whatever, change old program
to current mode level and change the old program to conform to that mode, if
needed.
New program choose on which mode it should be able to run 1....n. (probably
always the latest)
Benefits
Old program will work asis at each compabilitymode level
When changing old/new program change code to conform to latest mode at time.
New programs will probably utilize lastest mode level, and when getting old
they still run.on that level.
/hex
----- Ursprungligt Meddelande -----
Från: Staffan Tylen <staffan.ty...@gmail.com>
Till: Open Object Rexx Users <oorexx-users@lists.sourceforge.net>
Kopia:
Datum: onsdag, 05 december 2012 20:36
Ämne: Re: [Oorexx-users] Any comments on RFE: #502 SingleSelection class
Here are my 2p: I think that creating new classes, flags, you name it, to cope
with compatibility issues should be avoided as much as possible. What might be
'new' today will be 'old' in a few years time and a new invention will then be
required to cope with version 2 of 'new'. As for the SingleSelection class I
have no real opinion at the moment as I'm still trying to understand what this
is all about, but when it comes to changing things like zero or one-based
treeviews and listviews I'm in favour of either adding a new parameter, or
adding another style option. Or how about combining the two with a new
'options' parameter in the create... methods, where 0BASE and 1BASE could be
the first supported options. This can then be extended without limit in the
future with no need for any further 'additional' parameter. I just spent my
2p...
Staffan
On Wed, Dec 5, 2012 at 8:13 PM, Rick McGuire <object.r...@gmail.com> wrote:
I can't say I'm particularly fond of adding a new class just to implement this
feature, particularly since the user could just specify the length using a call
to the max() bif. I'm not particularly fond of run-away argument lists
either. Perhaps you could just make the length an optional argument. If not
specified, then the length of the title string is used as the length.
Rick
On Wed, Dec 5, 2012 at 1:48 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
Hi,
/hex opened up a RFE: #502 SingleSelection class which I'm implementing and I
wonder if anyone else would like to contribute to the discussion?
So far it goes like this:
RFE:
This is on windows 8 and oodialog 4.2.1
Using SingleSelection class, the width of the displayed window is based on the
message length parameter, I suppose.
Preferable, the width of displayed window should be based on the greatest of
the message and title parameter length and if specifying the length parameter
the window should display a window with suitable width that shows all
selections and the full message/title parameter length.
Maybe also center the message text in displayed window.
Mark:
While I think the stated preferences are good, especially making the dialog
wide enough to completely display the title, I'm worried that the changes can
effect existing programs too much. Enough that some people may be unhappy with
the changes to their existing programs.
Because of this, rather than change the .SingleSelection class, I'm thinking of
adding an extended .SingleSelection class that has the enhancements and leaving
the .SingleSelection class as is. The new class would be .SingleSelectionEx.
Thoughts?
/hex
Hm..One more class to keep track of.
How about a global parameter like "compabilityMode" .true for old
behaviour/style and .false for "new" behaviour/style. Can be used for other
"new" stuff also.
Or in the case of SingleSelection one more optional parameter at the end,
meaning "fit window to text"
But SingleSelectionEx is also OK
Mark:
Regarding the "compatibility mode" that is similar to a RFE I opened: #441
Enhance ooDialog ApplicationManager to set one-based indexes
The idea being that you could set 'something' through the .application manager
to use one-based indexes in the ListView, which now uses zero-based indexes. By
default the 'something' is off.
The compatibility mode would have to be fine-grained though. You might want
SingleSelectionEx on, but not one-based indexes for ListViews.
So, for this case, it seems it might make it hard to remember what to do to get
SingleSelectionEx.
I have the same general feeling about adding another argument. If there are
only 2 arguments, adding a third makes sense sometimes. But, in this case there
are already 6 arguments and it is hard to remember what the order of the last 3
arguments is.
Adding a 7th makes it harder still.
Maybe we should open up this discussion on the User's list and see what others
might think.
I have SingleSelectionEx implemented and tested. I'll commit it this evening
and you can try it out. I hate to start the doc until I see which way to go on
this ... but changing the implementation to accept a 7th argument instead of
using a new class is easy enough to change.
--
Mark Miesfeld
I'm leaning towards adding the .SingleSelectionEx class whose behavior is as
the RFE requested. I'm interested in what others think about adding an extra
argument to the .SingleSelection class instead? (Or a compatiblity flag added
to the .ApplicationManger?)
--
Mark Miesfeld
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
