[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Difficulty editing particular fields in census manager
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] Difficulty editing particular fields in census manager |
Date: |
Thu, 30 Aug 2018 02:39:27 +0200 |
On Thu, 30 Aug 2018 00:30:22 +0000 Greg Chicares <address@hidden> wrote:
GC> Perhaps something like wxGenericValidator would be okay here, because
GC> lmi's MVC classes should meet all our validation needs.
wxFloatingPointValidator is supposed to provide a better user-experience
than wxGenericValidator, even if it doesn't quite live up to it right
now. Of course, if we needed an urgent fix, it could indeed be used ...
GC> > If a fix is needed urgently
GC>
GC> Well, it took us many years to notice this, so it would be a stretch
GC> to call it urgent.
... but considering this, I hope it can wait until the next month release
which will hopefully incorporate an updated wxWidgets version with the fix
for http://trac.wxwidgets.org/ticket/12968
GC> > perhaps the least bad solution would be to
GC> > set the lower end of the valid range to 0 when it's strictly positive.
This
GC> > wouldn't actually be a big problem for lmi, as invalid values still
GC> > wouldn't be accepted, albeit still without any error message, because of a
GC> > later call to Reconcile() and while doing it at wxFloatingPointValidator
GC> > level remains the best solution, perhaps you could use this patch
GC> >
GC> > ---------------------------------- >8
--------------------------------------
GC> > diff --git a/census_view.cpp b/census_view.cpp
GC> [...]
GC> > - val.SetRange(data.min, data.max);
GC> > + val.SetRange(std::min(data.min, 0), data.max);
GC>
GC> [BTW, you meant "0.0"--instead of "0", which tries to call
GC> std::min<double,int>().]
Oops, yes, absolutely. Sorry.
GC> > for now?
GC>
GC> That looked like a great idea, but in a few seconds of playing with it,
GC> I had several screenfuls of this repeating diagnostic:
GC>
GC> 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
GC> Retrieving the value from the model threw an exception
GC>
GC> and a deep stack of messageboxes, one of which warned of failure here:
GC>
GC> bool RangeTypeRenderer::SetValue(wxVariant const& value)
GC> {
GC> tn_range_variant_data const* data =
dynamic_cast<tn_range_variant_data*>(value.GetData());
GC> LMI_ASSERT(data);
GC> ^^^^^^^^^^^^^^^^^
GC>
GC> while the other showed nothing but a single, lonely hyphen; leaning on
GC> Esc didn't close them all, so I killed the process. I'd rather not
GC> repeat that experience, so I don't give detailed instructions to
GC> reproduce it, but I suspect you'd have no trouble provoking the same
GC> kind of meltdown.
Actually I do, but it's because I'm using MSVC for testing right now. But
I do indeed see the assert when pressing minus in the editor. I think it
could actually be a separate bug, but I prefer to really fix the first one
before dealing with it just in case this one disappears too then.
Regards,
VZ