[Top][All Lists]

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

Re: [lmi] product editor feedback

From: Greg Chicares
Subject: Re: [lmi] product editor feedback
Date: Fri, 30 Mar 2007 12:03:52 +0000
User-agent: Thunderbird (Windows/20060516)

On 2007-3-29 20:49 UTC, Boutin, Wendy wrote:
> Evgeniy Tarassov wrote:
>> On 3/2/07, Wendy Boutin <address@hidden> wrote:
>>>  - checkboxes *look* enabled when top level node is selected
>> This is a bug in WX. As soon as the corresponding path makes it into
>> wx HEAD it will be available.
> Upgrading wx may be out of our immediate scope right now because of
> other work that still remains. There's a suggestion below that may
> help solve this particular problem. I'm not ruling out a wx upgrade,
> but if we can avoid adding that right now, than that's better for us.

I imagine there's some trivial way to make the checkboxes and
grid invisible when and only when a non-leaf node is selected.

>>>  - insufficient space for UWBasis values as column or row headers
>> A patch was committed into WX so this should not be a problem with the
>> latest WX.

Wendy--IIRC, the legacy system had this same non-ideal behavior;
if so, I'm guessing that this alone wouldn't be sufficient cause
to hold up the end-of-April release or to upgrade wx before then.

>> The axis selection is a
>> property of the current view (presenting the data), not the data
>> itself. It could be added into the file, but it will mix the data with
>> its visual representation, personally, i don't think it is right. Do
>> you think it should be done nevertheless? 
> We agree: it's not right to add this to the file.
>> Currently when a user opens
>> a "session" (opening a window in the program, which shows the data)
>> the selection will persist, but as soon as the "session" is over (the
>> window is closed), the selection is gone.
> Then is it the case that there's no way to save the selections?

To what file would you save them? We all agree that it should not
be the file we're editing, so it'd have to be an auxiliary file.
Consider whether that file would be different for each user, and
whether it would persist between releases. Also consider whether
a user's axis selections for product A would be appropriate for
product B, for which a particular item might not vary across the
same axes.

> I don't
> like that I can change my axes, save the file, reopen it and see the axes 
> rearranged in the order that they're listed in the GUI. 

Is that behavior, though, a necessary consequence of not saving
the axis selections in any file?

Wouldn't the alternative behavior you'd prefer constitute an
enhancement as compared to the legacy system? If so, is it a
requirement for the April release? April is upon us, and this
does not seem to be a small task.

>>>  - all top level nodes should have values of zero
>>>     e.g., loading a proprietary product displayed 'PremTaxTable' value
>>> in 'Tables' grid

BTW, that may relate to the segfault problem we discussed
earlier this month. It sounds like a stray pointer.

>> I think one of the changes done to the code should have fixed this
>> issue already. I can't reproduce this behavior, but if it ever
>> occurred before it should be now impossible (due to the code changes
>> made).
> I am using cvs HEAD code as of today and can still observe my original
> problem with a proprietary product. It would be better not to show 
> anything except the legend for non-leaf nodes.

I like that suggestion. And, as you note...

> That might also obviate 
> the issue (above) of axis-checkbox enablement. (Maybe that's part of the 
> reason why ihs works this way.)

...it might be the best answer to some other problems.

>>>  - can DBL_MAX be formatted as, say, "MAXIMUM"?
>> Yes. It should be easy to implement. What do you think should be
>> accepted from the user as the keyword? Does it has to be "MAXIMUM"
>> only? Case (in)sensitive? Should it accept an abbreviation like "MAX"?
> I think Greg has better insight with this one, so I'll defer your
> questions to him.

Recently we discussed the idea of making the bottom cell in the
"Limit" column unmodifiable. Perhaps we can change its contents
at the same time, and make it always contain some invariant text.

As to what that text should be--I'm thinking "Any excess" without
the quotes. Probably that's insurance jargon, but our users would
understand it. Thus, South Dakota premium tax [SD 10-4-22(2)]:

       Limit       Value
      100000      0.025
  Any excess      0.0008

Would any other text be more comprehensible to our users?

>>> Assertion '(.999 * DBL_MAX) < limits_.back()' failed.
>>> [file c:/opt/lmi/src/lmi/stratified_charges.cpp, line 139]
>> Fixed. The cause is the same as for the database part - top level
>> nodes can not be manipulated.
> I can still reproduce it with cvs HEAD. Is it possible your fixes
> are in separate patches that Greg's reviewing

Yes. We mustn't assume that they'll all be applied before the
April release. Therefore...

> or maybe a different
> branch that I should be using?

...you should use HEAD. We aren't going to release any patch
that hasn't been applied to HEAD.

reply via email to

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