-
-
First off, I'd like to welcome Andrew Duthie--I liked your book and your writings about Whidbey on ASP.NET Pro. Is it you, right? I ran into you at a DevConn lately but never had a chance to say Hi.
Code reduction is a always laudable initiative and a great selling point for any technology, I think. However, we (especially, authors/trainers) just have to pay attention not to *reduce* the highlights of a cool and powerful technology like ASP.NET 2.0 to just code *reduction*. That's an important feature which greatly enhances your productivity. We should focus in presentation more on the whats that provide for such a code reduction rather than impressing people with cool demos done with little or no code at all.
Declarative programming is not bad but you can enjoy it (and control it) more if you know about, say, data source controls. This answers one of the comments about having SQL into tags. Data source controls are objects meaning that you can use them programmatically too. They're the key to ASP.NET codeless data binding; but they're first and foremost POWERFUL objects. Should we highlight this enough before we run a cool master/detail codeless demo?
All in all, this is the sense of the comment I got from that attendee.
I'm happy with Whidbey and appreciate the changes that in many cases just reflect key and clear drawbacks of v1.1. Especially, for what is inherent to VS.
PS: Andrew, I'll tell you a nice story about our books. A few months ago, at a .NET roadshow here in Italy I recommended your book instead of mine--yet to ship at that time. One of the attendees soon came up to recommend all to wait for mine instead of getting yours. She said mine would have been better anyway :-)))
No, it wasn't my wife... and not even a friend or a relative... :-))))
-
-
Next week I'll be in the States to teach a Wintellect class in Tennessee. It's about .NET programming with VB.NET. It's with classes like this, apparently huge and pretentious in their effort to cover just about everything about .NET in 8x5 hours/days, that you understand the true sense of .NET. The framework is ONE. And supports different programming models--WinForms, WebForms, WebServices. I started in the early 90s with the Windows SDK and the Charles Petzold hefty tome and .NET is like a dream. Yeah, the childish dream of a shy junior programmer...
There's a trend in the evolution of .NET. A couple of weeks ago I was in Milan speaking at the biggest Italian technical event for developers (the WPC). In one of the jam sessions, one of the attendees made me the target of a gently rebuke about one of my statements. What did I say to deserve a rebuke? Gentle, but still a rebuke.
I said that Whidbey tends to make programming virtually codeless.
I was referring to ASP.NET programming and it's unquestionable that with ASP.NET 2.0 you need to write much less code to accomplish the same things. For example, look at the powerful combination of GridView and data source controls. You can easily arrange realistic master/detail views with no code at all. Unlike the codeless master/detail feature of Windows Forms (version 1.1), in ASP.NET you don't even have to write code to customize the appearance of the grid. (You realistically need to in WinForms)
However, the question here is: how much lack of code (so to speak) can realistic apps support?
Applications are still made of code. And programmers have been created (actually, instantiated and guess it happened after the canonical seven days of creation) to write code. No, I don't think .NET is going to starve programmers. I believe that codeless applications will never be a reality.
So emphasizing that Whidbey (specifically ASP.NET) largely reduces the code to write and approaches virtual codeless programming is technically incorrect?
All in all, the good news about Whidbey (and the MS trend) is that with the same effort you can now (actually, in 2005) build more powerful apps because you manage more powerful tools.
How do you feel about codeless programming?
-
-
When the desired width of a Web DataGrid column and the size of the text don't get along very well, one of two things happens. Either the column is automatically enlarged to include all the text or the text wraps to the next line.
For some reason--it could just be me--I normally happen to dislike both. So I made a point to figure out a way to add an ellipsis to the text after a certain size and use a tooltip. Yep, exactly the same behavior you get for free from a WinForms treeview. By making some reasonable assumptions, I did it. Here's how. Assumptions are:
- The DataGrid has explicit font information like font name and size in points
- The column indicates its exact width in pixels
The first step is defining a ItemDataBound event handler to capture the string being displayed in the cell. This string is the full text for the cell--the one you have to clip and adorn with a tooltip. Based on font information, you calculate the width of the text in pixels and compare that to the expected width of the column. If the text is too large for the column, you add an ellipsis and wrap the text in a tag with a proper title attribute.
The code below demonstrate the key steps.
void ItemDataBound(object sender, DataGridItemEventArgs e)
{
// Get the string to be displayed
string title = GetTheString();
// Returns the updated text for the specified column
string newText = AdjustTextForDisplay(title, 1, grid);
// Set the text including the tooltip when necessary
e.Item.Cells[1].Text = newText;
}
string AdjustTextForDisplay(string text, int colIndex, DataGrid grid)
{
// Calculate the dimensions of the text with the current font
SizeF textSize = MeasureString(text, grid.Font);
// Compare the size with the column's width
int colWidth = (int) grid.Columns[colIndex].ItemStyle.Width.Value;
if(textSize.Width > colWidth)
{
// Get the exceeding pixels
int delta = (int) (textSize.Width - colWidth);
// Calculate the average width of the characters (approx)
int avgCharWidth = (int) (textSize.Width/text.Length);
// Calculate the number of chars to trim to stay in the fixed width (approx)
int chrToTrim = (int) (delta/avgCharWidth);
// Get the proper substring + the ellipsis
// Trim 2 more chars (approx) to make room for the ellipsis
string rawText = text.Substring(0, text.Length-(chrToTrim+2)) + "...";
// Format to add a tooltip
string fmt = "{1}";
return String.Format(fmt, text, rawText);
}
return text;
}
SizeF MeasureString(string text, FontInfo fontInfo)
{
SizeF size;
float emSize = Convert.ToSingle(fontInfo.Size.Unit.Value+1);
emSize = (emSize==0 ?12 :emSize);
Font stringFont = new Font(fontInfo.Name, emSize);
Bitmap bmp = new Bitmap(1000, 100);
Graphics g = Graphics.FromImage(bmp);
size = g.MeasureString(text, stringFont);
g.Dispose();
return size;
}
Here's a screenshot. (Hopefully...)
-
-
Most of my Web datagrids use data-bound tooltips. (This is a feature that I also suggested to add to the ASP.NET 2.0 GridView.) The idea is pretty simple: you use one of the row fields to populate a tooltip control. In Web Forms, I normally achieve this by writing a ItemDataBound handler that does the following:
- Make sure the item being bound is Item or AlternatingItem
- Grab the data item
- Retrieve the control (or the cell) I want to bind to the tooltip
- Set the ToolTip property of that WebControl to one of the data item fields. Normally a cast to WebControl is required because the ToolTip property is not available on the more base class Control.
- When the control renders to HTML, the ToolTip property is rendered as a title property
It (usually) works great.
Today (no such Thanksgiving holiday in Europe...) I needed to achieve the same but for a Windows Forms datagrid. Here's how I did it.
I added a ToolTip control to the form and created a custom table style for my grid. I made the datagrid column object I wanted to use a tooltip with global in the code. Next, the following steps:
- Add a CurrentCellChanged event handler
- Retrieve column and row number for the new cell
- Map the column number to a row in the Rows collection of the underlying DataTable
- Retrieve the data-bound text from the DataRow
- Call ToolTip1.SetToolTip on the TextBox object associated with the grid column
- DataGridTextBoxColumn has a TextBox property that returns the instance of the textbox being used to edit the contents of each cell in the column. It's always the same object just moved around as you click on the cells
- The SetTooltip method on the ToolTip object sets a text to display with a control
It works. And this is enough for me now!
-
-
Very few built-in server controls make a private use of the view state; and most often this is limited to particular features. A private use of the view state is when a control stores the content of non-public properties in the view state. By storing its internal properties to the view state, the control is using the view state privately. There's no way for parent controls and for the page to access this info. That's OK because that info is private to the control itself.
Making private use of the public viewstate is and remains a perfectly legal practice. However, it becomes a dangerous one when the view state is disabled at the page level. Like it or not, if the viewstate is disabled altogether there's not much a control can do.
Purposedly, ASP.NET 2.0 introduces a new type of state for controls--the control state. This is one of my favorite new features of ASP.NET--though one too specific for being mentioned in the highlights of the technology. In ASP.NET 2.0, the control state is safer to use than the view state because none of the application or page level settings can ever affect it. If your custom control has private or protected properties stored in the view state, you should move all of them to the control state in ASP.NET 2.0. Everything you store in the control state remains there until explicitly removed. The control state is persisted to a new hidden field named __CONTROLSTATE. This means that the more data you pack into in it, the more data is moved back and forth between the browser and the Web server. Unlike the view state, though, there’s no way to control the size of the control state. You should be using control state in ASP.NET 2.0; but be very very careful about it.
The implementation is left to the control developer. In other words, there's no predefined hashtable like ViewState where you add to. At least, this is not the case in the alpha. The idea is that you maintain your state in the variables that best suit you, much like what you would do in a stateful WinForms app. Then, by overriding the new SaveControlState method you pack any critical data into an array or a hashtable and return it to the system for further binary serialization and Base64 encoding. It is important for SaveControlState to return a serializable structure.
Hidden fields are more and more at the core of ASP.NET programming :-)
On the other hand, how could it be otherwise as long as HTTP is the underlying transportation?
-
-
ASP.NET 1.x is mature. ASP.NET 2.0 has just been unveiled and won't be a reality for at least 18 months. So many new features adorn the alpha of ASP.NET 2.0 (and I would bet the farm the number will exponentially grow in the next few months) that one would eagerly look forward to using it on a regular basis. But it is not here yet. And it won't be publicly available at least until next spring.
Can I use those cool new features today? Working on an introductory ASP.NET 2.0 book (will see the light in the Beta 1 timeframe, whenever it is), I feel like running with the hare and hunt with the hounds. In Italy we express the same concept using a different metaphor that probably is more apt to describe the sense of transition here. We use to say that you have one foot in both shoes. I'm doing Web development--one foot--with two technologies. And I feel somewhat uneasy. Knowing ASP.NET 2.0, I would like to use the same features today and I sizzle; knowing it will take a while before I can, I feel uneasy.
Unless things change completely by the time Beta 1 arrives, ASP.NET 2.0 doesn't revolutionize the existing platform. Instead, it builds atop existing features and infrastructure. This opens up a new world of opportunities, for me/you as a trainer/writer and as a consultant. Extend ASP.NET 1.1 with version 2.0-like features. It's easier than you may think. You have just to be as scary-smart as MS guys are on the ASP.NET team :-)
That's my new challenge: building new and revised ASP.NET best practices to make 1.1 a better platform blinking at version 2.0. Starting next week, I'll begin working on a series of MSDN Magazine articles to illustrate this point. Expect to see the first one out around February--(Cutting Edge column, March 2004 issue).
What is the first feature I'll tackle? I'll (try to) start with personalization.