[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Direct drill-down census editor testing
From: |
Greg Chicares |
Subject: |
Re: [lmi] Direct drill-down census editor testing |
Date: |
Thu, 05 Jan 2012 03:10:01 +0000 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
On 2011-12-18 10:16Z, Václav Slavík wrote:
>
> On 14 Dec 2011, at 10:08, Greg Chicares wrote:
>> I think the ultimate solution is a distinct MvcController-like class for
>> the census editor.
>
> It would be better to share the code, but I don't see any easy way of doing
> that :(
>
> In addition to ConditionallyEnableItems(), we'll also need the equivalent of
> ConditionallyEnableControl(), I think, for disabling editing of columns that
> shouldn't be editable.
>
> Are there any other parts of MvcController in need of bringing over to
> CensusView?
In order to achieve parallel behavior, we'll need parallel code;
that's why I think the best solution is an MVC Controller class
designed to work with wxDVC, similar to the one that now works
with tabbed dialogs. I guess the wxDVC case might have a simpler
implementation because you completely control wxDVC. Thus, the
code to handle focus changes (NameOfControlToDeferEvaluating(),
EnsureOptimalFocus(), RefocusLastFocusedWindow(), etc.) is quite
intricate because the OS handles focus within a dialog, and not
always in the most convenient way. With wxDVC, that problem
probably doesn't exist. The objective is still the same--in
this case, to lock the user in a field in which an out-of-range
value has just been entered--but a wxDVC implementation wouldn't
have the OS-focus-handling obstacle to overcome.
So I guess the answer to your question is: all of it, except the
parts that are needed just to work around tabbed-dialog problems;
but those are the most labyrinthine parts, whose objectives may
be simpler to achieve with wxDVC.
- Re: [lmi] Direct drill-down census editor testing,
Greg Chicares <=