May 2005 - Posts

Awhile back I wrote about my Whidby hopes, dreams, and concerns. My friend Michael wrote me today with a wishlist of his own. I realize it's kind of late in the game for additional language features, but his ideas are good (in my opinion) so I'm going to post them anyway in the hope that maybe, just maybe someone at Microsoft might take note.

1. Different scope/access modifieres for the property getter and setter.

public int Property1

   get 
   { 
      return m_iProperty1; 
   }
}

private int Property1

   set 
  { 
      m_iProperty1 = value; 
   }
}

I've personally run into this one. I tend to run into this when I want to inherit from a class that has a readonly property, and I want to set the property in the base class without exposing the setter to the rest of the world. I end up having to write a SetPropertyName(value as object) procedure (sorry about the mixed C#/VB syntax) in the child class. FXCop doesn't like the SetPropertyName() method and recommends that I "use a property setter" instead. D'oh!

2. Add a new access modifier for data members that can only be accessed through property methods even from within the containing class.

Michael's C# example (given the above property sample):

secret int m_iProperty1;
private void AMethod()

   m_iProperty1 = 2; // Compiler error 
   Property1 = 2; // Ok, no error
}

My VB .NET Example:

Public Property MyValue() As String

Private _Value as string = String.Empty   'Scope limited to getter and setter

Get

return _Value

End Get

Set(ByVal Value As String)

me._Value = Value

End Set

End Property

Posted by taganov | 7 comment(s)
Filed under:

I've wanted to use tracing for awhile and was inspired by Kevin Blakely's Post on ASP .NET Tracing in a popup window. I didn't want the tracing in the popup window--just wanted to move it down the page below my other controls. So, I borrowed Kevin's code and modified it as follows:

var defaultHeight = 600;

var origOnLoad;

if (!origOnLoad) document.onload;

window.onload = moveTraceContent;

// moves the trace div to desired position.

function moveTraceContent(height)

{

var traceDiv = GetTraceDiv();

if (traceDiv)

{

if (!height) height = defaultHeight;

traceDiv.style.position = "absolute";

traceDiv.style.top = height;

}

if (origOnLoad) return origOnLoad();

}

// Returns the div that is created by the ASP.Net trace

function GetTraceDiv()

{   

var div = document.getElementById('__asptrace');

return div;

}

Of course, you could tweak moveTraceContent to do whatever you wished.

Posted by taganov | 5 comment(s)
Filed under: ,

A co-worker and I were having an argument this morning about the best way to databind to an ASP .NET datagrid control. The argument centered around whether to use the declarative server-tag syntax in the aspx file (e.g., <%# Container.DataItem("Name") %> ) or doing it programmatically in the code-behind using the ItemDataBound() event.

I personally do not like the server-tag approach. Given that I use the code-behind to manage databinding in most other instances, and given that I often need a finer degree of presentation control than server tags give me, I prefer to write my binding code using the event model.  I realize that this approach adds a bit of complexity on the initial design side, but I find that such code is easier to modify and extend in the long run than server tags. I also like knowing that all of my binding code is in one place, and that there is a consistent approach to databinding throughout the system, making maintenance easier. Extensibility is also a concern because if the needs of the binding exceed what is normally accessible via server-tags, the binding logic has to be redeveloped from scratch in the code-behind. Finally, the server-tags approach smells of classic ASP to me; and while it's a purely emotional response, I want to stay as far away from intermingling presentation and programming logic as possible.

My co-worker recognizes that there are many instances where programmatic databinding is necessary, but argues that it's often easier to just use declarative server-tags.  His argument is that the speed-of-development on the front-end is worth the possible slower maintainability and extensibility in the future.

I realize that I'm not giving my co-worker equal space here, but in truth, that's about all he said. I'm interested if anyone else has an opinion on this subject, and what other issues may be present that we're not considering.

Thoughts?

<%# Container.DataItem("AttorneyName")%>

Posted by taganov | 17 comment(s)
Filed under: ,

I'm new to Worlds of Warcraft. If anybody happens to be in Cenarion Circle, I'm playing a (currently) 11th level Paladin named KahlanAmnell. :-)

Posted by taganov | 4 comment(s)
Filed under:
Michael Kaplan has a great post on how to make sorted views performant. His post was essentially a response to my previous post on why you shouldn't use ORDER BY statements in views. Michael shows how to make it work. Thanks Michael!

Don't put ORDER BY Statements in Views.

Delay sorting until you're actually about to use the data.

If you end up sorting differently than the default sort specified by the ORDER BY in the view, it comes as an expensive performance hit. Witness a stored procedure that was breaking a unit test due to a SqlClient.SqlTimeout Exception (took 2.5 minutes to run). Removing the ORDER BY statements from the underlying views brought execution time down to 6 seconds.

If I ever catch me putting ORDER BY statements in views again, I grant myself permission to kill me :-).


It's hard being a self-taught programmer sometimes. Will they cover this issue when I get to my relational database courses in college?

It must be my week to find really obscure problems. I have this ASP .NET page where an editor is loaded in a frame. The editor consists of a textbox and a dropdownlist. The user can enter the first few characters of the target value, and tabbing off of the textbox causes a postback. On the postback the dropdown will be updated with the first match identified in the textbox.

If the user clicks the dropdown while the page is preparing to postback, the page disappears. Further, I can't load any other pages in the frame.

Take the page out of the frame, and it works flawlessly. This isn't really an option in my application, but I did it for testing purposes just to see.

Apparently someone else had the same issue and its a known bug.

Hopefully this blog will save someone else the 2 days of research that this problem cost me.

Now to figure out the best way to work around the issue...

Posted by taganov | 4 comment(s)
Filed under:

Given the following unit test:

<Test()> Public Sub TestSortingAlgorithm()

Dim test1, test2, test3, test4 As String

test1 = "'"

test2 = "*"

test3 = "',"

test4 = "*,"

Dim formatString As String = "Compare ""{0}"" to ""{1}"": Result: {2}.{3}"

Dim Result1 As Integer = String.Compare(test1, test2)

Dim Result2 As Integer = String.Compare(test3, test4)

Debug.WriteLine(String.Format(formatString, test1, test2, Result1, vbCrLf))

Debug.WriteLine(String.Format(formatString, test3, test4, Result2, vbCrLf))

Assert.AreEqual(Result1, Result2, "It doesn't make sense that these two sets of strings should be sorted differently.")

End Sub

Here is the output:

Compare "'" to "*": Result: -1.

Compare "'," to "*,": Result: 1.

TestCase 'TestFixture.TestSortingAlgorithm' failed: It doesn't make sense that these two sets of strings should be sorted differently.

expected:<-1>

but was:<1>


UPDATE:

The following SQL (by way of comparison)

DECLARE @Temp TABLE
(
     string varchar(50)  
)

INSERT INTO @Temp (string)
VALUES('''')

INSERT INTO @Temp (string)
VALUES('*')

INSERT INTO @Temp (string)
VALUES(''',')

INSERT INTO @Temp (string)
VALUES('*,')


SELECT *
FROM @Temp
ORDER BY String ASC
GO

Yields the following Output:

'
',
*
*,

Posted by taganov | 6 comment(s)
Filed under:
More Posts