lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Difficulty editing particular fields in census manager


From: Greg Chicares
Subject: Re: [lmi] Difficulty editing particular fields in census manager
Date: Thu, 30 Aug 2018 00:30:22 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 2018-08-29 23:10, Vadim Zeitlin wrote:
[...]
>  Unfortunately I don't think it's possible to fix it without stopping to
> use wxFloatingPointValidator completely, which would be undesirable. I can
> fix it inside this class itself, but I'm not yet sure how exactly to do it,
> so I can't say how long will it take.

I was puzzled at first because I felt sure that I never actually used
any wx class derived from the wxValidator class, but only derived
from that base class myself. And that's true for 'transferor.?pp'...
but the census manager does indeed use wxFloatingPointValidator.

Perhaps something like wxGenericValidator would be okay here, because
lmi's MVC classes should meet all our validation needs.

>  If a fix is needed urgently

Well, it took us many years to notice this, so it would be a stretch
to call it urgent.

> perhaps the least bad solution would be to
> set the lower end of the valid range to 0 when it's strictly positive. This
> wouldn't actually be a big problem for lmi, as invalid values still
> wouldn't be accepted, albeit still without any error message, because of a
> later call to Reconcile() and while doing it at wxFloatingPointValidator
> level remains the best solution, perhaps you could use this patch
> 
> ---------------------------------- >8 --------------------------------------
> diff --git a/census_view.cpp b/census_view.cpp
[...]
> -    val.SetRange(data.min, data.max);
> +    val.SetRange(std::min(data.min, 0), data.max);

[BTW, you meant "0.0"--instead of "0", which tries to call
std::min<double,int>().]

> for now?

That looked like a great idea, but in a few seconds of playing with it,
I had several screenfuls of this repeating diagnostic:

Wrong type returned from the model for column 110: 
N12_GLOBAL__N_121tn_range_variant_ required but actual type is 
N12_GLOBAL__N_121tn_range_variant_dataE
Retrieving the value from the model threw an exception

and a deep stack of messageboxes, one of which warned of failure here:

bool RangeTypeRenderer::SetValue(wxVariant const& value)
{
    tn_range_variant_data const* data = 
dynamic_cast<tn_range_variant_data*>(value.GetData());
    LMI_ASSERT(data);
    ^^^^^^^^^^^^^^^^^

while the other showed nothing but a single, lonely hyphen; leaning on
Esc didn't close them all, so I killed the process. I'd rather not
repeat that experience, so I don't give detailed instructions to
reproduce it, but I suspect you'd have no trouble provoking the same
kind of meltdown.

I think we should forswear workarounds and wait for:
  http://trac.wxwidgets.org/ticket/12968



reply via email to

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