So, some of you wonder why... [modified]
-
John C wrote:
What's that got to do with the .net framework? Few use the built in controls for anything serious anyway.
Touche. In other words, it's reasonable to assume that Microsoft puts out junk for its .NET control library. Hmmm. Now exactly why shouldn't that reasoning be extended to other aspects of the framework then? Like WPF? Like communications? Hmmm? Marc
Marc Clifton wrote:
n other words, it's reasonable to assume that Microsoft puts out junk for its .NET control library.
No, in other words, much of the framework targets people who can't code and want to see something for free. Half of it, I would never use in a serious app, but I know what it's there for.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Marc Clifton wrote:
Utterly useless as a control that's bound to a nullable field.
Nullable types came along much later, and I guess they have not updated the control yet ( or ever, I admit )
Marc Clifton wrote:
Workaround: a new nullable property:
Why not use DateTime? ? There's a class that impliments a stored proc, it has a Dispose method and does not impliment IDisposable ( so you can't do a using statement ). The framework is far from perfect, but I don't see any of these things as more than minor annoyances.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
Nullable types came along much later, and I guess they have not updated the control yet ( or ever, I admit )
Which is utterly worthless because it still doesn't understand DBNull.Value, IOW, database nulls, which are different from C# nulls, and
int?doesn't handle DBNull.Value. What Microsoft is thinking when they have problems like this and decide to work on gloriosky features like Linq is beyond me. <blockquote class="FQ"><div class="FQA">Christian Graus wrote:</div>Why not use DateTime? ?</blockquote> Because DateTime doesn't provide a property for "this is the format I'd like". Instead, it's a hodgepodge class that combines the concept of date and time when many times you want just date, or just time. It's ironic, actually, because rarely do I find situations where both the date and time need to be entered, yet I'm stuck with the DateTime class. :rolleyes: Marc -
Marc Clifton wrote:
n other words, it's reasonable to assume that Microsoft puts out junk for its .NET control library.
No, in other words, much of the framework targets people who can't code and want to see something for free. Half of it, I would never use in a serious app, but I know what it's there for.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
No, in other words, much of the framework targets people who can't code and want to see something for free. Half of it, I would never use in a serious app, but I know what it's there for.
Truth is far more twisted than fiction. ;P Marc
-
Christian Graus wrote:
Nullable types came along much later, and I guess they have not updated the control yet ( or ever, I admit )
Which is utterly worthless because it still doesn't understand DBNull.Value, IOW, database nulls, which are different from C# nulls, and
int?doesn't handle DBNull.Value. What Microsoft is thinking when they have problems like this and decide to work on gloriosky features like Linq is beyond me. <blockquote class="FQ"><div class="FQA">Christian Graus wrote:</div>Why not use DateTime? ?</blockquote> Because DateTime doesn't provide a property for "this is the format I'd like". Instead, it's a hodgepodge class that combines the concept of date and time when many times you want just date, or just time. It's ironic, actually, because rarely do I find situations where both the date and time need to be entered, yet I'm stuck with the DateTime class. :rolleyes: MarcMarc Clifton wrote:
DBNull.Value
But before we had to write code that used magic numbers, at least we can bridge the two null concepts for value types now.
Marc Clifton wrote:
It's ironic, actually, because rarely do I find situations where both the date and time need to be entered, yet I'm stuck with the DateTime class.
I just use DateTime and pull out the part I want, I've never seen that as a huge issue.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
...I rag on the .NET framework. Here's two lovely examples. The DateTimePicker. Utterly useless as a control that's bound to a nullable field. Utterly useless for creating a "between" query that just needs the dates because when it's converted to a string, it includes the time component unless you do special stuff, even after setting the control to just providing a date picker. Workaround: a new nullable property:
public object NullableValue
{
get
{
// We just want the date with basically a default (but constant) value for the time.
// Get the short date string, as we don't want any time component,
// which hoses up SQL Server's "between" clause if there's a time component.
return Value.ToShortDateString();
}
set
{
if ( (value == null) || (value==DBNull.Value) )
{
Value = DateTime.Now;
}
else
{
Value = Convert.ToDateTime(value);
}
}
}The DataGridView. Select a row and delete it. OK, the "selection list" selects the next available row. Unless you delete the last row. Then the selection list Clears even though the current position has updated to the now last row. Workaround? This inane code to reset to binding source position which forces the selection list on the DataGridView:
protected void OnDeleteRow(object sender, EventArgs e)
{
IXDataGrid grid = (IXDataGrid)IXControl.GetControlByName(dataGridName, (IXForm)
IXControl.FindForm(this));
BindingSource bs = (BindingSource)grid.DataSource;
bs.RemoveCurrent();
UpdateButtonState(grid);if ( (grid.SelectedRows.Count == 0) && (bs.Count != 0) ) { bs.Position = 0; bs.Position = bs.Count - 1; }}
In both cases (well, if I can find the solution to the grid problem), not a total rewrite of these controls, but requiring a derived control to work around the bugs. Oh, excuse me. Features. And this was not a programming question in the lounge. Talk to the hand. :| Marc
Thyme In The Country Interacx My Blog
modified on Sunday, May 4, 2008 5:41 PM
Ah, seeing code like this reminds me of the bad old .NET days and makes me thankful I escaped it:
IXDataGrid grid = (IXDataGrid)IXControl.GetControlByName(dataGridName, (IXForm)IXControl.FindForm(this));
BindingSource bs = (BindingSource)grid.DataSource; -
Marc Clifton wrote:
DBNull.Value
But before we had to write code that used magic numbers, at least we can bridge the two null concepts for value types now.
Marc Clifton wrote:
It's ironic, actually, because rarely do I find situations where both the date and time need to be entered, yet I'm stuck with the DateTime class.
I just use DateTime and pull out the part I want, I've never seen that as a huge issue.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
I just use DateTime and pull out the part I want, I've never seen that as a huge issue.
Agreed. But sadly, a lot of this stuff falls apart when its used in conjunction with other gloriosky techniques, like data binding, automatic parameterization, validation, serialization, and so on. Taken one at a time, it's ok, but you start stringing these technologies together to form what you think should be a highly automatable process and *bang* it implodes on you. Marc
-
Ah, seeing code like this reminds me of the bad old .NET days and makes me thankful I escaped it:
IXDataGrid grid = (IXDataGrid)IXControl.GetControlByName(dataGridName, (IXForm)IXControl.FindForm(this));
BindingSource bs = (BindingSource)grid.DataSource;Nemanja Trifunovic wrote:
Ah, seeing code like this reminds me of the bad old .NET days and makes me thankful I escaped it:
to C++? Marc
-
Christian Graus wrote:
I just use DateTime and pull out the part I want, I've never seen that as a huge issue.
Agreed. But sadly, a lot of this stuff falls apart when its used in conjunction with other gloriosky techniques, like data binding, automatic parameterization, validation, serialization, and so on. Taken one at a time, it's ok, but you start stringing these technologies together to form what you think should be a highly automatable process and *bang* it implodes on you. Marc
Marc Clifton wrote:
But sadly, a lot of this stuff falls apart when its used in conjunction with other gloriosky techniques, like data binding, automatic parameterization, validation, serialization, and so on.
DataBinding works fine, you can format your data in the binding statements I don't use any of the stuff that automatically binds to a SQL source via SQL in the presentation layer, that's an example of nastiness not fit for real world code. Validators are another story again, but are a toolkit of simple common usages, and the ability to write your own if needed. I don't think you're wrong, I just don't think it's surprising.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
...I rag on the .NET framework. Here's two lovely examples. The DateTimePicker. Utterly useless as a control that's bound to a nullable field. Utterly useless for creating a "between" query that just needs the dates because when it's converted to a string, it includes the time component unless you do special stuff, even after setting the control to just providing a date picker. Workaround: a new nullable property:
public object NullableValue
{
get
{
// We just want the date with basically a default (but constant) value for the time.
// Get the short date string, as we don't want any time component,
// which hoses up SQL Server's "between" clause if there's a time component.
return Value.ToShortDateString();
}
set
{
if ( (value == null) || (value==DBNull.Value) )
{
Value = DateTime.Now;
}
else
{
Value = Convert.ToDateTime(value);
}
}
}The DataGridView. Select a row and delete it. OK, the "selection list" selects the next available row. Unless you delete the last row. Then the selection list Clears even though the current position has updated to the now last row. Workaround? This inane code to reset to binding source position which forces the selection list on the DataGridView:
protected void OnDeleteRow(object sender, EventArgs e)
{
IXDataGrid grid = (IXDataGrid)IXControl.GetControlByName(dataGridName, (IXForm)
IXControl.FindForm(this));
BindingSource bs = (BindingSource)grid.DataSource;
bs.RemoveCurrent();
UpdateButtonState(grid);if ( (grid.SelectedRows.Count == 0) && (bs.Count != 0) ) { bs.Position = 0; bs.Position = bs.Count - 1; }}
In both cases (well, if I can find the solution to the grid problem), not a total rewrite of these controls, but requiring a derived control to work around the bugs. Oh, excuse me. Features. And this was not a programming question in the lounge. Talk to the hand. :| Marc
Thyme In The Country Interacx My Blog
modified on Sunday, May 4, 2008 5:41 PM
Did you also post this on a MSFT forum so maybe it gets fixed?
-
Did you also post this on a MSFT forum so maybe it gets fixed?
Luther Weeks wrote:
Did you also post this on a MSFT forum so maybe it gets fixed?
I have little faith in the system. Marc
-
Christian Graus wrote:
Nullable types came along much later, and I guess they have not updated the control yet ( or ever, I admit )
Which is utterly worthless because it still doesn't understand DBNull.Value, IOW, database nulls, which are different from C# nulls, and
int?doesn't handle DBNull.Value. What Microsoft is thinking when they have problems like this and decide to work on gloriosky features like Linq is beyond me. <blockquote class="FQ"><div class="FQA">Christian Graus wrote:</div>Why not use DateTime? ?</blockquote> Because DateTime doesn't provide a property for "this is the format I'd like". Instead, it's a hodgepodge class that combines the concept of date and time when many times you want just date, or just time. It's ironic, actually, because rarely do I find situations where both the date and time need to be entered, yet I'm stuck with the DateTime class. :rolleyes: MarcMarc Clifton wrote:
What Microsoft is thinking when they have problems like this and decide to work on gloriosky features like Linq is beyond me.
I honestly think that they've decided that bug fixes are not as important as pushing out the next set of features. I've worked for many a small company that used this tactic in the short run to prevent competitors from gaining market share. But, It is still makes no sense to me in this instance since they (MS) effectively have no real competition in the windows developer space.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. - -Lazarus Long