Philip Rieck

More asp.net Viewstate filters …

2004-06-18T15:53:00Z

Note, this is cross-posted from Philip Rieck's full weblog. Full entry is here. I have the strong feeling that I will no longer cross-post to weblogs.asp.net. So if you find this stuff interesting, you'll probably want to subscribe to my rss feed. Otherwise, thanks for reading and goodbye. I'll keep the content available here as long as they'll let me.

The background:

I've seen a lot of articles lately about viewstate (well, in the last two weeks or so. I'm bad about keeping up with the rss) . Scott Mitchell recently published one article on MSDN all about the viewstate, and (among other things) showed how to send less viewstate. In it he also mentioned that Scott Galloway blogged on viewstate compression using bzip2. Also of note is the Flesk viewstate optimizer. All of these allow you to send less viewstate to the client, which means that you're saving bandwidth twice -- since the browser sends the Sviewstate back with the next request. For large pages with lots of viewstate, this can make a difference even on a LAN -- let alone those poor 56K modem users.

Now, I love these articles (and that looks like a good product), but they all take the same approach. While that's probably because it's the best one, I decided to try for the same result and take a different tack.

All of the above work by either having you override your page's “PersistViewStateToFileSystem” and call a method, or have you derive your page class from a base object they provide. All well and good, eh? Hey, the support is built into the framework!

The divergence:

I like a declarative approach. That is, I want to take an existing site, add on line to the web.config, and have it do what I want. After all, this is not per-page functionality I'm talking about here... it's a cross-cutting concern. Why modify all my pages to do it?

So I wrote one that just requires you to add an HttpModule (which takes copying a dll to your /bin dir, then adding three lines to your web.config. The module also requires just one more line to configure it). While this doesn't satisfy my "add one line" need, four lines is pretty close. And I don't have to modify anything else.

Presto! Add a module, and your viewstate shrinks. What could be easier? Now, before the parties start, let me warn you -- this is no magic bullet. GZipping the viewstate takes some time that could be used to download the viewstate... so where's the happy medium? Using a file store means you have lots of files and increased disk I/O. Using the Session or Application object mean more memory. And I can't generalize your database.

So this has the shotgun approach -- it can either compress the viewstate and leave it in-page (using #ziplib), it can save it to file, it can keep it in the application or session collections, or you can implement a (very, very simple) interface and do the work yourself.

There's more... get the full article here, where the source code and binaries are.

Create context menu items in IE (a wish from cerkit.com)

2004-05-12T00:21:00Z

...The scary thing is, I don't think people realize just how easy it is to add context menu items to IE. It involves just two things:

A html file containing a script (or a script file)
A single entry in the registry

...But where's the fun? (more specifically, where's the user-friendly .net?) I went ahead and implemented it again as a .net application, just so you could use it (if you wanted to) as an example of how to make a .net-written IE menu extension application. Here's how it works...

Go to the full entry for the source code and a screen shot...

[Posted from Philip Rieck's full blog.. subscribe now, posts to weblogs.asp.net are dwindling fast!]

Announcing the Visual Studio 2005 CTP "community change log"

2004-03-30T13:50:00Z

So, as I suggested in a previous post, I'd like to use the VS2005 CTPs. All of 'em. However, I don't want to tear my hair out trying to figure out what version we should use because the stuff I'm working with is broken in the latest version. I also don't want to have to try working with someting for a day only to figure out that it is newly broken, especially if someone else has already suffered through it.

So, Without further ado, I give you the Visual Studio 2005 Community Tech Preview community running change log (VS2K5CTPCRCL).

What Dave Bettin and I (and hopefully more of you) wanted to accomplish with this is simple - make up for the lack of a change log with the CTPs. This way, we can all know what's new, what's newly broken, and what is really, really cool. Not much info is up there yet... but it's coming, and quickly. If you help, it will be that much more useful to the entire community. Otherwise, it may just be helpful to Dave and I.

[cross-posted from Philip Rieck's full blog]

Our communtiy adds the C to the VS 2005 CTP

2004-03-27T23:32:00Z

I think the community can make the CTP drops much more useful to all of us.

MS said it: VS 2005 CTP is not a beta. VS 2005 CTP is not a beta. VS 2005 CTP is not a beta. VS 2005 CTP is not a beta. Developers.

The Problem:

The expansions in C# - one of my new favorite features of visual studio - no longer work well. That is, they still produce an "expansion" when you type the shortcut, but....

You have to hit tab twice now, and Ctrl-Alt-M, X is gone (sort of replaced by [Ctrl-R, X], but entirely different behavior). It took me a few tries to get 'em going, because they show up in the intellisense menu (now), so you'd assume that just one tab would work (or selecting with mouse, or hitting ). Nope.
The cursor position is all screwed up. For example, with "prop", the cursor goes to the beginning of the file. Oops.
The expansion vars (places where you type in items that get replaced) are no longer navigable with "tab".. Well, they do get selection rectangles around them when you hit tab, but the cursor isn't moved around.
When you enter a expansion replacement area, all the text in that area isn't highlighted. You have to delete what's there, then type new content.

It's much, much, much less useful and useable than the PDC bits. If I wanted to play with expansions, I may be better off using the PDC drop. I didn't know that until digging in a bit. However, I may be wrong - perhaps there's something else different (and better) that I missed...

So anyway - The Solution. You.

Dave Bettin and I are setting up a Wiki where the community can post and track these changes, figure out CTP breaks what feature, what CTP adds what feature, etc. -- A community-built running change log that will allow for interaction as well.

Why? If I'm reading correctly, these CTP drops will be somewhat frequent. I'd love to have this "running change log" so that someone using CTP7 knows that if they want to play with some specific new feature (say, the Data Container in windows forms) they should use CTP5 instead because it's broken in CTP7. Or a person looking for the refactorings knows that moving to CTP2 is worth the headache because it adds twelve new ones.

Is this a dumb idea? Would it provide any benefit to anyone? Comment here and let me know. We should have something up quite soon, but if no-one wants it, we won't sink the effort in.

Is this a good idea but needs more oomph? Is there something that must be included? Comment here and let me know.

[This entry was cross-posted from Philip Rieck's full blog.]

HttpModule to keep post-back scroll position

2004-02-11T23:00:00Z

One of the things I hate about the joy of postbacks is losing my scroll position. On a page that's a bit longer than the window, if I have an auto-postback combobox (for example), the user selects an item, the page posts back, and poof! they're back at the top of the page.

On a corporate intranet the post back is nice and fast, and many times the user has no clue that it happened.... Except for the fact that the page just "jumped" back to the top.

Because of this I (as many people) write my controls to re-position, or I have page logic to re-position after a postback. There are articles on CodeProject with controls for keeping the scroll position, one on DotNetJunkies that isn't quite so pre-packaged, but still good, and several tutorials. The problem then is that the behavior is coded in everywhere, or the control must be included on each page, or the page must be derived from something other than the Page class, or something else.. I wanted a fire and forget solution.

So here's what I created late last night to un-vex myself -- an HTTPModule that adds scroll position retention across postbacks to all pages. It's implemented as a filter that adds javascript to the pages after they are output. I've tested it only on IE 6, as that's the browser my client site's intranet uses.

The nice thing about this (to me) is that three lines in your web.config instantly gives you scroll position retention across postbacks on every page in your application. No muss, and not a whole lot of fuss.

To use it, add the module in to your web.config (see the readme.txt included for instructions on doing this), and then configure it to either add the behavior to all pages, or be selective (again, see the readme.txt). The zip includes the source, and a pre-build binary that's strongly named in case you want to just drop it in.

If you find any bugs or problems with it, fix 'em yourself! No, really you can just leave me a comment here and I may look at it. The module works great for me (the infamous "it works on my machine!" that translates to "it only works on my machine!"), and hopefully will for you too. If you like the code, I wrote it. If you don't like the code, then some other idiot wrote it.

Download it here (13K zip)

Cross-posted from Philip Rieck's full blog. Full of neat stuff, don't miss it!

UDDI - has it ever lived?

2004-02-08T03:40:00Z

Aaron Skonnard asked “Is UDDI Dead?” a few days ago, Wondering if WS-Addressing will reduce the need for it. Dave Bettin thinks that it can be sucessful, at least in the enterprise. Michael Erls thinks so too.

My take - UDDI hasn't lived at all yet. I'm not so sure it will. I agree with the opinions that if it does, it will be in the enterprise only, but I don't think it will live there either.

Why not? Well, at several large enterprises, I've seen solutions already in place -- web services at well known points that serve up the endpoints for other web services. These are tied into a web app that lets people search for functionality based on keywords and categories that make sense in the business they have.

This solution allows developers to find the services they want, if they exist. It allows them to list and describe the services they create. It allows them to programmatically (via the webservice) find a service that they already know about. All using technologies and methods they already understand -- and indeed use on a daily basis.

Now, UDDI has a lot of cool stuff -- security, subsciption, good searching capability, blah, blah, blah... And UDDI v3 has fixed some issues (like multiple registry support, publisher keys, etc) but for most its simply overkill. They need 10% of the features -- why learn a whole new set of tools when a few hours gives them the framework that they need?

Since I've seen this succeed -- and haven't yet seen UDDI deployed in an enterprise -- I'm wondering if UDDI has ever lived. And from my experience, its future is bleak as well.

cross-posted from Philip Rieck's full blog

WaitHandles for the confused

2004-01-27T20:27:00Z

I put up a somewhat old writeup on the ManualResetEvent and AutoResetEvent on my full blog, thought since it was .net, I'd post here as well. Here's an excerpt:

Confused about WaitHandles? Sure you are. For one, they have the word "Event" on them.. Are they events? Do they call delegates?. For another, what's this "Reset" action, and why would I want to do it manually? And lastly, what does the documentation mean when it says "Signaled" and "Nonsignaled"? In project [codename] you see a good number of calls to WaitHandle-derived objects , both AutoReset and ManualReset. As the interaction can be somewhat complex, it can be difficult to decipher what is going on. Hopefully this simplified example will help clear things up.

You can find it here if you're interested. It really was written for interns, but if you've never used them, you might find it useful.

Sharing my oft-used Ink controls, part 1.

2004-01-22T04:12:00Z

I do a good amount of TabletPC development, pretty much mostly for myself. I have lots of fun and useful apps that do things I need, and some apps I use to demo the Tablet to others..

And, like any developer, I hate to redo work. So I created a library of controls that I use that I can drop-in. I showed these to a friend today and she said “Share with the world!”. So here you are. This is the first one that I would even consider letting anyone else look at, and it's not a control I'd consider anywhere near polished. But perhaps you other TabletPC developers out there can use and adapt this to reduce some of the “gruntwork”.

So, here's the TabletTextbox - it's an Ink input control that I use on a lot of forms to quickly input text / numbers whatever. It allows quick retrieval of the recognized text with the .Text property, and can optionally show a field label and / or the recognized text inside the control (each can be put in one of the four corners, or omitted).

Here's a runtime screenshot of four instances of it with different properties:

And here's where to get the source for the TabletTextBox

Feel free to do what you want with it. If you find nasty bugs, comment here and I may fix them. Even better, if you fix the nasty bugs or add features, comment here if you like so that I can use those fixes myself!

[cross-posted from Philip Rocks, Philip Rieck's new-ish real blog - here.]

Strongly typed dataset tip

2004-01-21T15:03:00Z

While doing code reviews (for .net code, of course!), I see one minor annoyance with strongly typed datasets again and again - not using the TableName property. I don't know why this comes up so often, so I thought I'd add a quick tip about it.

If you have a strongly typed dataset (some call them XSD datasets), great. You don't need to remember column names or worry about casting values. So why do I see things like this:

dAdapter.TableMappings.Add("Table1", "MyTable");
//or
cntrl.DataMember("MyTable");

Instead of using the table's name as a string, use the .TableName property as such:

dAdapter.TableMappings.Add("Table1", typedSet.MyTable.TableName);
//or
cntrl.DataMember(typedSet.MyTable.TableName);

Now you can rename your table and let the compiler find all of the code you need to change, instead of trying to do a “Find” and hoping you didn't miss any. I'm all about making the compiler find as many problems as I can.

[cross-posted from Philip Rocks, Philip Rieck's new-ish real blog - http://philiprieck.com/blog/archive/2004/01/21/152.aspx]

Don't loose this regex

2004-01-16T18:40:00Z

I really wish I knew where I found this... but after only an hour of digging in my old code, I found the regex to deal with CSV files (that is, handle both quoted and non-quoted values, commas in quoted values, etc).

I know I didn't write the regex pattern. I also know I don't want to lose this and have to try.

// ,(?=([^"]*"[^"]*")*(?![^"]*"))

Regex rex = new Regex(",(?=([^\"]*\"[^\"]*\")*(?![^\"]*\"))");
string[] values = rex.Split( csvLine );
foreach( string v in values)
{
...
}

If you have an attribution for me, please let me know. I'd like to give credit to the regex author.

[update] - yes, it was from here : http://radio.weblogs.com/0117167/2003/02/18.html#a132 (that's from Early and Adopter) (thanks, Darren Neimke!)

[cross-posted from Philip Rocks, Philip Rieck's new-ish real blog - http://philiprieck.com/blog/]

Labelling people "advanced" is done by beginners.

2003-12-10T14:21:00Z

So, I'm sure you've seen Scoble post on what advanced users need, and responses like Jeff Key's, Richard Tallent's, Andy Hopper's , and Larry O'Brien. Here's why I think that labeling users as "Advanced", "Beginner", "Blue-square", or "Rob" is a bad idea. (unless their actual name is "Beginner", or whatever)

I'm a great cook, even though I don't cook much anymore (now that my wife has surpassed me I refuse to cook lest the comparisons begin). If someone asked me if I was an "advanced" oven user, I'd say "yes" without hesitation, then prove it by letting my wife whip up something delicious. I know what temperature I want to use, why I want to use that temperature, how long to keep it there, and to not touch the hot burny type things unless supervised by an adult.

But I'm also an idiot. I know, you don't believe me, but I always turn the oven on without looking in it. That wouldn't be bad, except for the fact that 99% of the time there's a broiler pan or cookie sheet in there, and I burn something or have to juggle multiple things when putting my masterpiece in. You'd think I'd learn, but I don't - or at least haven't yet after hundreds of lessons. Now, would most people find it annoying if their oven forced them to open and close the door (ostensibly making them look into it) before turning it on? Yes. Would that same option save me problems almost every day? Yes.

However, if the salesman had said "this oven is set up for advanced users", I'd have bought it, when what he meant was "This oven allows you to turn it on without looking into it and burning the french toast you put into it to keep it slightly warm this morning" - Heck, I am an advanced user, and even if I weren't, I'd probably still think I was. Even if I knew I wasn't, I wouldn't want the "beginner oven", thinking it would annoy me with it's "I know better than you - look into me, then I'll turn on" settings. Damn condescending oven. Others might be (truly) advanced but want the beginner model because it would be simpler to use - or so they thought, until they tried to turn the oven on. "I still know there's nothing in here, you stupid oven!" they would shout. But they might like the huge playskool-style dials.

So back to software (finally): If you ask a user if they're advanced, the answer they give will have nothing to do with the settings you're trying to determine . What makes a Photoshop user advanced; intimate knowledge of layout and the Pantone color system (even though they have no idea what "double-click " means) - or the incredible ability to perform application navigation and functions (but confusion over what the heck a specular highlight is)?

The truth is, the "advanced" label is not useful. In windows settings terms, you simply can't guess at what will make a user feel as though have the perfect balance between power and ease. What you can do is aim for defaults that cause the majority of people minimal confusion (hopefully achieve some intuitive functionality), and allow easy customization to let that one specific person find their own balance.

That said, here's what I want as an "advanced user":

On initial install, set windows resolution to the right value
Yes, Scoble definitely got this right. Not doing this is really, really annoying. Richard Simmons Alarm Clock annoying.
Customization of functionality should be easy to find
Some apps allow you to change sounds for events - these sound settings show up in the application settings, and in the system "sound" settings. I like this. How about customizations "near the function", and in one repository available through the control panel. Apps could opt in to adding and retrieving user settable options from this store, which is easy for a user to maintain (unlike the registry). While I can already see some problems with this, the ease with witch one can change options is much more important than the number of options available. In fact, options that are hard to set or find means you can't have too many of them.
Ability to save, restore, and migrate all these customizations to other computers.
I no longer customize VS.NET because it's so frustrating to move these options around. If I get used to my own key bindings, I can't use the default settings easily -- and I can't move my settings easily either -- so I just get used to the default.

Perhaps a social statement

2003-12-01T18:02:00Z

From ThisIsBroken, comes this

I know I feel like this scene from Vancouver is accurate some days.

To beta or not to beta-- The previewer's dilemma

2003-11-20T14:28:00Z

I went to the PDC. I got the bits. I played with Whidbey and ASP.NET 2.0. I fell in love.

Back in the real world of work, I'm about to start a 4-6 month project. During this project we'll have to:

Use (or write our own) a page templating solution that will allow a consistent look and feel across the site with minimal effort per-page. Hmm, master pages would be perfect
Allow personalization. Hmm, doesn't asp.net 2 have a personalization engine?
We'll use objects as data sources. Unfortunately our interns will have to forgo the use of the designers because they don't support this at design time. Hey, doesn't whidbey have an object datasource?

We'd like to:

validate against XHTML. Not going to happen with VS2003.
pre-compile the huge number of pages / ascx's this project may have to catch compilation errors before the page or code-path is hit. Wish I could do this

Yikes- I want Whidbey! Now!. I can get lots of this now from different or home-grown solutions, but in 9 months or a year when this application is re-visited, I'll be using Whidbey. Wouldn't it be great if I didn't have to

Spend time now hacking together what whidbey already has in the alpha?
Not have to rewrite the code later to use whidbey features? (or support both?)

So here I am, reimplementing things that Microsoft has already built, grumbling because I can't use it. This doesn't even touch the other things I want (generics, refactoring, stencils, other “neat“ features)

I don't understand why people would want to consult a psychic - It sucks to know the future when you're stuck in the present.

Soap with attatchments change in WSE 2!

2003-11-13T04:20:00Z

Rebecca Dias let us know of a change to WSE2 based on PDC feedback:

We have already taken one action in WSE v2.0 as a result of the feedback from the PDC. Attachments will be abstracted away so that migration to MTOM will be more seemless.

This makes me very happy in two ways:

Despite letting us know that adopters of WSE are on the “Bleeding edge”, and should expect more work when migrating from one version / messaging technology to the next, they're still making it easy on us. Attachments are one of those things that we want now, and WSE is for people that aren't afraid to pay later for doing it now. Thanks for making us pay less. Ahh, SWA & DIME, I hardly knew ye.
She cares! she really cares! -- I mean, of course, that Microsoft cares. One of the biggest lessons I came away with from the PDC was that I am Microsoft's customer, and I'm important to them. Too often, people think of MS as the “evil monopoly” that simply churns out standards-breaking software, and those of us that use that software have to sit back and watch for whats coming next. Not so. Microsoft knows that by listening to me (yes, me and others like me) they are better able to a) build better software, and b) keep making money by being the platform/tool vendor of my choice.

One other thing the PDC helped me with - I stopped thinking of Microsoft as “that software company”, and started thinking of Microsoft “that company where lots of people work to make software”. Perhaps a subtle disctintion to most of you, but to me the personalization made a huge difference in my mindset about why they make some of the decisions and products that they make.

Longhorn available on Subscriber downloads

2003-11-12T20:52:00Z

That's right - the same bits of Longhorn preview available at the PDC are now available to download (MSDN subscribers only). I guessing slowly, as everyone in the world hits the servers at the same time.