4 thoughts on “Tell us your .NET troubles

  1. 1) TabPages can’t be disabled and the appearance of the tabs themselves can’t be changed (to make it look like it’s been disabled for example). This is basic stuff. Incidentally, the docs in 2005 mistakenly say that you can set the Enabled property in several places.
    2) DataBinding – It’s better, but still lacks some basics. If a textbox is bound to a varchar(20) in an ADO.NET DataTable, why does it let you type in more than 20 characters? If you bind it to an integer, why can you type in letters? I understand that you can used masked textboxes, but come on…
    3) I won’t go too much into data access/manipulation because it looks like LINQ will go a very, very long way. However… If I have access to my data source during development and during deployment, wouldn’t it be great if the information for making DataTables strongly typed coud be pulled dynamically from the data store cached instead of being in a static XML file that breaks things when the data structure changes? Once the design was firmed up, I could have the option of creating and using static XML. The only thing that really “should” break when the data schema changes are the select statements that explicitly name colmns that no longer exist.
    4) Wouldn’t WITH {} blocks be nice in C#?
    WITH this.tabControl1.Pages["tabPage1"]
    {
    .BackColor = Color.Red
    .ForeColor = Color.White
    etc…
    }
    Maybe a personal preference, but easier to type, read and understand for me than
    TabPage tabP1 =this.tabControl1.Pages["tabPage1"]
    tabP1.BackColor = Color.Red
    tabP1.ForeColor = Color.White
    etc…
    5) Better control over the appearance of disabled controls such as giving us .DisabledBackColor and .DisabledForeColor properties.

  2. 1) TabPages can’t be disabled and the appearance of the tabs themselves can’t be changed (to make it look like it’s been disabled for example). This is basic stuff. Incidentally, the docs in 2005 mistakenly say that you can set the Enabled property in several places.
    2) DataBinding – It’s better, but still lacks some basics. If a textbox is bound to a varchar(20) in an ADO.NET DataTable, why does it let you type in more than 20 characters? If you bind it to an integer, why can you type in letters? I understand that you can used masked textboxes, but come on…
    3) I won’t go too much into data access/manipulation because it looks like LINQ will go a very, very long way. However… If I have access to my data source during development and during deployment, wouldn’t it be great if the information for making DataTables strongly typed coud be pulled dynamically from the data store cached instead of being in a static XML file that breaks things when the data structure changes? Once the design was firmed up, I could have the option of creating and using static XML. The only thing that really “should” break when the data schema changes are the select statements that explicitly name colmns that no longer exist.
    4) Wouldn’t WITH {} blocks be nice in C#?
    WITH this.tabControl1.Pages["tabPage1"]
    {
    .BackColor = Color.Red
    .ForeColor = Color.White
    etc…
    }
    Maybe a personal preference, but easier to type, read and understand for me than
    TabPage tabP1 =this.tabControl1.Pages["tabPage1"]
    tabP1.BackColor = Color.Red
    tabP1.ForeColor = Color.White
    etc…
    5) Better control over the appearance of disabled controls such as giving us .DisabledBackColor and .DisabledForeColor properties.

  3. lack of good obfuscation tools suck – even after obfuscation thr .NET code is too easy to decode – so intellectual property is not preserved so goodcas in Java or in native (non-managed) code.

  4. lack of good obfuscation tools suck – even after obfuscation thr .NET code is too easy to decode – so intellectual property is not preserved so goodcas in Java or in native (non-managed) code.

Comments are closed.