Bugs item #958052, was opened at 2004-05-21 07:49
Message generated for change (Comment added) made by derekc
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=958052&group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v3.0
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Leo von Wyss (vonwyss)
>Assigned to: Derek (derekc)
Summary: Intermediate class: inconsistent data types in Rows
Initial Comment:
When the Intermediate object is directly handed from
the Compiler to the Linker (that is, integration the
candle and light parts into one custom program), linking
fails with InvalidCastExceptions. This is because in the
Compiler, row fields are (in some cases, e.g. in the
summary stream) populated using int's, but in the Linker,
the return of row[0] (or similar) is always cast to a
string.
Suggested fix:
Row.cs, ln. 187ff:
get {
if (this.fields[field].Data != null)
return this.fields[field].Data.ToString();
else
return null;
}
Maybe the type of the this[] indexer of the Row class
should be changed to string for clarity. This would avoid
the situation altogether. In this case, the ".ToString()"
part would have be added when the values are set.
Other possible fix: Replace expressions like '(string)row
[0]' with row[0].ToString() in the Linker. This requires
checking for null in all those places, however.
I am aware that this does not occur then the WiX tools
are used as intended, but I think it is nevertheless a
design weakness to have type mismatches between the
classes.
----------------------------------------------------------------------
>Comment By: Derek (derekc)
Date: 2005-10-19 09:59
Message:
Logged In: YES
user_id=518766
This should now be fixed once 3.0 goes out (which is
hopefully soon). We opted to go with an approach in which
the data is still stored in an object field, but the type of
the object must be an int for numerical fields and a string
for everything else. To most efficiently use this new
strongly-typed data, just cast the Field.Data value as a
string or int as appropriate. Please note that the int
value (since its stored in an object field) is nullable, so
any code that reads nullable ints needs to check for null
before casting (or use Convert.ToInt32 which converts null
to 0).
----------------------------------------------------------------------
Comment By: Bill Korbecki (billkorbecki)
Date: 2005-02-03 14:06
Message:
Logged In: YES
user_id=1211578
This is a problem that we are interested in resolving, since we
have an interest in Wix as an API, rather than simply a set of
executables. I would tend to disagree, however, with the
intended fix for this problem. The information within the
Intermediate table data is meant to conform to the table
definitions as defined within the table XML files. The Compiler
properly manages that transformation, which is good. The
process followed by the "Intermediate.Load()" method should
manage it properly as well, setting data in rows per their
designation within the table definitions. Further, the Linker
methods which deal with the information should be casting
their data properly when using it (these are defined tables
with object data, not simple strings).
Suggested fixes:
Field.cs:
public object Data
{
get { return this.data; }
set { this.data =
ColumnDefinition.FormatValueAsDefinedType(value,
columnDefinition.Type); }
}
ColumnDefinition.cs:
internal static object FormatValueAsDefinedType(object
value, ColumnType type)
{
object returnData;
if (value is string)
{
// convert string to indicated type for ease of use
// (throws exception if conversion not possible)
returnData = ConvertStringToType(value, type);
}
else
{
// throw exception if not valid data type
ValidateData(value);
returnData = value;
}
return returnData;
}
NOTE: "ConvertStringToType()" and "ValidateData()"
methods left as exercise...
This allows for data set into the Intermediate to be
validated. For ease of use, it will also allow for conversion of
string data (which would come from the XML) into appropriate
forms, if necessary. With this in place, the Intermediate
should load up its data properly.
The Linker, on the other hand, really should be more careful
about how it deals with the data, since it is defined as object
data and not strings.
As a side-note, I would personally suggest using
the "Row.SetData(string, object)" method when setting data
in a row and using string constants in order to indicate the
column names. For example, rather than this:
row[0] = 1;
Use this:
row.SetData(ID_NUMBER, 1);
Where "ID_NUMBER" is a constant whose name is the column
name. This prevents the breakage that may occur if table
definitions for the tables are augmented (ie. unreal rows are
added, deleted, etc). For example, if someone is not careful
and an unreal row is inserted somewhere into the table
definitions, use of "row[0]" may change meaning,
whereas "row.SetData(ID_NUMBER, 1)" remains the same.
Maintaining the code around that table addition for the "row
[0]" case would involve tracking down all the instances
of "row[0]" within the code around that table, which would be
exceedingly error prone.
Moving towards string constants makes maintaining the code
much more manageable around table definition alterations.
For example, if column or table names change and all of the
code reference a common string constant for table and
column names, then a change in name involves a simple
change to the constant rather than a lengthy and error prone
search through the code to find all the places where the
name is hard-coded.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=958052&group_id=105970
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
WiX-devs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/wix-devs
