lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Group premium quotes


From: Greg Chicares
Subject: Re: [lmi] Group premium quotes
Date: Fri, 17 Jul 2015 17:22:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

On 2015-07-17 16:16, Vadim Zeitlin wrote:
> On Fri, 17 Jul 2015 02:25:35 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> But let's postpone any further code refinements here because the
> GC> client's Compliance department is challenging this section, which means 
> that
> GC> some of these fields may be moved into a system-generated array (like the
> GC> "Prepared date" and "Prepared by" section you've already coded), while 
> others
> GC> may be expunged, and perhaps this whole boxed "Summary" vanishes.
> 
>  So does this mean that I should wait until this is fully resolved before
> submitting the patches?

Not if you find that inconvenient.

> Or should I remove the box entirely in the initial
> version? Or leave the problematic fields empty?

Any of those is fine...

> I'm ready to do anything
> except leaving the hardcoded values in the code, which is what I currently
> have.

...except that one--because the hardcoded values contain proprietary data.
So do the footnotes, but they can be cleansed similarly.

> GC> >  And, while not quite a field, I'd also like to ask which date format
> GC> > should be used for the three places in which dates occur in the 
> document:
> GC> > 
> GC> > - The report header in the top left (currently hardcoded as "%B %d, 
> %Y").
> GC> 
> GC> I would prefer the OS-specific user default format--is that easy to do?
> 
>  Yes, this is actually the simplest thing to do because this is what
> happens by default with wxDateTime (which I use freely in this code as it
> uses wxDC and other wx classes anyhow). However I was almost certain that
> this wasn't the right thing to do because this report is, presumably, used
> not only on the machine that was used to generate it and it's not clear at
> all why should the final report recipient see the dates in the format
> preferred by the report author.
> 
>  Do we really want to do this?

Yes, especially because it's the simplest thing. AFAICT, everyone in the US
except for me writes dates as "7/8/9" and even understands them unambiguously.
If I think hard about it, I suppose that means July eighth, 2009. Given that
the prevalent convention is the most inscrutable, and that end users probably
haven't changed the msw default date format anyway, I feel confident that no
confusion will ensue.

> GC> Perhaps they'll see the light and not choose the "Comments" treatment.
> 
>  I am still thinking of some way to provide the desired flexibility without
> abusing the "Comments" field for it, but for now I didn't really find
> anything obviously better.

There is nothing better.

> One thought I had was to allow using an extra
> image file instead of putting the text there, which is certainly as
> flexible as it gets, but it would also need to be completely static, i.e.
> not even effective date (which I fill with the current date value) could be
> dynamically generated, which is probably not acceptable.

Well, they could type it into a word processor, use a smart phone to take
a picture of it, mail it to their PC, and paste it in. But the "Comments"
idea still seems preferable to me. Let's just stop looking for a better
way: there is none. And maybe they'll see the light after all and realize
it's better with no user-configurable text at all.




reply via email to

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