[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]