Re: Hints for AODL

> Hi Oleg,
> I can't help you actually because I'm doing major
changes to cell.cs  (in
> addition to the little changes I did in the cell.cs you
already have)
> 1) strongly typed values (boxed to object) so the user
will not have to
> convert the value to/from string before saving/reading
the value
> 2) automatic-recognizing/setting of
"office-value" and "office-valuetype"
> 3) handling of null/DBNull values (#N/A) (date and
boolean values support
> was already added in the cell.cs I gave you before)
> This is more .net and developer friendly 
In my implementation of Fields and Forms in case if some
attribute has
several possible values I use enumerations that represent
these values
+ have an extra value NotSet (if the attribute is not set).
For example:
  public enum TargetFrame {Self, Blank, Parent, Top,
NotSet};
The properties are also strongly typed for int, double etc.
If a value
is not set, a special value is returned (usually -1).
  
For Boolean values I use an XmlBoolean enumeration:
  public enum XmlBoolean {True,False,NotSet};

office:value-type within Forms and Fields classes is
represented by
  public enum PropertyValueType {Float, Percentage,
Currency, Date, Time, Boolean, String, NotSet};

However, the values that may have several types are still
strings.


> Just an information:
> I suppose we would not do any "breaking"
interface-changes beetween the code
> in the cvs version and the code released as
"stable"
> (If an user uses AODL 1.2 then his code should still
work with AODL 1.3)

> The question:
> Should I use ObsoleteAttribute to mark the older
methods so the code will
> still work
> or I can break the interface (and drop OfficeValue and
OfficeValueType
> properties)
> signaling them in a "breaking changes
section"?
I think it's better to ask the initial author - Lars
Behrmann - about
this 
> Moreover..
> Some member names, as I said before, should really be
changed (ie.
> Table.RowCollections -> Table.Rows)
> So this does mean that the interface should be
necessarily changed (but the
> change is worth the work)
> How should we proceed?
> Please let me know.
I agree, it's better 
In Forms and Fields I have
  TextDocument.Forms
  TextDocument.Forms.Controls
  TextDocument.Fields
etc.

> Bye,
> Lino.


-- 
Best regards,
 Oleg Yegorov                         
mailto:yegorov.oleggmail.com

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org