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
