ReelChaos Blog

Say you have a custom object MyObject and you have a custom collection MyObjectCollection inheriting from CollectionBase so that you are able to bind it to a repeater. Lets say you have a custom web control that has a MyObj property that you try to set in the code front like so:

MyControl MyObj = < %# Container.DataItem %>

This does not work for me, although people have said it works for them. So after MUCH googling I found a workaround, besides loading the control in the codebehind and doing a Placeholder.Controls.Add(mycontrol) while foreaching through each object in the collection.

First add this to your repeater:

OnItemCreated="repeater_itemcreated"

Then set the codebehind like so:

public void repeater_itemcreated(object sender, RepeaterItemEventArgs e)

{

    if((e.Item.Controls.Count>1) && (e.Item.Controls[1].GetType().Name == "usercontrols_mycontrol_ascx"))

    {

        ((UserControls_MyControl)e.Item.Controls[1]).MyObjProperty = (MyObj)e.Item.DataItem;

        ((UserControls_MyControl)e.Item.Controls[1]).ID = "Content";

    }

}

Labels: asp.net, C#, coding, controls, oddities

I'm not really sure if i would decree it a design pattern (and i don't want to get into an argument as to what is one), but...

I was over at Mark's house and reviewing some code for "the video game" that we WILL create and he was showing me how the scene graph works for local transformation matrices. In video games you multiply one matrix against another against another until you position your one vertex. Well instead of doing those multiplications down the line every time something doesn't move. Instead you have a local transformation matrix you multiply by and as a vertex moves it tells its children to set their transform matrices to dirty so they know to update next frame.

This brings the story to me... It made me think the "dirty pattern"

Lets apply this to a class that represents a database object.

If the class is updating any object (reflected in a database) the class should set a "dirty" bit to know whether it should do any database changes at all. Furthermore if this class has changes it needs to make to other database classes, it can pulldown(instantiate) those classes, change them, and have them set their diry bits.

Labels: C#, coding, dev, patterns