Re: [lmi] Allow switching skin while lmi is running

[Greg Chicares]

On 2016-05-31 20:15, Vadim Zeitlin wrote:
> On Mon, 30 May 2016 20:14:42 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Dynamic skin selection was the hard part; adding other members of
> GC> class configurable_settings would be easy, and this is probably
> GC> the best time to add any that we want. Here's a list of that
> GC> class's members, along with some layout ideas.
> GC> 
> GC> ----configurable_settings member---  --tab--    ----control type---
> GC> calculation_summary_columns_         view       array of comboboxes
> GC> use_builtin_calculation_summary_     view       checkbox
> GC> default_input_filename_              input      textctrl
> GC> skin_filename_                       input      listbox or combobox
> GC> print_directory_                     reports    textctrl
> GC> seconds_to_pause_between_printouts_  reports    spinctrl
> GC> spreadsheet_file_extension_          reports    textctrl
[...]
>  I don't have anything to add to this list, I just wanted to say that it
> would be better to choose wxFilePickerCtrl and wxDirPickerCtrl for
> default_input_filename_ and print_directory_ respectively, instead of plain
> wxTextCtrl.

Sounds like a good idea. Since I'm not familiar with those controls,
could I prevail upon you to add them to lmi's 'transferor.?pp'? (I'm
pretty sure we want wxFLP_FILE_MUST_EXIST, but I'm not sure exactly how,
say, GetPath() and GetFileName() differ.)

Could I also ask you to opine on the "TODO ??" markers in transferor.cpp',
because it gladdens my heart to resolve those? This one may be easy for you:

// TODO ?? Use TransferString() with class wxControlWithItems instead
// of its derived classes, now that wx has been changed to implement
// wxControlWithItems::SetSelection(). But consider whether class
// wxItemContainerImmutable can be used for all those classes and
// wxRadioBox as well.

Perhaps we should just remove this comment:

    // TODO ?? Explain why this uses "Yes" and "No" instead of
    // true and false, or change it to support bool, e.g.
    //   control.SetValue(numeric_io_cast<bool>(data));
    //   data = numeric_io_cast<std::string>(control.GetValue());

which seems to propose changing
  <RetireesCanEnroll>No</RetireesCanEnroll>
to
  <RetireesCanEnroll>0</RetireesCanEnroll>.
That would be a costly, sweeping change with no benefit.

Then there are five instances of this:

// TODO ?? Show the offending control's name (unavailable for now).

which complain if, e.g., a listbox doesn't have single-selection style.
These are deliberate design limitations that we always respect, so
no end user ever sees these messages. Correct me if I'm wrong, but I
think the control's name is unavailable here because of encapsulation,
and it wouldn't make sense to make it available...so these comments
should just be removed (and perhaps replaced with one global comment
explaining why the names are unavailable).

> GC> I also looked at the "pyx"
> GC> and "idiosyncrasy" options and concluded that most of them are
> GC> hidden for good reasons:
> GC>   idiosyncrasyT is useful only for debugging
> GC>   idiosyncrasyV is pretty much obsolete
> GC>   idiosyncrasy_daily_interest_accounting would ideally be
> GC>     a member of class Input, just like the general-account rate
> GC>   idiosyncrasyZ and pyx=values_tsv would ideally be menu commands
> 
>  Should I look into doing this or was this just an abstract remark and not
> a call for action?

Let's defer all of these until the next decade.

> GC> This would be a good time to suggest anything else that we might
> GC> want to show on this dialog.
> 
>  As I already said, I can't think of anything, but I can add the 4 fields
> you think it would be useful to have there if you'd like.

I'll do that--I want to make some formatting changes anyway. The only
thing I need help with is 'transferor.cpp'.