[lmi] product editor prototype and questions about .pol, .rnd, .tir and .ill+.cns file types

[Evgeniy Tarassov]

Hello Greg!
A couple of days ago i have commited a prototype for product editor
into MDGRID branch. I still have a couple of questions, and if you
could comment on it would be great.

Do you think that pedit_* pattern for the file names is appropriate?

.pol files
I was not able to find a match to the 'Term rider' field. There are
two variables in the TProductData class (ihs_proddata.hpp) that have
the same value in the sample.pol file and similar names
TProductData::CurrTermFilename and TProductData::GuarTermFilename.
Which one should be shown to the user? Maybe both?
Also there is total of 38 fields in that class (TProductData) and only
15 are shown in the GUI (ihs.exe), is there any hidden logic that was
not (yet) implemented or should be taken into account while editing
this types of files?

.rnd files
In the old ihs.exe the window corresponding to rnd files contains two
columns with editors for entities. The left column contains 12
elements, while the right one contins only 2 -- is there anything
special about it, or its just a visual sugar? Or maybe the list could
be extended and the space left in the right column is reserved for new
rounding values?

.tir files
There were one missing thing -- a resize member in the
stratified_entity class (stratified_charges.hpp) to change the number
of bands. I've implemented it outside of the class by repeating what
ihs.exe is doing:
resize( n ):
{
if current_n = 0
  add one band (limit:MAX_DBL, value:1)
last band always stays the last one
if n > current_n
    if current_n = 1
        fill new bands with (limit:0, value:0)
    else (current_n >= 2)
        fill new bands with the one before the last band
if n < current_n
    repeatedly destroy one before the last band until n == current_n
}
It is the same that ihs.exe does.
Do you think it should be moved into the stratified_entity class?
Currently that class behaves more like a struct -- there is no limit
checking, only at the write-to-disk time. Do you think it could be
appropriate to add some sort of operator[] to the class to allow
editing of the class data while preserving its internal invariants
(like limits array having strictly growing values, having
limits.back() always equal to DBL_MAX, etc)?
The fact that the last limit is always DBL_MAX forces user not to
change the limit of the last band or to memorise that DBML_MAX. Do you
think we should try to "gray out" that limit part of the last band so
that (at least) it stays read-only? As far as i understand it is the
only special cell in the grid editing tir files. Ideally that cell
should contain the infinity mark to reflect the nature of
stratified_entity, is it correct?
In ihs.exe it is possible to simply use the roller button of the mouse
to change the number o bands, and if the user does accidentally erase
a band, there is no confirmation dialog popping out and the data is
lost, maybe because of that there is a small button 'revert item' that
simply restores the value of the entity. That small button could be a
nice feature to any filetype editor.

.ill and .cns files
I could not find sample files of that type. Could you please send me
one of each type so that i could understand quicker the corresponding
data structure and how to edit it?

Thank you very much in advance!

PS: i was not able to modify .make files to correctly add the new
product editor target and (especially) build and test the prototype.
There is new target 'test_pedit' in autotools makefile.am that builds
it with the usual cycle:
./autogen.sh
mkdir pedit && cd $_
../configure <options needed to find wxWidgets, xmlwrapp and boost>
make test_pedit.exe

--
ET