So, some of you wonder why... [modified]
-
John C wrote:
the built in controls should be much better
Yeah, I edited my response. :) Marc
And to be Uber fair, every third party library I use, I have hundreds of lines of code devoted to adding extra functionality to them that should have been there in the first place. Controls are so hard to get right for everyone and trying to just leads to horrible bloat. I'd like to see winform controls that are super basic but easily extendable with possibly a library of code samples or modules that you can easily add very specific functionality as required. Trying to be everything to everyone is the downfall of the Infragistics suite which is badly in need of a complete rewrite top to bottom.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying." - David Ogilvy
-
And to be Uber fair, every third party library I use, I have hundreds of lines of code devoted to adding extra functionality to them that should have been there in the first place. Controls are so hard to get right for everyone and trying to just leads to horrible bloat. I'd like to see winform controls that are super basic but easily extendable with possibly a library of code samples or modules that you can easily add very specific functionality as required. Trying to be everything to everyone is the downfall of the Infragistics suite which is badly in need of a complete rewrite top to bottom.
"The pursuit of excellence is less profitable than the pursuit of bigness, but it can be more satisfying." - David Ogilvy
John C wrote:
I have hundreds of lines of code devoted to adding extra functionality to them that should have been there in the first place.
Yeah, I was thinking that but decided I'd stop while I was, perhaps, ahead. :)
John C wrote:
I'd like to see winform controls that are super basic but easily extendable with possibly a library of code samples or modules that you can easily add very specific functionality as required.
That would be nirvana. And not just for controls, but for all sorts of stuff! Marc
-
...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
I have to question your use of a date value in a string format...
-
:shrug: Frameworks uh, work, when you're writing the application the framework designer had in mind. When you step outside of that, you need to bite the bullet and write your own code. IMHO, the problem with the .NET BCL is that it tries to straddle that line between a set of complimentary, general-purpose libraries (to make writing supporting code for an application easier and more reliable) and a specialized, targeted framework (to make writing applications easier and more reliable). The goals of the latter often appear to be at odds with those of the former. That said, i have no idea what you're talking about and suspect you're just looking to rant. Same here.;P
Citizen 20.1.01
'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
Shog9 wrote:
is that it tries to straddle that line
Interesting point. I never thought of it that way. Marc
-
I have to question your use of a date value in a string format...
Brady Kelly wrote:
I have to question your use of a date value in a string format...
Agreed. But consider this nuance. If I return a DateTime for use in a "between" clause in SQL, I have to serialize it to a string anyways because I can't use parameters. That's another oddity in itself. Can you say "SQL injection attack"? So, instead, I could write the SQL code to strip off the time when I pass in the string. Yuck. I just want something that's a G.D. date! And then you have the mixup between XSD date and time types, time zones, and, oh god, let's not go there today. X| Marc
-
...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
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 )
-
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