Subscribe: Infinities Loop
Added By: Feedage Forager Feedage Grade B rated
Language: English
article  atlas  control  controls  net  new  page  public  server  set  side  state  string  text  textbox  viewstate 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Infinities Loop

Infinities Loop

.NET from a new perspective

Last Build Date: Mon, 16 Apr 2012 03:17:10 +0000


If you can't beat 'em, work for 'em!

Thu, 03 Aug 2006 08:19:00 +0000

Right. I'm happy to say, I've had the privledge of joining the ASP.NET team with Microsoft! As you may imagine, that has kept me busy lately. I have a few comments from readers that I haven't answered yet, but I will get to them, I promise :)

This means I'm moving my blog! Please redirect your bookmarks and RSS readers to:

I transfered over the ViewState article since it's the most popular. I'll transfer over the rest... eventually.

I'll maintain this blog for a while. At least until the content is transfered. See you later.

TRULY Understanding Viewstate (again)

Wed, 26 Jul 2006 07:45:00 +0000

It has come to my attention that many visitors here have found me via a google search related to ViewState or something similar. For example, here's a google ranking one could be proud of! Unfortunately, not all the search results link directly to the article they seek, and it is buried 6 posts back so they don't always find it. If you're interested in my article on understanding the viewstate process, this post is for you. It's received a lot of interesting comments lately, so I think it deserves a little /bump anyway :)

Bringing ViewState into the Light

Mon, 03 Jul 2006 16:37:00 +0000

Download the sourceYAVA (Yet another ViewState Article). For years now ViewState has remained hidden in the turbulent html source of our documents and applications. ASP.NET puts it there because, well, it isn't pretty. It's pretty ugly really.Many ViewState Viewers are available that let you put on Base64 encoded glasses and see what's really in there. But sometimes I just want to have a good idea of what the size of my ViewState is on the various pages of my applications. If its too big, then I'll start thinking about optimizing it, which is when a decoder may come in handy. But to just get a feel for what its size is throughout my application, all I need is to look at the encoded string. But doing a "view source" every time is a pain.ASP.NET 2.0 makes it easy to customize how ViewState is persisted. It even comes with two persisters of its own: HiddenFieldPageStatePersister and SessionPageStatePersister. Why not have a VisibleFieldPageStatePersister?ViewState in all its gloryThe cool thing about this simple persister is that it isn't just showing you what the ViewState is. The textarea is the field that the ViewState actually lives in. That means it's easy to change the ViewState for the page. Imagine you have a complex page with dozens of input fields on them, and you are trying to test a step in a process that is several steps behind those fields. It would be a pain to have to enter all those fields every time you wanted to debug. With this, you could copy the ViewState of the form at the point you'd like to return back to, and then assuming there were no server-side actions that you depend on having actually occurred, and ViewState is enabled on all the controls you need it for, you will instantly be back in that state.WARNING: Do not let this make you think that ViewState is responsible for maintaining the state of posted input fields like TextBoxes and CheckBoxes. It isn't. Well it is, too. ViewState lets TextBoxes and such remember their state even when their value isn't naturally posted (such as when it's invisible, or people like us cheat the system as in this example). But normally TextBoxes and such remember their state simply because they are input forms, and even without ViewState their value is posted to the server. ViewState just makes it that much smarter at it (and enables things like TextChanged and CheckChanged events). So... if you have ViewState disabled on a TextBox, for example, this little trick won't restore it's state.Here's an example. On this page, the "Click here!" button changes the label of the page, like so:ViewState jumps by 128 bytes hereIf we copy the text from the "previous" field into the "current" field, a postback occurs automagically, and the form returns to it's previous state.Voila!How useful this really is, I'm not sure. There's plenty of room for improvement. For example, it could be extended to track the viewstate on every postback, allowing you to "go back" and "go forward", swapping the state along the way as appropriate. It could also have a built-in ViewState visualizer, that'd be handy. I haven't tested it in all scenarios... like when ViewState encryption is enabled. It definitely won't work if you limit the size of the ViewState field. Also, since it's using an actual TextBox control that it adds to the forms control collection, it's possible that code elsewhere on your pages could accidentally manipulate or otherwise disable the control. The simplest way to use it is to make your page inherit from the included VisibleViewStatePage class (instead of just Page).Download the source (C#) hereHappy coding! :)[...]

A drink from the fire hose

Wed, 21 Jun 2006 06:43:00 +0000

Just wanted to give thanks to the team behind A thanks for selecting my Atlas: Smart Auto Completion article as an Article of the Day!

Just to give you a clue of what that was like from this side of the screen...

Guess when it started?

Yes, the site is a veritable fire hose of traffic, and I got to take a small, brief, drink. Alas, by now my article has fallen off the list of articles of the week. And so this is also a thanks to those of you who may be sticking around (you guys are represented by the blue bars) :) It's all the nice comments I've gotten from readers that keeps me going. So definitely stop by often, because I can guarantee you there is more content to come.

Perhaps plug into my atom feed.

See ya soon!

Join the Dark Side of Visual Studio

Wed, 14 Jun 2006 04:56:00 +0000

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here: Studio is without a doubt a powerful tool. With every iteration, it continues to improve upon itself. But as you happily hack away at all your applications, you are blistfully unaware of it's evil dark side that has been there since the beginning. It's true.There are those of us who embrace the dark side. But we are out numbered...You see, the dark side isn't how it comes by default. No... it comes all happy and bright and cheery by default, and like good little jedi programmers you accept those defaults. But the dark side is there, hidden away deep within the environment settings, reaching out and corrupting those programmers who are corruptible. Why some are corruptible and some are not is a mystery that may never be solved, but each and every programmer must give pause and consider the benefits it provides.I know what you may be thinking. It's hard to read. Are you so sure about that? Lets compare it with the happy cheery default color scheme:The key difference of course is the pervasive black background color. This is the environment I and many others work in every day. For me, it started way back when I used a Borland C++ IDE that had preset environment color schemes. One was called Twilight, and it looked similar to this. That color scheme was even my inspiration for this blog template (albeit it is only a variation on a standard blogspot theme, I'm ashamed to say).Most people who see it for the first time are offended by it... but if you think about it, it really makes sense. It brings balance to the force.The default scheme sports a bright white background color with dark text over it. But monitors these days are brighter than ever. You're presumably a programmer, so you've no doubt had those late but productive coding nights, nights that are lit by only the glow of your monitor. The glow is bright enough to light up the room and cast shadows. Not unlike... a light bulb.So there you are, staring straight into a strong light source, looking for the few pixels on it which are not illuminated. Can you read the wattage and manufacturer letters on the head a light bulb while it's turned on? Ahhh... but what if the bulb were black, and only the letters on it were illuminated?This bulb has no markings, but you'd bet they'd show up nice and bright and easy to read in the right image.It seems to me the only reason a black-on-white background is so standard is because the GUI was invented to be an analogy to pen and paper. Paper is white. Your screen doesn't have to be.Want to join the dark side? Click here to download my VS2005 environment settings. Just import them via the Tools->Import and Export Settings menu. Don't worry. If it doesn't suit you, just revert :)If anyone is interested I can export VS2003 settings as well, but it requires an add-in since VS2003 doesn't have an import/export feature built in.Happy coding!UPDATE 06/19/2006As requested... To enable exporting/importing styles in VS2003 you need an add-in called VSStyler, which you can download here:VSStyler Add-In for VS2003Once you have the add-in, download the dark side style export here:The Dark Side for VS2003[...]

Atlas: Smart Auto Completion

Fri, 26 May 2006 01:50:00 +0000

Auto Completion without a Web ServiceTo get the latest version that works with Beta 2, please visit my new blog: you haven't heard of the Atlas project yet, this article may not be for you. But even then, reading this may give you a clue as to the capabilities of Atlas. To quote the Atlas site,"Atlas" is a free framework for building a new generation of richer, more interactive, highly personalized standards based Web applications.One of the innovations Atlas brings to the table is its level of integration with the server side. It is because of this integration that makes it possible for you to take advantage of Atlas' advanced client side features without leaving the comforts of the server side of the world.But despite this client/server integration, Atlas is still a truly client side framework, one that can be integrated with any server side back end, not just ASP.NET. Its design must take that into consideration, because everything it does must (and should) be a purely client side game. But if you are definitely using Atlas with ASP.NET, it would be nice if you could rely on deeper integration into the rich server side world. And that is what this article is all about.Using the Auto Complete ExtenderFirst, lets go over how the built-in stuff works. The built-in Atlas AutoCompleteExtender adds intelligent auto completion behavior to a textbox. Here's how you set one up:First thing you need is a script manager:And then place a textbox and attach an AutoCompleteExtender to it: The behavior uses the given ServicePath and ServiceMethod properties to call the specified Web Service whenever suggestions are needed. The web service, written by you, can query a database or do whatever it needs to do in order to calculate the suggestions. Here is an example of a web service that provides the necessary method signature:[WebService(Namespace = "")][WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]public class SuggestionService : System.Web.Services.WebService{ public SuggestionService() { } [WebMethod] public string[] GetSuggestions(string prefixText, int count) { return new string[] { "abc", "def", "ghi" }; }}The prefixText parameter is the text the user has entered thus far, and the count parameter is the maximum number of suggestions you should return. And just like that, we have auto-completion!Auto Completion via a Web ServiceGoing one step furtherIt's the greatest thing since the variable geometry nacelle. But, there are some limitations to this approach. Because it must call a web service, the logic for determining the suggestions is isolated from the page that contains the textbox. That means you do not have access to any state information that is available on the page. In many cases that may not be an issue. It may even be good design to isolate that logic into a web service. But because you lack that state information, you are forced to configure the web service via global means such as the web.config. For example, a connection string. What if a developer wants auto completion for different database than the one the rest of the application is using? What if the suggestions that you want to show depend on the value of another control on the page, such as a date range that should limit the search results of the query? Or maybe you have a "product category" dropdown and the textbox should only suggest results for products that are in that category? What if you are a control developer (like me) and you want to create a custom textbox control[...]

The CodeExpressionBuilder

Wed, 26 Apr 2006 00:57:00 +0000

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here: very exciting new feature in ASP.NET 2.0 is Expression Builders. Expression builders allow for some pretty interesting interaction with the ASP.NET compilation model.For example, new to ASP.NET 2.0 is the ability to reference appSettings declaratively. Lets say you wanted the text of a button to be based on a value in the appSettings section of your web.config. Piece of cake:This is made possible by the built in AppSettingsExpressionBuilder. Lets say you wanted to display a localizable string, which is stored as a resource. In ASP.NET 1.1 it was sort of a pain. No longer:<%$ resources: ResourceKey %>That's the ResourcesExpressionBuilder hard at work. Nice!There's also a ConnectionStringsExpressionBuilder so you can refer to Connection Strings defined in the new connection strings section in the web.config. That is extremely helpful when working with the new declarative data controls:Wow.Now lets take it one step further. Have you ever seen this exception?The dreaded "Server tags cannot contain constructs" exception.That's because you probably tried to do something like this: />Perhaps you tried to fix it by putting it in quotes:... Only to be thwarted once again, as the literal text, including the <%= %> construct, ended up in the page:Putting <%= %> in quotes doesn't help much.If all you want to do is show the result of this code as a string, you could quite simply just get rid of the label:<%= CurrentUserName %>That would work. But for purposes of this example, lets assume that doesn't work for you. Perhaps you need the label server control for some other reason, or perhaps you need to set a string property of some other type of server control in this way.The problem is you have incorrectly, although intuitively, tried to assign the property of a server control using the <%= %> construct. Unfortunately that is simply not supported by ASP.NET, 1.1 nor 2.0. If you ask around about your problem, someone may tell you that you will have to convert to using the <%# %> databinding construct instead. That is advice that I have given myself, I even eluded to it in my previous blog post. That will work. But it requires that you are calling DataBind() on the control, AND, it will cause you to BLOAT VIEWSTATE... and you KNOW how much I hate bloating viewstate!It seems like it should be a common need... all you want is to assign the default value for a control to something a little dynamic. Something that can't be represented with a literal. Something with some logic behind it. You can just go ahead and assign the value in your code-behind, say.. in the OnInit method.. but that too will bloat viewstate. I'm afraid there's no super simple solution unless you don't mind disabling viewstate on that control. That may work in some scenarios, but sometimes you really need the ViewState enabled! What's a web developer to do?Here's a better example. You want, for some reason, the text value of a CheckBox to be the current date and time. For whatever reason, you can't disable viewstate on the CheckBox (say, because you need the CheckChanged event, which doesn't work without viewstate). It doesn't matter why exactly. How on Earth are you going to get the current date and time into the Text property on the CheckBox, WITHOUT BLOATING VIEWSTATE? By "Bloating ViewState", I mean causing data to become serialized in the __VIEWSTATE hidden form field when i[...]

TRULY Understanding Viewstate

Mon, 13 Mar 2006 03:11:00 +0000

UPDATE: THIS POST HAS BEEN MOVED TO MY NEW BLOG! Please redirect your bookmarks here: you read this blog at all, by now you've got to be sick of me talking about ViewState. I'm sorry, but its becoming increasingly clear to me that ViewState is a very misunderstood animal. I would like to help put an end to the madness by attempting to explain exactly how the ViewState mechanism works, from beginning to end, and from many different use cases, such as declared controls vs. dynamic controls.There are a lot of great articles out there that try to dispel the myths about ViewState. You might say this is like beating a dead horse (where ViewState is the horse, and the internet is the assailant). But this horse isn't dead, let me tell you. No, he's very much alive and he's stampeding through your living room. We need to beat him down once again. No horses were harmed during the authoring of this article.It's not that there's no good information out there about ViewState, it's just all of them seem to be lacking something, and that is contributing to the community's overall confusion about ViewState. For example, one of the key features that is important to understand about ViewState is how it tracks dirtiness. Yet, here is a very good, in-depth article on ViewState that doesn't even mention it! Then there's this W3Schools article on ViewState that seems to indicate that posted form values are maintained via ViewState, but that's not true. Don't believe me? Disable ViewState on that textbox in their example and run it again). And it's the #1 Google Search Result for "ASP.NET ViewState". Can you believe that? Ok so these are all third party sites. Microsoft articles wouldn't be wrong, would they? No. But, they aren't extremely in depth either. For example, here is ASP.NET Documentation on MSDN that describes how Controls maintain state across postbacks. The documentation isn't wrong per say, but it makes a statement that isn't entirely correct:"If a control uses ViewState for property data instead of a private field, that property automatically will be persisted across round trips to the client.That seems to imply that anything you shove into the ViewState StateBag will be round-tripped in the client's browser. NOT TRUE!So it's really no wonder there is so much confusion on ViewState. There is no where I've found on the internet that has a 100% complete and accurate explanation of how it works! The best article I have ever found is this one by Scott Mitchell. There's nothing that is wrong or even ambiguous in that article, however, it is incomplete. It does not explain the relationship of controls and their child controls when it comes to initialization and ViewState Tracking, and it is this point alone that causes a bulk of the mishandlings of ViewState, at least in the experiences I've had.So the point of this article will be to first give a complete understanding of how ViewState basically functions, from beginning to end, hopefully filling in the holes that many other articles have, but without going into a lot of technical detail on things like LosFormatting, for example, because there are plenty of sites out there that do an awesome job of that already. After a complete explanation of the entire ViewState process, I will go into some examples of how developers typically misuse ViewState, usually without even realizing it, and how to fix it.First let me explain why understanding ViewState to it's core is so important:MISUNDERSTANDING OF VIEWSTATE WILL LEAD TO...Leakage of sensitive dataViewState Attacks - aka the Jedi Mind Trick -- *waves hand* that plasma tv is for sale for $1.00Poor performance - even to the point of NO PERFORMANCEPoor scalability - how many users can you handle if each is posting 50k of data every request?Overall poor designHe[...]

Composite Controls made easy

Wed, 15 Feb 2006 02:26:00 +0000

Scott Gu has an interesting article in his blog, pointing to another article in MSDN, about creating Composite Controls.Its a great read, a must read, even.I just have one problem with it. Near the beginning of the article there is some sample code as follows:public class LabelTextBox : WebControl, INamingContainer{ public string Text { get { object o = ViewState["Text"]; if (o == null) return String.Empty; return (string) o; } set { ViewState["Text"] = value; } } public string Title { get { object o = ViewState["Title"]; if (o == null) return String.Empty; return (string) o; } set { ViewState["Title"] = value; } } protected override void CreateChildControls() { Controls.Clear(); CreateControlHierarchy(); ClearChildViewState(); } protected virtual void CreateControlHierarchy() { TextBox t = new TextBox(); Label l = new Label(); t.Text = Text; l.Text = Title; Controls.Add(l); Controls.Add(t); }}This is supposed to be an example of how you can use composite controls to make your life easier. This one allows you to set a label to a textbox, which redners before the textbox. Great use of compositing.Except for one little detail...Before I explain the problem let me just say... details like this are really frustrating. ASP.NET is very powerful, but with that power comes some responsibility. It is very easy to do things the "wrong" way. It's also very, very easy to do things the right way, but you have to know the difference. And knowing the difference means having a fairly deep understanding of how the framework, well, works. This and my previous post on ViewState are just two examples of these mundane yet crucial details.And now on to the juicy stuff...My problem with the example code is really a state management thing. When it creates the textbox and label, it "copies" the Title and Text properties, which are ViewState-based properties of the composite control, into them. That raises some red flags to me, because as soon as you are finished copying the values into the child controls, your public properties are now completely disconnected from them. If someone, somewhere, for some reason, changes your Title or Text property value after this code occurs, it's too late. They will be dumb-founded as to why your control refuses to listen to their instructions (it will still render to 'old' value).THE SOLUTIONThe solution is so elegant in my opinion, I'm not sure why this isn't official recommended practice for compositing. I call it "delegating the properties". It means, don't store the state yourself, use the child control itself to store the state. The real problem was we had the value of our properties stored in two locations -- our ViewState, and our child controls' ViewState. Using the child control itself to store the state means it will always be in just one place, a place where we the parent and the child control can agree on. Here's how:private TextBox txtFoo;public MyControl(){ this.EnsureChildControls();}public string Text{ get { return this.txtFoo.Text; } set { this.txtFoo.Text = value; }}protected override CreateChildControls(){ this.txtFoo = new TextBox() this.Controls.Add(txtFoo);}The Text property does nothing more than access the textbox's Text property. No longer do we need to 'copy' the value into the textbox -- its already there!The important thing about this trick is to simply call EnsureChildControls() in your constructor. That's so the textbox will exist should someone try to set the Text property (which is very early on if they set it declaratively). Alternatively, you could call EnsureChildControls() within the get and set like so:public string Text{ get { this.EnsureChildControls(); return this.txtFoo.Text[...]

ViewState: Misunderstood monster or fluffy sleeping kitten?

Thu, 09 Feb 2006 08:01:00 +0000

The former!Let me explain something to guys. ViewState is more complicated than you think it is. That's why you all abuse it so much :) Let me demonstrate:public class MyControl : Control{ public string Text { get { return (string) this.ViewState["Text"]; } set { this.ViewState["Text"] = value; } } protected override void OnLoad(object sender, EventArgs args) { if(!Page.IsPostBack) { this.Text = "Hello World!"; } } public override void Render(HtmlTextWriter writer) { writer.WriteLine(this.Text); }}What is WRONG with this picture?Hmmmmmmm???No.. that's not it.You don't know?I told you that's not it.Give up?That's what I thought. Sorry for my rudeness but it seems like no one on the planet knows why this is wrong. I have to deal with it every day as a lead programmer. But hey, I don't blame you. I've done this sort of thing myself. It looks perfectly harmless. You want the default value of "Text" to be "Hello World!". And why wouldn't you anyway, "Hello World!" has been serving us programmers since 1812. What better way to honor its 194th birthday than to make it the default value on your Text property?No problem. Let it shine I say! But that's not what is wrong.What's wrong is HOW you make it the default value. You know that HTTP is a connectionless protocol right? Well yeah, that's why Session state and ViewState were invented. To help you maintain data across those stateless requests. Brilliant, it really is! "Hello World" has never been so happy.So let me ask you... What is this line of code for?if(!Page.IsPostBack)I know. It's so you don't do unnecessary work, right?ViewState will be so kind as to save the value for you. Therefore, you'd be wasting CPU cycles if you had to set it on every request, right? Sure. What's that you say? Oh... You're also worried about overwriting the value in case someone has changed it? I see. Well that's pretty smart... I mean, afterall, ViewState is loaded before OnLoad. We wouldn't want to overwrite any precious changes to that value. Very good! Now wait just a second here...You were on the right track, but you failed to understand the REAL problem here. The problem isn't that you would be wasting CPU cycles if you reassigned the value on every request...Oh no. The problem is much greater than that.The problem is that you are completely unaware of the purpose of ViewState. Did I say that already? Sorry, really I am... Here... There's no better way than to show you.public class MyControl : Control{ public string Text { get { return this.ViewState["Text"] == null ? "Hello World" : (string) this.ViewState["Text"]; } set { this.ViewState["Text"] = value; } } public override void Render(HtmlTextWriter writer) { writer.WriteLine(this.Text); }}What have we got here. Hmm... No OnLoad anymore."Hello World" has moved up into the property. If the value in ViewState is NULL we return it. That means, dun dun dun! We have a default value! And we didn't have to set it, its just THERE.Ok... so big deal. Who cares?I'll tell you who cares... and its not a fluffy sleeping kitten.In the 2nd control, the value "Hello World!" is not persisted into the hidden form field "_VIEWSTATE". In the first control, it is.Its a very... subtle... difference. But its VERY IMPORTANT!!!I have seen controls written the "bad" way that contained dozens of properties. The result is, when someone puts this nasty control on a page, even BEFORE THE FIRST POSTBACK, their viewstate is HUGELY BLOATED with crap. If you do it the 2nd way, its just as big as if you had ZERO properties. If some unlucky Joe Programmer uses your control within a DataGrid or repeater, they'll be taking a hit once for every data item they bind.VIEWSTATE IS NOT TO BE TAKEN LIGHTLY :)Here's the rule of thumb that you must live and die by: VIEWSTA[...]

Blog, how I miss thee

Thu, 11 Aug 2005 04:38:00 +0000

I haven't forgotten about you. I've just been busy, that's all. I promise I'll never leave you my dear blog. I have a picture of us that time we went to Vegas on my desk at work. Those were such good times, weren't they? It constantly reminds me of you. You are so reliable... whatever happens I know that you will be there for me, just waiting to hear of my daily struggles. And I know that whatever I tell you will be kept between you and me... for no one in cyberspace knows you exist! Oh blog, what would I do without you? This I do not know.

Understanding Infinity

Tue, 13 Jul 2004 00:42:00 +0000

The vastness of the universe is certainly well beyond human comprehension. Just the size of the city you live in is already stretching the limits of your imagination. Truly, even with a birds eye view, you cannot grasp the scale of distance you see before you. Our minds were only intended to process the immediate surroundings, anything beyond a certain distance and size is simply unimportant. But we do have the desire to understand... and an inkling of an imagination to start with. For me, it is this concept alone that drives my artistic side. I'm not talking about arts and crafts, I'm talking about abstract thinking. I love to probe the limits of my imagination in as many different ways as I can. That is really what drives me to create poetry, when I'm motivated anyway... I want to throw together a combination of words that inspire thought. I want to pry open the ceiling of our imagination, into possibilities unknown. It's a difficult task, maybe impossible. Even if I create a work of prose that I can be proud of, that I think just might be good enough to spark a sense of curiosity in someone else's mind, I cannot know whether it is simply my desire to succeed which is fooling me into believing that I have. I am locked within the confines of my mind, utterly incapable of observing it from a suitably subjective distance. Writing is indeed one of my main outlets of artistic energy, but that same set of neurons that gives me that outlet is probing for another way out... I've tried creating electronic music. I feel as if I have the capability of creating something worth listening to, something that could vex your mind as much if not more than my words could (however much that is). But my ability to throw together notes has proven to be... uninspiring. When I was a pre-teen I spent many summer months probing my more traditional artistic abilities with pencil and paper, even with photography. Tracing was fun, but simply for the fleeting moments in which I could fool myself into believing I had created an original piece of art. I was helpless to create anything but straight-edged perspective drawings. They were easy because you could get away with using only a ruler as a guide -- even a toddler could draw a straight line. I merely had to decide where the lines would go. Its those pesky curves and the shading that are beyond my analytical mind, which is constantly wondering what precise angle and thickness to execute. But with computers, you can accomplish more with less skill. Now a toddler can not only draw a straight line, she can draw a perfectly straight line. She can choose from all possible visible colors. She can add shading, gradients, even add perspective. Surely with these powerful tools at hand, I can produce something worth thinking about? Unfortunately, no. Computers provide an infinitely broad set of tools, but it still takes a human mind to create depth with them. Why? Because it is the human mind which will be consuming the artwork, no other reason. And so probing the depths of your mind is a prerequisite to producing art worth thinking about. But probing the depths of your mind isn't enough, either. I can sit here in silence and feel the deepest of emotions about the universe around me, but unless I can harness that energy and push it out through my extremities onto some kind of physical medium, you might just think I'm a really quiet person. And it is that ability, that harnessing that I seem to be lacking completely. Because no matter what prose I create, music I compose, pictures I take, or what images I produce, they seem woefully inadequate, and they are. Not that I'm not semi-talented in at least one of these trades -- the point is I don't feel that I've conveyed the emotion at the scale I intended to. N[...]

Binding a DataGrid to an arraylist of strings

Tue, 25 May 2004 23:03:00 +0000

...or any simple value type for that matter.

A friend of mine asked me this question and of course it sounds simple. All he wanted to do was:

The question was what to put as the DataField, since he's binding an arraylist of strings, as in:

ArrayList list = new ArrayList();
grid.DataSource = list;

What indeed? There's no property on the string data type that returns the string. Doing a little google searching didn't turn up anything satisfactory. One idea was to wrap up the array list into a hashtable (where you can use Key/Value), or to make a custom class and bind that. Yuck, thats a hack! It isn't reusable at all -- and most importantly, it might be a designer messing with the aspx (or ascx) page, and they can't and shouldn't have to write code to accomplish the task. Here's what I would consider the "right" way, which requires zero code changes:

<%# Container.DataItem %>


Sun, 23 May 2004 03:37:00 +0000

That mid-day dip in alertness really grabs hold of me sometimes. Sure, staying up researching longhorn until 1:30 the night before doesn't help. Neither does getting up before the sun rises (an evilness in today's world). But that mid-day dip still seems unnaturally strong. The interesting thing is it's always around 2pm at its worst... if I manage to fight through it, by 3pm I'm back up to normal, and as chip as ever. I know what you're thinking -- its the lunch! Yah I've heard that before but I don't believe it. It doesn't matter when or what I have to eat. Even if I eat nothing.

What's the deal??? Is there something in the air conditioning ducts? It's as if the human body was meant to take a nice little siesta in the middle of the day.

As far as I can tell via google that's a generally accepted idea, and many studies have shown that a 15-20 minute "powernap" once or twice a day can increase overall alertness. Say what?? Where was this study when some genious invented the 8 hour work day? ... good night.

Hello World

Sat, 22 May 2004 21:42:00 +0000

This will be a place for my thoughts. Thoughts about the world, the universe, philosophy, yadda yadda yadda. They'll be wierd, sometimes they won't make any sense, sometimes they will be completely wrong. That's cool though... at least I've got a place to put them. Maybe someone out there will stumble upon my little island of thoughts here, probably through some completely unrelated google search, like "popcorn and fish" or "what is iodized salt", or what-have-you.

If you do happen upon this blog, be sure to drop me a comment or two... I promise I won't delete it.