jump to navigation

Pass a Name Value Pair Collection to JavaScript August 8, 2011

Posted by codinglifestyle in ASP.NET, CodeProject, Javascript.
Tags: , ,
1 comment so far

In my crusade against in-line code I am endevouring to clean up the script hell in my current project. My javascript is littered these types of statements:

var hid = <%=hidSelectedItems.ClientId%>;
var msg = <%=GetResourceString('lblTooManyItems')%>;

Part of the cleanup is to minimize script on the page and instead use a separate .js file. This encourages me to write static functions which take in ids and resources as parameters, allows for easier script debugging, and removes all in-line code making maintenance or future refactoring easier.

While moving code to a proper .js file is nice there are times we might miss the in-line goodness. Never fear, we can build a JavaScript object containing properties for anything we might need with ease. This equates to passing a name/value pair collection to the JavaScript from the code behind. Take a look at this example:

    ScriptOptions options = new ScriptOptions();
    options.Add("ok", GetResourceString("btnOK"));
    options.Add("oksave", GetResourceString("btnOkSave"));
    options.Add("cancel", GetResourceString("btnCancel"));
    options.Add("viewTitle", GetResourceString("lblAddressEditorView"));
    options.Add("editTitle", GetResourceString("lblAddressEditorEdit"));
    options.Add("createTitle", GetResourceString("lblAddressEditorCreate"));
    options.RegisterOptionsScript(this, "_OptionsAddressEditorResources");

Here we’re using the ScriptOptions class to create an object called _OptionsAddressEditorResources we can access in our script. Now let’s see these options in use:

function fnAddressEditDialog(address, args) {
    //Define the buttons and events
    var buttonList = {};
    buttonList[_OptionsAddressEditorResources.ok]     = function() { return fnAddressEditOnOk(jQuery(this), args); };
    buttonList[_OptionsAddressEditorResources.oksave] = function() { return fnAddressEditOnOkSave(jQuery(this), args); };
    buttonList[_OptionsAddressEditorResources.cancel] = function() { jQuery(this).dialog("close"); };

    //Display the dialog
    jQuery("#addressEditorDialog").dialog({
        title: _OptionsAddressEditorResources.editTitle,
        modal: true,
        width: 535,
        resizable: false,
        buttons: buttonList
    });
}

Above we see the jQuery dialog using the resources contained within the _OptionsAddressEditorResources object.

So this seems simple but pretty powerful. Below is the ScriptOptions class which simply extends a Dictionary and writes out the script creating a named global object. Good luck cleaning up your script hell. Hopefully this will help.

    /// <summary>
    /// Class for generating javascript option arrays
    /// </summary>
    public class ScriptOptions : Dictionary<string, string>
    {
        /// <summary>
        /// Adds the control id to the options script
        /// </summary>
        /// <param name="control">The control.</param>
        public void AddControlId(WebControl control)
        {
            this.Add(control.ID, control.ClientID);
        }

        /// <summary>
        /// Registers all the key/values as an options script for access in the client.
        /// </summary>
        /// <param name="page">The page</param>
        /// <param name="optionsName">Name of the options object</param>
        public void RegisterOptionsScript(Page page, string optionsName)
        {
            if (!page.ClientScript.IsStartupScriptRegistered(page.GetType(), optionsName))
            {
                StringBuilder script = new StringBuilder(string.Format("var {0} = new Object();", optionsName));
                this.Keys.ToList().ForEach(key => script.Append(string.Format("{0}.{1}='{2}';", optionsName, key, this[key])));
                page.ClientScript.RegisterStartupScript(page.GetType(), optionsName, script.ToString(), true);
            } 
        }
    }
Advertisement

Custom Attributes with Extension Methods: Resource Key July 4, 2011

Posted by codinglifestyle in C#, CodeProject.
Tags: , , , , ,
add a comment

I picked up this technique in my last job to use a custom attribute to contain a resource key. The biggest benefit was all the enums in the system used this attribute which provided a way to translate that enum to text. Take a look at a sample enum:

public enum Mode
{
    [AttributeResourceKey("lblInvalid")]
    Invalid,
    [AttributeResourceKey("lblReview")]
    Review,
    [AttributeResourceKey("lblCheckout")]
    Checkout,
    [AttributeResourceKey("lblOrdered")]
    Ordered
}

Each enum uses the AttributeResourceKey to specify the resource key defined in the resx file. Combined with an extension method we can extend the enum itself to allow us to execute the following:

public void DoOperation(Mode mode)
{
    Log.Info(GetResourceString(mode.ResourceKey()));
    ...
}

The C++ head in me thinks, “why are we using reflection when a static function in a helper class could contain a switch statement to convert the enum to the resource key?”.  Technically this is sufficient and faster.  However, the C# head in me loves the idea that the enum and the resource key are intimately tied together in the same file. There is no helper function to forget to update.  The penalty of reading an attribute is a small price to pay to keep the enum and resource key together in order to increase overall maintainability.

So the first thing I am going to do is define a simple interface for my custom attributes.

public interface IAttributeValue<T>
{
    T Value { get; }
}

All this interface does is define that the custom attribute class itself will define a property called Value of type T. This will be useful when using the generic method, below, for pulling the attribute. Next we define the custom attribute class itself.

    public sealed class AttributeResourceKey : Attribute, IAttributeValue<string>
    {
        private string _resourceKey;
        public AttributeResourceKey(string resourceKey)
        {
            _resourceKey = resourceKey;
        }

        #region IAttributeValue<string> Members
        public string Value
        {
            get { return _resourceKey; }
        }
        #endregion
    }

Notice how simple the above class is. We have a constructor taking a string and a property called Value which returns said string. Now let’s look at the generic method for pulling the attribute.

    public static class AttributeHelper
    {
        /// <summary>
        /// Given an enum, pull out its attribute (if present)
        /// </summary>
        public static TReturn GetValue<TAttribute, TReturn>(object value)
        where TAttribute: IAttributeValue<TReturn>
        {
            FieldInfo fieldInfo = value.GetType().GetField(value.ToString());
            object[] attribs    = fieldInfo.GetCustomAttributes(typeof(TAttribute), false);
            TReturn returnValue = default(TReturn);

            if (attribs != null && attribs.Length > 0)
                returnValue = ((TAttribute)attribs[0]).Value;

            return returnValue;
        }
    }

The code above is the heart of code. It uses generics so you need only define this code once in a static class. By passing the attribute and return type we can extract our Value defined by IAttributeValue<TReturn>.  Using the where constraint on TAttribute allows the generic method to know this type defines a property called Value of type TReturn.  This exposes the true power of generics as without this constraint the method could only presume TAttribute is nothing more than an object.  This might tempt you to wrongly cast TAttribute in order to access it’s properties inviting an exception only seen at runtime.

Now to define our extension method, to be placed in a common namespace, to extend all enums with the ResourceKey() method.

    public static class EnumerationExtensions
    {
        /// <summary>
        /// Given an enum, pull out its resource key (if present)
        /// </summary>
        public static string ResourceKey(this Enum value)
        {
            return AttributeHelper.GetValue<AttributeResourceKey, string>(value);
        }
    }

Thanks to the generic attribute helper the above extension method looks trivial. We simply use the helper to return the resource key and now we’ve extended all our enums to have this useful property.

Understanding BackgroundWorker and Encapsulating your own Thread Class February 22, 2011

Posted by codinglifestyle in C#, CodeProject, Parallelism.
Tags: , , , , , , ,
add a comment

You may have come across this page if you were searching for any of the following:

  • BackgroundWorker events not firing
  • BackgroundWorker RunWorkerCompleted event not firing
  • BackgroundWorker threads frozen
  • Encapsulate thread class

Yesterday my web page was launching several worker threads and waiting for them to return to amalgamate the results in to a single data set to bind to a grid. Launching several worker threads and waiting for a join is a common pattern. To nicely encapsulate the thread itself I derived a class from BackgroundWorker. BackgroundWorker has many advantages such as using an event model, thread pool, and all the thread plumbing built right in. All you have to do is override OnDoWork and off you go. The RunWorkerCompleted event was used, in conjunction with a lock, to collect the data once the worker thread finished.

Everything looked good but for some reason the event never fired. The problem was that I had gotten myself in to a deadlock scenario. The expectation is that when the event fires the delegate method will run in the context of the thread which fired it. If this were true, this would have allowed my synchronization logic to operate normally and not deadlock. The reality is that BackgroundWorker goes out of its way to run this event in the calling thread’s identity. It did this so when using BackgroundWorker in conjunction with the UI no invoke will be required (an exception will be thrown if a thread tries to touch the UI’s controls requiring you to check InvokeRequired).

When in doubt, use something like this to check the identity of the thread executing the code:

Trace.WriteLine(string.Format(“Thread id {0}”, System.Threading.Thread.CurrentThread.ManagedThreadId));

Once putting the above trace in the code I would clearly see that the identity of my main thread was identical to the thread identity in the RunWorkerCompleted event. Once the code tried to aquire the lock it was all over.

So the solution in my case was not to use the RunWorkerCompleted event. I added an alternative event to my thread class and called that at the end of OnDoWork. The event executed in the context of the thread, as expected, and my synchronization logic worked fine. But I couldn’t help feeling it was a bit of a kludge and pondered whether I should be deriving from BackgroundWorker at all. However, what’s the alternative? There really aren’t other alternatives to BackgroundWorker built in to the framework but it is easy to create your own.  See below:

 /// <summary>
 /// Abstract base class which performs some work and stores it in a data property
 /// </summary>
 /// <typeparam name="T">The type of data this thread will procure</typeparam>
 public abstract class ThreadBase<T>
 {
 #region Public methods
 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 public void DoWorkAsync()
 {
     DoWorkAsync(null);
 }

 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 public void DoWorkAsync(object arguement)
 {
 ThreadPool.QueueUserWorkItem(DoWorkHelper, arguement);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 public void DoWork()
 {
 DoWork(null);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 /// <remarks>
 /// Can be called to run syncronously, which doesn't fire the OnComplete event
 /// </remarks>
 public abstract void DoWork(object arguement);
 #endregion

#region Private methods
 private void DoWorkHelper(object arguement)
 {
 DoWork(arguement);
 if (OnComplete != null)
     OnComplete.Invoke(this, Data);
 }
 #endregion

#region Properties
 public T Data { get; protected set; }
 #endregion

#region Events

 /// <summary>
 /// Delegate which is invoked when the thread has completed
 /// </summary>
 /// <param name="thread">The thread.</param>
 /// <param name="data">The data.</param>
 public delegate void ThreadComplete(ThreadBase<T> thread, T data);

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the thread</remarks>
 public event ThreadComplete OnComplete;
 #endregion
 }

My generic ThreadBase class is a lightweight baseclass substitute for BackgroundWorker providing the flexibility to call it synchronously or asynchronously, a generically typed Data property, and an OnComplete event. The OnComplete will execute in the thread’s context so synchronization of several threads won’t be a problem. Take a look at it in action:

 public class MyThread : ThreadBase<DateTime>
 {
 public override void DoWork(object arguement)
 {
 Trace.WriteLine(string.Format("MyThread thread id {0}", System.Threading.Thread.CurrentThread.ManagedThreadId));

Data = DateTime.Now;
 }
 }

What a nicely encapsulated thread! Below we can see how cleanly a MyThread can be used:

 MyThread thread = new MyThread();
 thread.OnComplete += new ThreadBase<DateTime>.ThreadComplete(thread_OnComplete);
 thread.DoWorkAsync();

 void thread_OnComplete(ThreadBase<DateTime> thread, DateTime data)
 {
 Trace.WriteLine(string.Format("Complete thread id {0}: {1}", Thread.CurrentThread.ManagedThreadId, data));
 }

Then I got to thinking what if I wanted the best of both worlds? Thanks to reflector I found out how BackgroundWorker’s RunWorkerCompleted event executes in the context of the calling thread. My generic ThreadBaseEx class offers two events: OnCompleteByThreadContext and OnCompleteByCallerContext.

 /// <summary>
 /// Abstract base class which performs some work and stores it in a data property
 /// </summary>
 /// <typeparam name="T">The type of data this thread will procure</typeparam>
 public abstract class ThreadBaseEx<T>
 {
 #region Private variables
 private AsyncOperation _asyncOperation;
 private readonly SendOrPostCallback _operationCompleted;
 #endregion

#region Ctor
 public ThreadBaseEx()
 {
 _operationCompleted = new SendOrPostCallback(AsyncOperationCompleted);
 }
 #endregion

#region Public methods
 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 public void DoWorkAsync()
 {
 DoWorkAsync(null);
 }

 /// <summary>
 /// Does the work asynchronously and fires the OnComplete event
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 public void DoWorkAsync(object arguement)
 {
 _asyncOperation = AsyncOperationManager.CreateOperation(null);
 ThreadPool.QueueUserWorkItem(DoWorkHelper, arguement);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 public void DoWork()
 {
 DoWork(null);
 }

 /// <summary>
 /// Does the work and populates the Data property
 /// </summary>
 /// <param name="arguement">The arguement object</param>
 /// <remarks>
 /// Can be called to run syncronously, which doesn't fire the OnComplete event
 /// </remarks>
 public abstract void DoWork(object arguement);
 #endregion

#region Private methods
 private void DoWorkHelper(object arguement)
 {
 DoWork(arguement);
 if (OnCompleteByThreadContext != null)
 OnCompleteByThreadContext.Invoke(this, Data);
 _asyncOperation.PostOperationCompleted(this._operationCompleted, arguement);
 }

private void AsyncOperationCompleted(object arg)
 {
 OnCompleteByCallerContext(this, Data);
 }
 #endregion

#region Properties
 public T Data { get; protected set; }
 #endregion

#region Events
 /// <summary>
 /// Delegate which is invoked when the thread has completed
 /// </summary>
 /// <param name="thread">The thread.</param>
 /// <param name="data">The data.</param>
 public delegate void ThreadComplete(ThreadBaseEx<T> thread, T data);

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the worker thread</remarks>
 public event ThreadComplete OnCompleteByThreadContext;

 /// <summary>
 /// Occurs when the thread completes.
 /// </summary>
 /// <remarks>This event operates in the context of the calling thread</remarks>
public event ThreadComplete OnCompleteByCallerContext;
 #endregion
 }

Your encapsulated thread will be the same as above, but now with two events allowing either scenario, depending on what suits.

ASP.Net Windows Authentication: Authorization by Group January 20, 2011

Posted by codinglifestyle in ASP.NET, C#, CodeProject, Security.
Tags: , , , , , , , ,
5 comments

Often in this line of work it’s the simple things that take the longest time. A seemingly simple question came up yesterday on how to lock access to a customer’s website to a specific Windows group. There are a couple of simple gotchas worth documenting in a relatively simple solution presented below.

First, let’s start with the basics. By default ASP.NET executes code using a fixed account. Assuming you are using IIS 6 or greater, the identity is specified in the application pool. However, if we set impersonation to true ASP.NET assumes the user’s identity. Combined with Windows authentication, our code will run within the context of the user’s Windows identity.

To achieve this, in the web.config we set authentication to Windows and impersonate to true. Now we will have an authenticated Windows user, we next need to focus on authorization or what rights and restrictions apply to that user. Our requirement in this case is simple, if you belong to a specified Windows group you have access, otherwise you do not. When using Windows authentication, roles within ASP.NET translate to Windows groups. To allow a specific Windows group, allow that role within the authorization tag in the web.config. We could add additional lines to allow further roles or users. In this case, we simply want to deny everyone else, so notice the deny users * wildcard below.

Web.config

<system.web>
<authentication mode=Windows/>
<identity impersonate=true/>
<authorization>
<allow roles=BUILTIN\Administrators/>
<deny users=*/>
</authorization>
</system.web>

Here’s a handy tip: When testing use the whoami command. This will show you all the groups the logged in user belongs to which is handy when testing.

If you are making modifications to local or domain groups for the current user (probably your own account for testing) ensure that you see the group information you expect with the whoami /groups command. If you have just added yourself to a test group, remember that you must logout and log back in to see these changes.

Now you could stop here, you’re website is secured. However, if you do the user will get IIS’s rather nasty 401 error page. It would be much nicer to show our own custom error or possibly redirect the user to a registration page of some sort. The problem is we’ve restricted the entire website, so even a harmless error page requires authorization. What we need is an exception, which we can do be adding the snippet below the system.web closing tag.

<location path=AccessDenied.aspx>
<system.web>
<authorization>
<allow users=*/>
</authorization>
</system.web>
</location>

What this has done is specify a specific file to have different authorization requirements to the rest of the website.  Optionally we could have specified a directory where we can place CSS, image files, a masterpage, or other resources we may want to allow access to.  In this example, we are only allowing all users to see the AccessDenied.aspx page.

You might think that using the customErrors section in the web.config would be the last step to redirect the user to the AccessDenied.aspx page. However, IIS has other ideas!  IIS catches the 401 before it ever consults with ASP.Net and therefore ignores your customErrors section for a 401. Use the below workaround in your global.asax.cs to catch the 401 and redirect the user to our error page before IIS has a chance to interfere.

Global.asax.cs

protected void Application_EndRequest(Object sender, EventArgs e)
{
if (HttpContext.Current.Response.Status.StartsWith(“401”))
{
HttpContext.Current.Response.ClearContent();
Server.Execute(AccessDenied.aspx);
}
}

If we have further security requirements, we can do further checks any time by getting the IPrincipal from Page.User or HttpContext.Current.User. We could enable a button in our UI with a simple statement such as:

adminButton.Enabled = Page.User.IsInRole(@“domain\domainadmins”);

While the solution seems obvious and elegant, it took a bit of searching and playing to get it to work just right. There are other ways of centrally enforcing security such as Application_AuthenticateRequest in global.asax. However in this case it is far more configurable to take full advantage of the settings available to us in the web.config.

Welcome Microsoft Delegate! Lambda expressions right this way… July 3, 2010

Posted by codinglifestyle in C#, CodeProject, linq, Uncategorized.
Tags: , , , , ,
add a comment

Delegates are deceptively great.  Without them something as simple as the OnClick event of a button would cease to work.  In a nutshell, they offer a simple way to pass a function as a parameter which in turn can be invoked anywhere, anytime.  Pointers for functions, very useful!

In .NET v2.0 the anonymous delegate was quietly introduced, well at least it slipped my notice.  I read about them at the same time I read about Lambda functions.  I saw them laid bare without the syntactic sugar in all they’re simple glory.  As I was stuck on a .NET v2.0 project I found sugar-free anonymous delegates useful to, say, recursively find all controls of a given Type and execute a function on the matching controls.

More recently, I was working on a robust Windows service responsible for various IO operations.  It was vitally important each file operation (heretofore fileop) had its own comprehensive try/catch block.  As the number of fileops increased the code looked like one huge catch block.

It was clear it would be nice to have just one try/catch block in a static utility class which could catch every IO exception conceivable.  Then I could replace each try/catch block with one-line:

bool isBackedUp = FileUtil.FileOp(_logger, () => File.Copy(latestFilename, backupFilename, true));

Notice the file copy on the other side of the lambda function syntax, () =>, is what is executed in the try block below:

public delegate void FileOperation();

internal static bool FileOp(ILogger logger, FileOperation fileOp)

{

bool success = false;

try

{

fileOp.DynamicInvoke();

success = true;

}

catch (ArgumentException argEx)

{

logger.Error(argEx, “Bad arguement(s) passed”);

}

catch (DirectoryNotFoundException dirEx)

{

logger.Error(dirEx, “The specified path is invalid”);

}

catch (FileNotFoundException fileEx)

{

logger.Error(fileEx, “The specified file was not found”);

}

catch (PathTooLongException pathEx)

{

logger.Error(pathEx, “The specified path, file name, or both exceed the system-defined maximum length”);

}

catch (IOException ioEx)

{

logger.Error(ioEx, “An I/O error has occurred”);

}

catch (NotSupportedException supportEx)

{

logger.Error(supportEx, “The requested operation was not supported”);

}

catch (SecurityException secEx)

{

logger.Error(secEx, “The caller does not have the required permission.”);

}

catch (UnauthorizedAccessException accessEx)

{

logger.Error(accessEx, “The caller does not have the required permission”);

}

catch (Exception ex)

{

logger.Error(ex, “General fileop exception”);

}

return success;

}

Not only was this an elegant way to catch a comprehensive set of exceptions, but the resulting code was much more readable.

Of course we could pass bigger hunks of code and this is fine in moderation.  But the flip-side can mean less readable code when lambda functions (and especially lambda expressions) are used without restraint.  Readability for the whole team is paramount.  After all, too much syntactic sugar will rot your teeth!

The brilliant thing about C# is the mind set of “I’m sure there’s a way to do this” is often rewarded with a little research.

PlaySound: A Better Way to Play Wav Files in C# April 30, 2010

Posted by codinglifestyle in C#, CodeProject, Uncategorized.
Tags: , , , , ,
1 comment so far

The other day I was whipping up a fun utility which played some wav files.  I was giving this to people who’s desktop us Windows Server 2008 so using the Windows Media Player COM object wasn’t an option and SoundPlayer didn’t seem to work with any of the wav files I had for some reason.

Back in my C++ days I used to do this all the time with winmm.dll’s PlaySound (and have a piece of freeware which uses this to a great extent).

Well, once again as a C# programmer I am saved by pinvoke!

public static class Wav

{

[DllImport(“winmm.dll”, SetLastError = true)]

static extern bool PlaySound(string pszSound, UIntPtr hmod, uint fdwSound);

[Flags]

public enum SoundFlags

{

/// <summary>play synchronously (default)</summary>

SND_SYNC = 0x0000,

/// <summary>play asynchronously</summary>

SND_ASYNC = 0x0001,

/// <summary>silence (!default) if sound not found</summary>

SND_NODEFAULT = 0x0002,

/// <summary>pszSound points to a memory file</summary>

SND_MEMORY = 0x0004,

/// <summary>loop the sound until next sndPlaySound</summary>

SND_LOOP = 0x0008,

/// <summary>don’t stop any currently playing sound</summary>

SND_NOSTOP = 0x0010,

/// <summary>Stop Playing Wave</summary>

SND_PURGE = 0x40,

/// <summary>don’t wait if the driver is busy</summary>

SND_NOWAIT = 0x00002000,

/// <summary>name is a registry alias</summary>

SND_ALIAS = 0x00010000,

/// <summary>alias is a predefined id</summary>

SND_ALIAS_ID = 0x00110000,

/// <summary>name is file name</summary>

SND_FILENAME = 0x00020000,

/// <summary>name is resource name or atom</summary>

SND_RESOURCE = 0x00040004

}

public static void Play(string strFileName)

{

PlaySound(strFileName, UIntPtr.Zero, (uint)(SoundFlags.SND_FILENAME | SoundFlags.SND_ASYNC));

}

}

Example:

FileInfo fi = new FileInfo(sFile);

Wav.Play(fi.FullName);

Unlock User or Reset Password via Database query – ASP.NET Membership February 13, 2010

Posted by codinglifestyle in ASP.NET, CodeProject.
Tags: , , , , , ,
4 comments

This morning I was logging in to my website and couldn’t log in.  My personal site uses the out-of-the-box ASP.NET v2 membership and roles.  This took a while to determine what was wrong because my own website didn’t tell me much, using a blanket unsuccessful message for any problem.  This lead me to believe my password was wrong or worse that my site had been hacked and the password changed!

It turned out I entered the wrong password too many times and locked myself out.  However, my site wasn’t programmed to tell me I was locked out (see here for improvement).  I probably entered the right password loads of times, but couldn’t tell because my account was locked.  Once I figured this out the easiest way to unlock the user was via the SQL query window as my site is deployed on an ISP.  You can unlock programatically, but I wasn’t sure how to via the database directly.  Luckily, a quick look through the sprocs revealed what I was looking for and the day was saved:

DECLARE @return_value int

EXEC @return_value = [dbo].[aspnet_Membership_UnlockUser]

@ApplicationName = N‘applicationName’,

@UserName = N‘user’

SELECT ‘Return Value’ = @return_value

GO

If you don’t know your application name, the query below can be handy.  If you need to reset your password you can use the information obtained by this query along with the sproc below.  First, create a new user or you can use an existing user with a known password.  Next, execute the query below.

SELECT au.username, aa.ApplicationName, password, passwordformat, passwordsalt

FROM aspnet_membership am

INNER JOIN aspnet_users au

ON (au.userid = am.userid)

INNER JOIN aspnet_applications aa

ON (au.applicationId = aa.applicationid)

Now that you have a valid password, salt, and password type you can set that password information to the account which needs to be reset.  So take the valid password, salt, and password format and put it in the sproc below along with the application name and user which needs to be reset.

–Prepare the change date

DECLARE @changeDate datetime

set @changeDate = getdate()

–set the password

exec aspnet_Membership_setPassword ‘applicationName’,

‘user’,

‘password’,

‘passwordsalt’,

@changeDate,

Passwordformat

Execute.  Now both users have the same password.  Good luck!

Ref: http://aquesthosting.headtreez.com/doc/b873561c-ab7a-4a8e-9934-cc9366af8a81,http://mitchelsellers.com/Blogs/tabid/54/EntryID/23/Default.aspx, http://msdn.microsoft.com/en-us/library/system.web.security.membershipuser.unlockuser.aspx

Repeaters and Lost Data After Postback (Viewstate) October 8, 2009

Posted by codinglifestyle in ASP.NET, CodeProject.
Tags: , ,
18 comments

Test question: I have a form which binds data to a Repeater on PageLoad.  The Repeater’s ItemTemplate contains a TextBox and Checkbox.  On postback the data is lost.  What’s wrong?

You may have found this page if you have been googling the following:

  • repeater postback lost data
  • dynamic control postback viewstate
  • data lost on postback

The problem is the Repeater is a dynamic control.  If you are binding in the codebehind, which we typically are, you have to realize that the textbox and checkboxes do not existuntil you DataBind().  Keeping that in mind, we should ask ourselves what is the order of execution of ViewState.  I think we can start to formulate our answer to the question above by realizing where I DataBind() and create my controls in relation to the workings of ViewState is why our data is lost on postback.

So, the answer: PageLoad is the wrong place to bind a Repeater or setup a dynamic control.  It is too late.  ViewState has already tried to resync your controls but they weren’t created yet.

What about the answer you want?  Stop toying with me and tell me the answer I hear you say.  Try OnInit().  If you bind there you’re controls will exist in time for ViewState to operate normally.

protected override void OnInit(EventArgs e)

I would have also accepted Repeaters are the evil frogspawn of Satan and should never be used unless you find peeling off your fingernails with rusty pliers appealing.

ref: http://weblogs.asp.net/ngur/archive/2004/05/17/133340.aspx, http://aspnet.4guysfromrolla.com/articles/092904-1.aspx

Change Background Color of Invalid Controls (ASP.NET Validator) September 16, 2009

Posted by codinglifestyle in ASP.NET, CodeProject.
Tags: , , , ,
11 comments

I was working with a customer who has invested a lot in redoing the validation in their web application.  I accedentially suggested wouldn’t it be nice if we could change the background or border of the field in question.  The customer loved this idea which meant I’d just created more work for myself.  After searching about I wasn’t finding this done for me, so I actually had to write some code instead of cutting and pasting.

If you set a breakpoint on WebForm_OnSubmit and step in you can check out the .NET validator script.  Key thing here is a global array called Page_Validators.  From here it is fairly trivial to test and change something about the control in question.

function fnOnUpdateValidators()

{

for (var i = 0; i < Page_Validators.length; i++)

{

var val = Page_Validators[i];

var ctrl = document.getElementById(val.controltovalidate);

if (ctrl != null && ctrl.style != null)

{

if (!val.isvalid)

ctrl.style.background=“#FFAAAA”;

else

ctrl.style.backgroundColor = “”;

}

}

}

 

Of course, one problem is if the control already had a background color, it would be lost.  This can be circumvented by storing the old value in an attribute or elsewhere.  Also, custom validators are a special case so you will need to add the appropriate changes for fields validated in a custom way.

To make sure my function is called I use the deprecated Page.RegisterOnSubmitStatement(“val”, “fnOnUpdateValidators();”).  This will call my function after the validators have fired so the isvalid is up to date.

Composite Controls: Dude, where’s my data? June 25, 2009

Posted by codinglifestyle in ASP.NET, C#, CodeProject.
Tags: , , , , , , , , ,
3 comments

I started my .NET career writing WebParts for SharePoint 2003.  You would think this would make me a bit of a server control expert, as WebParts are essentially gussied up server controls.  Yet, I’ve officially wasted 2 days on an age old composite control problem which typically involves these kinds of google searches:

  • server control postback missing data
  • postback server control child control missing
  • composite control event not firing
  • webcontrol createchildcontrol postback control
  • viewstate webcontrol data missing empty blank

Sound familiar?  I understand your pain and hope I can help.  Composite controls can be tricky, if they aren’t set up just right even the most basic example won’t work properly.

First, keep in mind there are two types of custom controls developers typically write.  There are user controls (.ascx) and server controls (.cs).   We will focus on a server control.  One gotcha for a composite control is using the right base class*.  We want to use the CompositeControl base class, not WebControl or Control.  This will tell ASP.NET to ensure the IDs of our child controls are unique (via INamingContainer).  This is simple but very important, in order for ASP.NET to wire up events and serialize ViewState the ID of a control needs to be identical at all times.  So only assign a literal string to your child control and let .NET worry about making it unique.

Now there are two cases to consider, the first is where our composite server control creates a static set of controls.  This is a straightforward case, because we can create the controls at any time.  The most important function in a server control is CreateChildControls().   This is where you can create and assign your controls to member variables.  We can have properties and get and set values straight to our member controls.   In every property just call EnsureChildControls() in each get and set.

private TextBox _TextBox;

[Bindable(true), Category(“TextBoxEx”), DefaultValue(“”), Localizable(true)]

public string Text

{

get

{

EnsureChildControls();

return _TextBox.Text;

}

set

{

EnsureChildControls();

_TextBox.Text = value;

}

}

 

protected override void CreateChildControls()

{

_TextBox = new TextBox();

_TextBox.ID = “_Text”;

 

Controls.Add(_TextBox);

}

 

In reality we may have properties or logic which determine which controls are created or how our control behaves.  This is a complicated scenario, because we cannot create the controls before the logic has been initialized (otherwise our logic will not know which controls to dynamically create)!  In this case, we want our control’s own properties independent of the child controls and we’ll store this information in ViewState, not a control.  We want to avoid calling EnsureChildControls() and delay calling CreateChildControls() prematurely.  This allows the control to be initialized first so that when CreateChildControls() is called our logic will know which controls to create.  First let’s see how to store a property in ViewState.

 

private const string STR_CreateTextBox       = “CreateTextBox”;

public bool CreateTextBox

{

get

{

if (ViewState[STR_CreateTextBox] == null)

return false;

else return (bool)ViewState[STR_CreateTextBox];

}

set

{

ViewState[STR_CreateTextBox] = value;

}

}

If you were wondering if ViewState was the right place to store properties the answer is maybe.  For a bound property it is overkill as it will be set back to its original value every postback.  In that case we simply need a property with a backing store (or in C# 3.0+ a simple get; set; will do).  But when our logic needs to be stored ViewState is the place to persist it.  Just remember that the dynamically created controls don’t need ViewState of their own so we’ll be sure to turn that off when we create them.  The right place to create and add our dynamic controls is in CreateChildControls().  Let’s create a TextBox based on some logic stored in the composite control’s ViewState.

protected override void CreateChildControls()

{

if (CreateTextBox)

{

_TextBox = new TextBox();

_TextBox.ID = “_Text”;

_TextBox.EnableViewState = false;

_TextBox.TextChanged += new EventHandler(Text_TextChanged);

Controls.Add(_TextBox);

}

}

void Text_TextChanged(object sender, EventArgs e)

{

string sText = ((TextBox)sender).Text;

}

Lets take a look at what we’re doing here.  We are dynamically creating our TextBox control in CreateChildControls().  We are setting the ID to a literal string, ASP.NET will make sure our name is unique because we inherit from CompositeControl.  We are setting EnableViewState to false because, as discussed, our composite control is already taking care of ViewState.  We are adding an event as an example as this is the right place to setup any events you might need.

Now here is the interesting bit:  How do we get the user’s value back from a dynamic TextBox?  Take another look at the property Text above and note that the getter calls CreateChildControls().  This will ensure our textbox is recreated and the form will syncronize the user’s form data back in to the textbox.  We could also capture the value using the TextBox’s text changed event to do some processing or whatever.  With this event, when we postback, our Text_TextChanged event will fire before a OK button’s click event on the page due its place in the control hierarchy.  This allows our event to manipulate the TextBox’s text value before our OK button’s click event occurs.

I’ll just note that you may be reading some advice on forum’s to override OnInit.  Contrary to that advice, CreateChildControls() is the right place to dynamically create your controls and events.  OnPreRender() is a great place for initialization as it is called after all properties are set.  And, of course, Render() gives you complete control on how your control will be drawn.

* Now I have to mention Repeater.  Repeater may cause a lot of pain with your server controls.  You may see your control working properly outside a repeater and suddenly all go pearshaped when used with one.  After a lot of trial and error I discovered this had to do with the ID assigned to the dynamic controls.  We know ASP.NET depends on the ID being identical at all points for events and serialization with the form and viewstate to take place.    Sad to say when our composite control is inside a Repeater we can not trust our IDs to .NET.  So we do not want to inherit from CompositeControl or INamingContainer.  Instead, assign a unique id yourself.  Being that it is a repeater, this can not be a literal string because no 2 controls can have the same ID.  Instead try _TextBox.ID = this.ID + “_Text”;

So although there are several points and gotchas to consider, think about using a custom control to lend some OO design to your UI.  Be sure to unit test on a simple website to make development of the control easier.  Good luck!