HELP!

Have a problem to do with Attributes and serialization: currently it's too greedy and is serializing
to the Html/XML even blank/null ITemplates properties -- rather than not serializing nothing
when the ITemplate == null.

Let me explain:

//SCENARIO 1 -- WORKS
First let's look at a scenario that works: I have an Itemplate that I want to expose as a property
of a webcontrol:
[
System.ComponentModel.DefaultValue(null),
System.ComponentModel.NotifyParentProperty(true),
System.Web.UI.PersistenceMode(System.Web.UI.PersistenceMode.InnerProperty),
System.ComponentModel.DesignerSerializationVisibility(DesignerSerializationVisibility.Content)
]
public ITemplate TestTemplate {get {return _TestTemplate;}set {_TestTemplate = value;}}
private ITemplate _TestTemplate = null;

Perfect.
I muck around in the IDE, change other properties, and the IDE forces a save to the
XML/HTML of the control.

The result looks like:

<CC:MYCONTROL BackColor="red"/>

No referance to TestTemplate because TestTemplate is null.
Good -- that's what we want, atleast in this case when no template
is defined.



//SCENARIO 2 -- DOESNT WORK:
Now -- Let's look at what is not working:
Because I am designing a control that has many Template objects (eg: RssChannelTitle,
RssChannelDescription, RssItemTitle, RssItemDescription, footer, etc.....)
I don't want them as primary (root level) Properties of the control, but as sub-properties within an
ExpandableObject, and so that the output xml/html would look more like:

<CC:MYCONTROL>
<TEMPLATES>
<HEADER>
My Custom Header Goes here!!!
</HEADER>
<FOOTER>
My custom footer goes here...
</FOOTER>
</TEAMPLATES>
</CC:MYCONTROL>


In other words (codewise):
System.ComponentModel.DefaultValue(null), /*Q: The right DefaultValue to give when not a null? */
System.ComponentModel.NotifyParentProperty(true),
System.Web.UI.PersistenceMode(System.Web.UI.PersistenceModeInnerProperty),
//System.ComponentModel.DesignerSerializationVisibility(DesignerSerializationVisibility.Content),
public Control_Templates Templates{get {return _Templates;}}
private _Templates = new Control_Templates();
where:

[TypeConverter(typeof(ExpandableObjectConverter))]
Control_Templates {
[
System.ComponentModel.DefaultValue(null),
System.ComponentModel.NotifyParentProperty(true),
System.Web.UI.PersistenceMode(System.Web.UI.PersistenceMode.InnerProperty),
System.ComponentModel.DesignerSerializationVisibility(DesignerSerializationVisibility.Content)
]
public ITemplate Header {get {return _Header;}set {_Header = value;}}
private ITemplate _Header = null;

[[[[[[[[[[[[[[[[...many more templates defs go here...]]]]]]]]]]]]]]]]

[
System.ComponentModel.DefaultValue(null),
System.ComponentModel.NotifyParentProperty(true),
System.Web.UI.PersistenceMode(System.Web.UI.PersistenceMode.InnerProperty)
]
public ITemplate Footer {get {return _Footer;}set {_Footer = value;}}
private ITemplate _Footer = null;
}



The final result of this is that the XML generated looks like:

<CC:MYCONTROL>
<TEMPLATES>
<HEADER>
</HEADER>
<FOOTER>
</FOOTER>
</TEAMPLATES>
</CC:MYCONTROL>

even though all the ITemplates are NULL, rather than

<CC:MYCONTROL>
<TEMPLATES>
</TEAMPLATES>
</CC:MYCONTROL>

Which is causing rendering issues because during my Render() I wrote:

if (this.Templates.Header==null){this.Templates.Header = new Template_Header();}
if (this.Templates.Header!=null){
TemplateContainer_Header oHeader = new TemplateContainer_Header(this, this.oChannel);
this.Controls.Add(oHeader);
this.Templates.Header.InstantiateIn(oHeader);
}

But that doesn't work.
Now, because it has serialized the
property to being <HEADER></HEADER> it says that it has a header -- just that it's blank -- and
therefore never instantiates the builtin/default template that I provided for this scenario (but is not listed in the code on this page).


The check in Render() would now have to be something like
if (this.Templates.Header.Controls.Count == 0) {...}
or something like that, which is absurd coding.


It would be best to figure out how to ensure that it doesn't write blank ITemplates as properties in
the xml....just like it can do
when the template is a base level property.

In other words, HELP!


(And Thank you!)




PS:
I hate pounding at the keyboard like a monkey and trying random things, but I've been reduced to trying anything...
Tried so far -- modifying the attributes on one of the ITemplate sub-properties :



I have tried removing the NotifiyParentProperty -- didn't work.
I have tried setting NotifyParentProperty to false... didn't work.
I have tried taking off the DefaultProperty(null)...didn't help either.
I tried making DefaultProperty(typeof(...))
I triied making DefaultProperty("")
I tried making it PersistenceMode.Hidden --- which obviously is dumb...

Out of ideas.
....



Sky

An interesting and unpleasant dillema.
Is the ExpandableO Converter screwing it up?
Do you use template editing mode to edit the templates.

You could dig into the mono implementation of the DataGrid (the templates are not direct children), but it is probably a purely design-time issue.

I like the idea of moving the templates out into annother control, I will be back to help with this.

Hi Andrew:

:-))))
Just seeing the phrase "I will be back to help with this" made my day/weekend. I was going nuts trying to hack at this alone!


Ok. In answer to your questions:

a) Is ExpandableObject converter screwing it up. Possibly. But without it, how would I offer access to such properties from PropertyPanel?
Currently the subclass is just {ITemplateA, ITemplateB, ITemplateC} so yes I could remove this -- but later with more varied sub controls, I would have to put back the ExpandableObject attribute (eg: if subclasses were something like {SettingsA, ITemplateA} and {SettingsB, ITemplateB}

b) I have not yet created Template editors (was getting there :-)

c) I will try to find look up the code for Mono. Where to start?

c) If I hear that others don't have this issue, I will begin wondering if it is that I am still on VS2002.?

d) Yes: moving Properties to sub groups seems so logical to me: especially since the whole Net framework is about objects within objects doing specific things... I find it wierd that the logic 'stopped' there. Once you get to 'Control', there's no further breakdown. Which is fine for a small -- article size -- control, but I just tried to make a Day/Week/Month/Quarter/Year/Gant chart last week...and I was swimming around in variables everywhere...no ability to break it down elegantly to sub-elements. And I can't find any articles on how to wire up controls this way.....

Anyway, thanks so much for responding to the post! Hope we are able to find a solution. I am going to remove ExpandableObject now and see if that changes the way the IDE handles things and get back to you.


Update: I just removed the attribute. No change except for lack of access to subclass via IDE...


PS:
Just in case....If you need some code to verify this behavior, I uploaded the control in question to:
http://xact-solutions.com/shared/projects/asp.net/rssfeeder/rssfeed.cs
Cough... Its not a great control -- and I've hacked at it so much it's ... terrible.
But it does show what I mean in terms of the saving of the Templates element... The Properties are TestTemplate (works correctly) and Templates (doesn't).

Update:
In terms of your suggestion regarding DataGrid.cs and Mono project:

Found the following:
http://www.mit.edu/afs/sipb.mit.edu/project/mono/src/mcs-0.12/class/System.Web/System.Web.UI.WebControls/DataGrid.cs

but scanned code, and then checked by dropping a DataGrid into the work zone of the IDE, made me realize that it does not have Templates that are accessble via PropertyPanel in IDE... So it's not exactly the same kettle. Unless I am not seeing something that you are seeing..?

Best regards,
Sky

You did not specify what is going wrong? (or maybe I just overlooked it). Am I correct to assume that you would want this output:

<CC:MYCONTROL>


<TEMPLATES>


</TEAMPLATES>


</CC:MYCONTROL>

Instead of:

<CC:MYCONTROL>


<TEMPLATES>


<HEADER>


</HEADER>


<FOOTER>


</FOOTER>


</TEAMPLATES>


</CC:MYCONTROL>

---

-- Justin Lovell

Yes!!!! That's exactly it.

The way the IDE serializes the stuff when it is a base level Property is correct -- but when moved into a sub-class, no.

Again, IDE does it correctly if:

//No Header specified, so no output
//Footer specified manually:
<CC:CONTROL>
<FOOTER>DeeDeeDum</FOOTER>
</CC:CONTROL>


//But does it differently (and wrong) when:

//Header serialized even when codewise
//it is a null:
<CC:CONTROL>
<TEMPLATES>
<HEADER></HEADER>
<FOOTER>DeeDeeDum</FOOTER>
</TEMPLATES>
</CC:CONTROL>

The great thing about this forum is that the participants are fantastic -- helpful, friendly, and actually know what they are talking about.

The down side of this forum is that it I have again not lived by the good advice of "Sometimes it is better to keep silent and be thought the fool rather than to open your mouth and remove all doubt."

I'm a ninny.
Problem solved. :-)
And its really really dumb. =:-0

The problem is not the attributes...It's lower on the page in the Render section:

if (this.Templates.Header==null){this.Templates.Header = new Template_Header();}
if (this.Templates.Header!=null){
TemplateContainer_Header oHeader = new TemplateContainer_Header(this, this.oChannel);
this.Controls.Add(oHeader);
this.Templates.Header.InstantiateIn(oHeader);
}


What is happening is that I was too cheap in my using of temporary variables at that point.
Yes -- it is checking the public property for a null -- which is fine -- but it is SETTING the public property to something before it uses it....rather than using a local var:

Template_Header tHeader = (Template_Header)this.Templates.Header;
if (tHeader==null){tHeader = new Template_Header();}
if (tHeader!=null){
TemplateContainer_Header oHeader = new TemplateContainer_Header(this, this.oChannel);
this.Controls.Add(oHeader);
tHeader.InstantiateIn(oHeader);
}


I NEVER EVER would have guessed that Serialization of a control is affected by something so LATE in the lifespan of a control (Render), and would not have found it, except for a nudge in the right direction from Peter Bromberg when he wrote with:

"Are you overriding CreateChildControls to instantiate your templates within the container? "

At the time, I thought he hadn't read my message correctly...but in essence, he was right on. Check the lifespan of the control in terms of rendering is the message of the day...Can suprise..atleast it did me.







Again, thanks a million for all the help. Lateral thinking/nudging did it. Whew.



Now...How can I go back and cover my tracks by changing all my posts to say, "Posted by John Jay Jr." ...

Great that you found the answer. I was going to look for the cause of the problem once you confirmed my understanding of your problem.

To take a closer look at what was triggering off the setting of the variables: in the design time, the following events are fired in order.

* constructor
* Render

Inbetween that, the designer is listening to any changes in variables when it calls the Render part (not the constructor). Once it detects a change, it would think that your code is trying to place a default value onto that property. Hence, writing your changes to the serialization.

---

-- Justin Lovell

Hi Justin:
(PS: Have enjoyed reading your blog in the past :-) )
Thanks for the info on IDE lifespan. Pretty short!
I've been trying some wierd variations with the above info, out of perverse curiosity...
My latest dumb idea was to see what would happen if I made a control that has a sub-control as a property.
I'm talking about:

Calendar : WebControl {


public CalendarMonth Month {...}}


}





CalendarMonth : WebControl {


}

"Eh?!? Why?!?!" You ask... beats me :-) I just wanted to see...
Actually the reason was that I was wondering if I could use a 'dummy' object to store variables for a MonthView, and in Render, use the vars from the dummy to make a real one to Render.
This would save me time since I would not have to create a whole set of properties just to hold the same vars that i will later push to the child control...
In other words, I'm lazy.

In fact, in Render(), one can do:

 Controls.Add (this.Month); 

since its both a property accessible via a this. and a control derived from webcontrol...
Note: One of course has to attach ExpandableObject attr to CalendarMonth, first or you wont see it in the properties panel of the IDE.

Result? Madness
Well. Interesting behaviour happens. Not enough works to be useful...but It ALMOST works for the moment... I just can't decide yet if it has a chance of being useful, rather than just an excercise in pissing off the IDE. Things to think about and resolve:

a) No Clone
The above works correctly for a single month view -- but fails to be useful/intuitive when dealing with a Year view:

for (int i=0;i<12;i++){Controls.Add(new Month.Clone());....

Except that there is no Clone method to get around using an instantiated control twice or more...
Have an ideas how one could do something like this?

b) Who'se the Boss around here?!
Putting one control inside a second one confuses the IDE in terms of who is the boss control, and what is the outer tag. I've noticed that when I change a prop of the child control (CalendarMonth) it flips out at the serialization state and adds them as incorrectly xml'ed properties in the parent property!

c) Need more insight in Site...
Oh. I nearly forgot....the reason I brought this all up is that I ran into something else that was wierd.
In a normal (or parent control) I can use:

 if (this.Site) && (this.Site.DesignMode){try {this.Render(EventArgs.Empty);}catch{}}

to force a fake PreRender event. But guess what...in a child control, the Site object == null. Eh? Wierd behavior all around.

I know, I know:
Why do I do these things rather than leave them alone.......
....And what does one respond to a post from such an obviously insane person?

Sky


PS: This < code > tag is nice -- but way to much margin top and bottom.

:: Have enjoyed reading your blog in the past

Thanks... I think ;-) . Ermm... the keyword (and the tense) that you used "was" -- past tense. I don't like that: <grinning>what did I do wrong (or currently doing wrong) for you not to read it anymore?</grinning>. Actually, answer that with a serious one.

Time to answer the questions before I dive back into Pascal :-) .

With the clone method, you can get it. Implement the IClonable interface (spelling error there... I think) and then set it up like if you created duplicates of the Month manually inside the Clone method.

However, I do not like that solution that you proposed to that problem because a Month is generical. For example, there are 12 months in a year which all have different structures -- first day of month, number of days, days of day number falling on different day names (Monday for instance), ect...

But why am I getting the feeling that you just made this as a mock up example for another one ;-) ? If your real-life problem is like the above example, then this is where you will have to create styles and/or templates for the "output" of the months to the UI. The data will be "generic"

Problem B: You can disable serialization. I **think** (and sure) that the member you are looking for is Hidden (I just can't remember the field name... too much time with Pascal).

Oh yes, before I forget! Don't put controls into the life cycle during the Render stage. Why? Your controls will not function correctly because it won't step through into the life cycle of Init, Load, PreRender -- it will go to straight rendering.

:: to force a fake PreRender event. But guess what...in a child control, the Site object == null. Eh? Wierd behavior all around.

<callingToTheDistance>Andrew! Andrew!</callingToTheDistance> Things like this, is what can be avoided with the checking of HttpContext.Current. If it is null... yip, you guessed: the chances of chances of you being in design view is 99.9%.

---

-- Justin Lovell

Ha!

About your blog :-) About 12 months ago, (maybe less?) when I first looked at C#, and articles out there, I would find out that they were written by this wierd guy who seemed to know what he was doing... so I read his blog. At the time, I didn't understand everything.

Then I got really pissed off with ASP.NET because I was taking 10 times longer to write anything in it than PHP, and I had to go back to making money -- so I stopped making or reading anything about ASP.NET...Hence the past tense...

Then about a month ago, I got back into it, and ...this time, things are going a bit better. ...
And because I am reading again...I'm sure going to end up reading articles posted by that wierd guy again :-) PS: Good luck with the exams. And I liked the gear box. Reminds me of my days drafting in college. Miss it a lot (studied architecture).

Back to the point: I'm just pretty desperate to get a couple of key concepts out of the way before I charge. I really WANT to use ASP.NET -- I like the modular approach/promise -- I just get disappointed some times.

Right now, I am trying to figure out how to create Controls that I can make for others -- that include graphics in the package as resourcses, are styleable, and are whereever possible, Template based. That's all.

You would think that, considing what is written on the outside of the ASP.NET box "It's all possible, it's all RAD, you'll love it!" that I should have figured out how to do it. But not.
I am still pulling my hair out on some dumb things:

b) Styleing (other thread started yesterday, but not going very well...)
a) Modular construction of controls (as we are now discussing on this thread) rather than one big one...
c) Embedded resources -- I havn't posted about that one...
d) Any chance what so ever of rendering a CalendarMonth based on templates -- but allow the TemplateCreator to embed Event causing controls (thread not started on that one).


So far, this research has gone pretty terribly...

BTW: Since I'm pretty new around here...Who is Andrew?

I agree -- HttpContext.Current is turning out to be a better check than Site object.

As for the IClone, saw that -- but I think that using reflection to carry over the properties is ... fine for classic objects...it's just that with Controls, that could be much more dangerous (for example -- although not the case we are discussing -- cloning a control that is on the page, to another object, would clone across ChildControlsCreated -- even though in the second control, EnsureChildControls has not been called by anyone...) so I am wary of IClone... I thought that maybe Serialization of a class, to rehydrate another was -- rough -- but maybe better? Doubt it: bet it is based on the same Reflection/enumuration of properties...and not events.

Waoh.... As for duplicating the CalendarMonth control -- I think this would duplicate the Date, and the Styles to show it -- but FirstDayOfMonth, etc. would be Properties/Methods....



Very best,
Sky

Strike the paragraph about Andrew -- didn't connect the dots...
Oops! <Embarrased>

::

Don't be embarassed :-) . Here is the discussion I was in reference to:

http://www.asp.net/Forums/ShowPost.aspx?tabindex=1&PostID=662940

The conversation was something like:

Andrew: Use Site property to detect when you are in design-view.
Justin: (In reference to the original code submitted) Here is a better way to use the HttpContext...
Andrew: Don't you trust Site?
Justin: Maybe ;-) . I was in reference to how the actual code was written.
Andrew: Oh... just seems that you love pushing the HttpContext.Current == null way.
Justin: To justify the maybe -- sometimes, the Site property is not a true reflection. There is also OTHER reasons I use HttpContext.Current == null.

....

I see that you have spurred up the other threads for your other issues. On Friday, I will be able to offer my assistance. I am trying to get a final milestone written and out of the window by tomorrow :-) .

---

-- Justin Lovell

The Site property has it's odd moments, such as in the templates of a datagrid.
On the design surface, they render as they would at runtime Site is null or not DesignMode, but if you switch to templated editing mode DesignMode is true again.

If whats important is the HttpContext, and in a lot of controls I've seen it is what is important, you should be checking it. And definitely the HttpContext.Current == null way

:)