I was recently on Developer Fusion when I noticed some simple and easy to use C# to VB and VB to C# converters. It is not difficult to translate code from one language to the other, but sometimes I'll want to test out a code snippet from some site and it is in VB. I use C# and I don't want to have to sit there translating 20 lines of code, and I also don't want to go and get an expensive converter. These seem to do a reasonable job converting between the two languages. I've used them a fair amount so far, and I haven't run into a problem with them yet. I suggest you check them out and bookmark them. They've saved me plenty of time already.
Earlier today I was trying to debug a Stack Overflow Exception I was receiving. While debugging I was stepping into the function where the problem was occurring. I could not seem to find the problem. A line of code was calling a function and passing it a few properties as parameters and the value returned by the function was being stored in another property. Without really paying attention to which properties I was stepping into I just clicked through them and then it would throw the exception. I was quite confused and did not even think that it could be a problem with the properties, because I had stepped through them. Well, I as with many other people are annoyed when I am debugging and it steps into a property with no extra logic. Sometimes when I create a property I remember to add the DebuggerStepThrough property. If you don't know what that is I recommend you learn what it is and use it.
When a property has no extra logic in it I obviously don't care to step through its execution it is not the problem.... except when it is.
Someone added a property to a class recently and remembered to add the DebuggerStepThrough property to it. The problem is that this simple property created an infinite loop, which I did not even think to check because some of the properties I was stepping into. Only one did I not step into and it had the problem. It had the following problem.
private int _x;
[DebuggerStepThrough]
public int X
{
get
{
return _x;
}
set
{
X = value;
}
}
When I tried to set the value I jumped into a recursive loop which the debugger stepped through so it did not even let me see the problem when I was trying to debug. Gotta make sure that doesn't happen. Kind of bad when a property calls itself instead of setting the private member it is supposed to access.
In order to use an update panel you have to specify the triggers either individually or by setting the ChildrenAsTriggers property of the UpdatePanel. Sometimes you may need to set these triggers dynamically such as if the desired trigger is inside of a repeater and is not inside of the update panel. In instances such as this you will need to from the code behind register the control with the script manager. To do this you will want to use the RegisterAsynchPostBackControl function of the ScriptManager in the following manner:
ScriptManager1.RegisterAsyncPostBackControl(Button1);
This code could be inside of the OnItemDataBound event handler for a repeater or even in page load if you want to register it in code. The script manager will now know to hijack the postbacks created by this control and turn them into asynchronous postbacks. The good thing about this is that you will now not do a full postback. The bad part is that you still have to let the update panel know that it needs to update after the asynchronous postback. To do this you will want to Call the Update() method of the UpdatePanel so for example you might do the following:
protected void Button1_Click(object sender, EventArgs e)
{
// Do work
UpdatePanel1.Update();
}
By using this method you will not be tied to your .aspx pages. It is not quite as elegant as when you just use the triggers collection in the UpdatePanel on the .aspx page, but this way of doing this is still easy and possible when inside of a template such as in a repeater or a gridview.
Happy AJAXing!
Recently I had forgotten how to access the ScriptManager in my MasterPage from one of the Content Pages. There is a static method on the ScriptManager class called GetCurrent() which will allow access to the current instance of a ScriptManager. This is useful because the ScriptManagerProxy is really just designed to do the declarative work normally performed on the ASP.NET page, but some work needs to be done through code. An example would be to check the ScriptManager instances IsInAsyncPostback property.
if (ScriptManager.GetCurrent().IsInAsyncPostback)
{
// Perform only in asynchronous postback logic here.
}
This is very useful and easy, but I seem to always forget it is here. Perhaps now that I have blogged about it I will remember, and if not I can at least come back here to find it. Yes, when I forget I go through the trouble of casting Master as my MasterPage's class and then I access it that way (what a pain).
For those of you who do not read Scott Guthrie’s Blog, you really should. I know that any time I need to write JavaScript I switch out of Visual Studio, but I will not have to with Visual Studio 2008. It is supposed to have much better support for JavaScript development. Even Intellisense. For anyone interested you should check out this recent blog entry from Scott Guthrie which gives a lot of cool information about Visual Studio 2008’s JavaScript Intellisense.
I can’t wait to start using VS 2008. It has a lot of great features I plan on getting a lot of use out of.