ross dickinson: web and desktop software developer

Always Use Caution When Using MemberwiseClone

by Ross on December 8, 2010 at 1:04 PM under .NET

I guess it goes without saying, though some people may not realize just how careful they need to be if they're using the MemberwiseClone protected method on .Net objects.

Always remember that MemberwiseClone will copy *everything* from one object in to another. There's not much to worry about with value types, because those get copied into new values no matter what. Reference types, though, have their references copied. You might think, "Hey, great, I don't have to copy over my various reference type properties". What you always need to keep in mind, though, is this copies private fields and other references you may not have in your control.

This bit me when I was using MemberwiseClone on a very basic object I'd made that implemented INotifyPropertyChanged. No problem there right? Wrong! If I had any attached event listeners to the object's PropertyChanged event, those listeners got attached to the new copy as well. If I attempted to remove the handler from the original object, it would not be removed from the copy(and vice versa).

End point: You should probably avoid MemberwiseClone if at all possible and either manually set the properties that are needed, or come up with a better way to automate the cloning process.

I discovered this bug/feature today. While working on a new page for work, I was having an issue where none of the child controls inside an ascx user control were instantiating during runtime, leading to all sorts of null reference exceptions. I wasn't quite sure why, as the custom control worked fine on every other page.

After a bit of tooling around, I found out that the problem was in how I registered the control at the top of the page. The problem was here:

<%@ Register Assembly="CompanyName" Namespace="CompanyName.Controls" TagPrefix="companyname" %>

I was trying to register the project's controls namespace so that I didn't have to register each control that I used individually. Visual Studio didn't complain, nor did the compiler. I was able to put in any of the types and it worked out fine. The big mystery is that, for reasons unknown to me, the user controls would instantiate on the page normally, but none of their child controls would. 

Switching the register back to

<%@ Register Src="~/Controls/UserControl.ascx" TagName="UserControl" TagPrefix="companyname" %>

And everything worked fine again.

The only thing I can figure out is that this is specific to user controls that have a designer file. External control libraries still work fine.

Update!

I finally realized why this was happening. Because the "ascx" part of a user control is a template, the template doesn't get loaded unless it's registered specifically. You can get around this by going: CustomControl.LoadTemplate("ascx path")!

Cleaning up ASP.Net WebForms markup

by Ross on November 19, 2010 at 1:08 PM under ASP.Net | Programming

One thing that clutters up ASP.Net websites is the amount of excessive markup created by controls.

One way to reduce the overall page size of the final output is to null/remove ID's on controls created in markup that don't need it. This often pops up because you've created a label, button, or some other control in the markup that you need to access from the code behind. If the control isn't being used on the client-side(through javascript, form validation, or some other purpose), you can safely set the ID property to null to prevent ASP from rendering the attribute. This is espescially helpful in versions previous to .Net 4, where you could potentially get id fields like "ctl00_ContentPresenter1_Parent_Child_GrandChildren_CabDrivers_lblStatus" mucking things up.

Consider this before going ahead: Objects relying on the FindControl method will still require that the ID attribute be set in order to find it. To avoid causing problems, you should null the ID property during the rendering phase. This can be done on the page level or the control level.

Removing VMWare Debugger from Visual Studio

by Ross on October 14, 2010 at 5:30 PM under Visual Studio | VMWare

A quick tip to anyone who's having trouble with removing the VMWare debugger("VMDebugger") from Visual Studio. Usually the first step is to run the uninstaller on VMWare and remove the debugger from the installed features. This doesn't work all the time though. You'll either have an issue saying the msi failed, or the installer may say "Rather than using the Modify/Change option through Add/Remove Programs, run the original VMWare Workstation installer again to modify this application".

The easiest way to do this is by renaming or removing the directory X:\installationpath\VMware\VMware Workstation\Visual Studio Integrated Debugger\

Next, start up Visual Studio and it should pop up an error message that it can't load up a plugin and if you want to remove it from the Add-In Manager permanently. Hit yes, and it should stop it from loading again. Shut down Visual Studio and relaunch it to see if the plugin's now removed. If ithe error message pops up again, you'll need to run VS in administrative mode, go through the error again, and then you should be set. Loading up in non-administrative mode won't load the plugin anymore either.

I just added a new fork on BlogEngine's codeplex site that adds widgets to the available areas themes have access to. Hopefully it'll get added to the main release!

Originally, BlogEngine was adding extra markup inside WidgetBase's Render method, which made it impossible to change unless you had access to the source code. That's usually not the case when dealing with theme creation. Later on, another change was made to WidgetBase that allowed it to support Photoshop image slices that only needed to be altered with CSS. While this is probably cool for a few people, this mostly just added a lot of excess markup to the final page. I'm a man who likes his markup slim, so this bugged me.

I thought it over a bit and realized that making a similar setup to the PostView/CommentView classes would allow a lot more flexibility and customizability for users. I created a class called WidgetContainer, a simple UserControl derived class thats sole purpose is to house a WidgetBase derived control. This class is easily themed by creating a WidgetContainer.ascx user control and adding it to a theme's directory.

The major benefit of this is that users can now have full control over their widget's markup without needing access to WidgetBase's source code.

To create a WidgetContainer theme, the only thing required is that it contains a control with the ID "phWidgetBody". That control only needs to derive from the Control class and allow children to be added to it. The WidgetContainer looks for this control at load time and adds its Widget instance to it.

Updates on this Site

by Ross on October 1, 2010 at 8:18 PM under ASP.Net | BlogEngine.NET

As someone who loves the .Net framework, I've been running this site using the open source project BlogEngine.NET. However, as I started actually making my own theme for the site, I started to become very aware of the project's shortcomings, bugs, and possible security flaws that currently exist. So please be aware that things may randomly break on this site as I update it from time to time to fix various things that I find broken.

And before anyone asks, I do report all the bugs I find to BlogEngine so that they'll hopefully be fixed in the rumored 2.0 release that's coming out at the end of the year! I'll post more about the bugs if/when they get fixed, cause I'd rather not make them public here.

Having said that, the upcoming release looks good. The admin section has been redesigned a bit to give it a more refined looking appearance, and it makes a lot more use of ajax/web services.

Using Enums in ViewState

by Ross on September 15, 2010 at 9:25 PM under ASP.Net

If you're having an issue with trying to figure out why your ViewStates are so large, check to see if you're storing any enum values inside the ViewState. ASP.Net stores each enum type's fully qualified assembly name inside the ViewState, which really bulks up the ViewState length.

An easy way to get around this is to convert the enum values to their basic value types before storing them to ViewState.

IExpress.exe Cautionary Tale

by Ross on September 2, 2010 at 3:20 PM under

Windows 7 x64 only comes with a 64 bit version of iexpress.exe. This version only creates package files that are 64 bit. Keep this in mind if you need to create a package that needs to work on 32 bit operating systems!

Preventing Focus Loss in WPF

by Ross on August 19, 2010 at 3:15 PM under Programming | WPF

For my program, Crunch, I'm trying to create a program that will be easy to convert between WPF and Silverlight. While they're the same for the most part, the two have a few differences that can lead to annoying compatibility issues. One of these is WPF's lack of Silverlight's ChildWindow class. The ChildWindow class allows for modal dialogs to pop up inside the Silverlight application itself, removing the need from breaking out of the web browser and showing a window.

Sadly, WPF doesn't have this feature. I've been able to work around this by making my own ModalDialog class. I'm not going into details on that, but one aspect that was annoying me recently.

When a ModalDialog instance displays inside its owning Window, the Window displays a container grid to cover up everything underneath. This works great for preventing mouse access of underlying controls and changing focus while the dialog is open, but this does nothing for keyboard navigation. A user could still hit tab and tab out of the control, leading to any number of problems!

The first thing I tried was disabling all underlying controls. This worked, but it seemed hacky and made the layout pretty ugly.

After some searching, I found there's two simple lines of code I can use to get around this issue. With these two properties set, keyboard focus is trapped within the container until either the property is changed, or another control is forcibly focused through code.

'Locks the tab key to the focused control

KeyboardNavigation.SetTabNavigation(modalContainerGrid, KeyboardNavigationMode.Cycle)

'Locks the tab key to the focused control if the user's also holding down Ctrl

KeyboardNavigation.SetControlTabNavigation(modalContainerGrid, KeyboardNavigationMode.Cycle)

I hope this helps someone in the future!

ASP.Net's TextBox class and MaxLength

by Ross on July 26, 2010 at 3:14 PM under Programming | ASP.Net

You learn something new every day!

It appears that ASP.Net's TextBox class doesn't have any built-in validation for trimming the Text property's length if the MaxLength property is set to a value greater than zero.

I suppose this is to give user's more leeway in how they want to validate the control, but it's not immediately obvious that a user can get around this limitation just by altering the html! ie: A user could use the FireFox FireBug extension to remove the textbox input's maxlength attribute and load it up with as much text as they'd like!

So remember kids: Always validate your input!

About the author

rossisdead is a 26 year old web and desktop software developer from New Jersey. He has two cats and likes long walks on the beach.

On Stackoverflow

On Stackoverflow Careers

On Codeplex

On Github