Al,
Well, now you're getting into stuff I don't know that much about ... I have not worked much with WebForms, almost exclusively with WinForms. I did do some web stuff a few years ago when we were setting up some of the base classes (for both win and web), doing things like two-way databinding, but I haven't used it much at all since then and I've forgotten most of the details. I *do* know that the Web's DropDownList works differently than the Win's ComboBox, but I just don't know how much differently. In WinForms, a ComboBox's ValueMember does not get converted to a string if it's an int. I think maybe everything's treated as an object, but don't quote me on that. <g>
>ddl1.DataTextField = "dom_desc"; // assumed shorthand for dt.Columns["dom_desc"].ToString( );What you're calling "shorthand" is not. The DataTextField is simply a string property of the DropDownList class that tells the what the column name is in the table that the control is being bound to. You can't specify it any other way.
>It looks like Convert.IsDBNull( ) can be used to trap the DBNull.Value condition you pointed out. Is this sort of approach what's recommended, or is it more normal just to wrap an assignment in a try...catch?<NO NO NO ... never use a try/catch for something you can test with a simple if statement. Catch's are very costly! I usually just compare like this:
if (row["MyColumn"] != DBNull.Value)
I've written my own method that I call GetNonNull that takes an object and assigns it a default. So, you'd call it something like this:
int MyColumn = GetNonNull(row["MyColumn"], 0); // if I wanted to default it to zero
This method has all kinds of overloads for the various types of defaults(int, string, date, etc.)
>Finally, if you're in "advice mode" what are your general thoughts re: NULL support in backend DBs? I'm in favor of using NULLs. We use them in our DB.
~~Bonnie
>>Al,
>>
>>You almost got it right. Try this:
>>
>>SomeType someValue = (SomeType)dt.Rows[SomeRowNumber][SomeColumnName or Index];
>>
>>
>>Note that you have to do an explicit cast (since the DataRowColumn is merely an object). Also, beware of DBNull.Value. The above statement will crash if that column contains DBNull.Value. There are ways around this (typically by checking first before assigning).
>
>That's terrific, thanks! By already knowing the answer I *think* you can infer this syntax from the example in the link Craig provided but it sure isn't clear. I looked far and wide in the MSDN docs and couldn't find anything like that.
>
>This came up in the midst of wrestling with ASP.NET DropDownLists. I'm trying something like this:
>// ddl1 is a DropDownList
>ddl1.DataSource = dt;
>ddl1.DataTextField = "dom_desc"; // assumed shorthand for dt.Columns["dom_desc"].ToString( );
>ddl1.DataValueField = "dom_pkey"; // assumed shorthand for dt.Columns["dom_pkey"].ToString( );
>
>/* As an aside, it's interesting trying to read code samples that make use of these "shorthands", or
> implicit conversions or whatever their formal name is :) I find the fully-qualified versions easier to
> learn, and certainly more compatible with IntelliSense. Is there a general preference
> (i.e. "better practice") to use fully-qualified code, or "shorthand"? */
The default behaviour in the DDL seems to be that the int pkey values are being converted to strings. I don't know if a ddl.DataValueField can be anything other than a string; some Web posts I found imply it can but don't show how it's done. I've made it work casting back and forth to strings but it's a PITA, working natively with ints would be easier I think. Can you offer any advice?
>
>It looks like Convert.IsDBNull( ) can be used to trap the DBNull.Value condition you pointed out. Is this sort of approach what's recommended, or is it more normal just to wrap an assignment in a try...catch?
>
>Finally, if you're in "advice mode" what are your general thoughts re: NULL support in backend DBs? I'm working against SQL Server and getting it to do most of the grunt work by using views and sprocs. For a lot of what I'm doing now NULL support is "correct", in that the DB and app must be able to determine when a value hasn't ever been initialized. I could get around that by using default values in the DB to represent "null" but it's not quite the same.
>
>In learning .Net it's amazing how many worms come out when you open an innocent-looking little can :) Well, at least I'm learning a lot < g >
