[Top][All Lists]

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

[lmi] An irreproducible anomaly

From: Greg Chicares
Subject: [lmi] An irreproducible anomaly
Date: Tue, 14 Jun 2016 20:04:08 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0

To attempt to reproduce this anomaly:

Open a census with more than one cell, in which "ContractNumber"
varies across cells. Edit "ContractNumber" by drilling down in the
census manager (not by opening the tabbed dialog); copy and paste
something into that field. Leaving the field open for editing
(with its contents highlighted), open the tabbed dialog by some
means such as pulling down the "Census" menu with the mouse and
selecting "Edit cell..." with the mouse. Observe the string
"[diagnostics]" (without double quotes) in the static-text control
whose XRC name is "diagnostics"; that string (with square brackets)
is the default "label" of that XRC element, and seeing it is
anomalous because MvcController::UponUpdateUI() should have cleared
it quickly:
Even if that anomaly is not observed, go to the "Payments" tab,
enter "-1" in "Dumpin", and Tab away from "Dumpin": the expected
effect is that this string appears in the static-text "diagnostics"
    "-1 is too low: 0 is the lower limit."
and focus is trapped in "Dumpin" until you fix that; but if you
don't see that message and can Tab away from "Dumpin", then you
have reproduced the anomaly.

The appearance of "[diagnostics]" has been reported in production,
with a February 2016 build of wx. I saw the "Dumpin" anomaly today
with our current build of wx. Drilling down into "ContractNumber"
was the circumstance of the original end-user report, but I can't
imagine the anomaly would arise only with that field, as there's
nothing special about it: it's an unconstrained string, and the
Input class has nineteen members of the same type. "Dumpin" just
happens to be a field that I know performs range validation, but
there are thirty-nine tnr_nonnegative_double fields in class
Input that should behave the same way.

My hypothesis is that the wxUpdateUIEvent pump has failed. But
I find no call to SetUpdateInterval() or SetMode() in lmi that
could cause UpdateUI events to stop flowing.

reply via email to

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