ASP.NET application programming
Thanks to everyone who came out tonight!
A list of excellent Entity Framework and ASP.NET MVC resources.
When you use the UpdatePanel control you probably also want to display some kind of progress bar to the user so they can see when the async. postback starts and when it’s done, at least something that indicate that some work are being done and they need to wait until it’s done. This can be done by using the UpdateProgress control shipped with ASP.Net Ajax 1.0 Extension. If you use the UpdatePanel control and specify an AsyncPostBackTrigger and also associate the UpdateProgress to an UpdaetPanel, the UpdateProgress control will not be displayed.
Incredible what a speed boost you can get with your ASP.NET AJAX apps by simply adding a few optional parameters. Shockingly faster in a lot of situations!
Just like ViewState, dynamic controls seem to be fodder for much debate, and a source of many confusing issues. This article will be the first of a multi-part series to detail just about everything you could ever want to know about how Dynamic Controls fit in with the framework.
ASP.NET has been out for half a decade. Maybe this article is a little late in the making. But with all of the new technologies coming down the pipe (e.g., Atlas), I thought it would be nice to get back to the basics. After all, not all of us have been in the game since the beginning :)
Actually, this article should probably be titled "TRULY Understanding ASP.NET". Because as you will see, dynamic controls really aren't that special. In learning how they fit in with the page life cycle, and how they are similar to static controls, you will gain an understanding of how ASP.NET works in general.
Instantiating a new user control is not as straightforward as you'd think. The logical approach would be like:
UserControl control = new UserControl();
A little bit more verbose than the old non-MasterPage way of setting a default button (Meaning the button that will receive a click event when the Enter key is pressed on the form), but still easy to do:
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. Don't worry, no horses were harmed during the authoring of this article.
In my last post I discussed how to link to a URL and pass the record identifier from a DataGrid Hyperlink column.
Moving along a bit further with this, you can have the URL opened in a child window by setting the Target field in the DataGrid Property Builder.
However, on doing this, there is a drawback in some cases: The child browser window opens to the same size as the parent browser window, fully occluding the parent window. In my case, I'd rather have the child window open smaller than the parent window to make switching between the two easier. However, I could not find a way to configure a target window size with the DataGrid Property Builder, so I had to research another approach to handling this issue:
The answer is pretty easy:
Open the child window in Visual Studio in Design mode and switch to HTML view and add onload="resizeTo(
If you want it under programmatic control, you can 'punch in' a session variable in place of the Width and Height values and just populate the session variables with the desired size before populating the datagrid:
Ran into a strange thing yesterday: I had an ASP.NET project with an existing page with very similar functionality to another page I needed to create, so I just copied the existing page using the Visual Studio Solution Explorer, renamed the file to the new filename.aspx needed for the new page, changed the Class name in the .vb code to match the new filename (Otherwise the class name of the copied file would collide with the class name of the original file I copied from.), and then tweaked the code to change the little bit of the code (and a little bit of the HTML part as well) that needed to differ in functionality from the original.
I went to try it out in the browser. The HTML part of the page looked correctly modified, but the data being displayed was from the database table being accessed by the original file.
Did I forget to change the table name? Probably, I've done dumber things... I bring up the new code in the editor, and see that I did indeed change the table name in the query. So what in the??
I added a quick Response.Write("This is a test") to the code, do a Rebuild Solution, and try it again in the browser. Same thing, and the "This is a test" does not appear.
Strange. Very strange.
Next thing I try I don't think will work: I add a Response.Write("This is the original code") to the original .aspx file that I copied from. Rebuild. Try again. The "This is the original code" shows up in the COPIED code that should say "This is a test".
Now I'm really stumped. I look through the project using Windows Explorer and open individual files using UltraEdit rather than Visual Studio. I'm a little worried about the .resx files, they contain stuff like "PublicKeyToken=b77a5c561934e089" that I'm not all that sure what they are supposed to mean. Is it possible that there is some kind of unique GUID identifying the original file is tagged into the .resx file for the copied code, and it will always point to the original? I hope not.
I'm also working with my code checked into Visual Source Safe. Is there something confused there since the original code I copied from was already checked in? Is Source Safe unable to differentiate between the two files? I check everything out, delete the .resx file for the copied code, rebuild the project, check everything back into SourceSafe, then try again. Same thing. Still could be Source Safe, but unsure what to go on.
It's the end of the day, so I leave myself some notes on my theories about what might be wrong so I can pick it up in the morning. Gettting away from a project is usually the best thing to do when you're stuck. That holds for this problem as well.
I return in the morning. Re-read my notes. Think about it for a while. Finally get to looking at the .aspx (not the .aspx.vb) code in UltraEdit again. (Sometimes it does some good to get away from all the hand-holding that Visual Studio does for you in cases of weirdness like this.) I finally find it: At the very top of the .aspx file, there is the line that looks like: