lmi
[Top][All Lists]
Advanced

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

[lmi] Editor for product files


From: Greg Chicares
Subject: [lmi] Editor for product files
Date: Wed, 10 Aug 2005 15:22:16 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

The editor we've been discussing handles several types of files:
  *.db4 *.fnd *.pol *.rnd *.tir
The '.pol' file names the others to be used for any product; a
'product' is defined by the collection of product files it uses.

The files are separate because the data they contain are of
different types. Eventually (later this year), we'll want to find
a way to use xml for all of them. When we do that, there will no
longer be any good reason to keep the files separate, so we'll
want the editor to handle the whole collection of data as a unit,
rather than as separate groups.

I think this could be done with almost the same GUI currently
used for '.db4' and '.tir' files. The tree control on the left
side, with the selected item's data on the right, is a paradigm
that works well. The right-hand panel would have to change
dynamically depending on the datum's type, which would of course
be specified in xml.

For the '.rnd' files that specify rounding, we currently offer
a set of owner-drawn radiobuttons. That seems to work OK, though
perhaps we should find a different way if that's difficult. It
is sort of nice to see all rounding rules on the same screen,
but if we show only one at a time due to a new tree-view
paradigm, I don't think anyone will miss seeing them all at
once--and if we add lots more rounding rules, then they won't
all fit on the same screen anyway, and the genericity of the
tree-view paradigm will be welcome in that event.

I think it would be best to design the new editor with this
sort of change in mind, but actually convert the data to xml
later. The xml conversion is a large, separate project that
affects much other code in lmi, and deferring it would keep
different developers from changing the same code for now.
Creating the new wx-based editor first would also fill a
short-term business need by making the old program now used
for that purpose obsolete.




reply via email to

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