We have created some dynamic web image controls. At design time we use
System.Web.UI.Design.ControlDesigner.OnPaint to draw our control directly to
the design surface. This saves us from having to create temporary images on
the file system.
The problem is when our controls are placed inside a template control like
FormView. The OnPaint method is not called so our controls appear as broken
images. Any work around for this?
As for the Custom ControlDesigner's "OnPaint" issue, I've also noticed
this when we adding such control in a template container. The design-time
content of the control in it. The design-time UI methods such as "OnPaint"
or "GetDesigntimeHtml" will not quite work in "Itemtemplate"(normal display
After discussing with some production engineers, we've got the following
reason on this behavior:
Controls inside templates (when NOT in template editing mode) render using
their runtime behavior. For example, a radiobutton with no text renders as
just a little circle without any additional text. This is because they are
merely child controls of their container and have no ControlDesigner
associated with them, so there is no GetDesignTimeHtml being called for
them (are you seeing otherwise?). By not rendering the [RadioButton1] text
I'd say you're getting a better WYSIWYG rendering of the control.
Therefore, when we put the control in GridView or Repeater or FormView's
ItemTemplate, the control it self is no longer considered in design mode(it
is just a inner html element of the super control), only the container
control (GridView or Repeater or FormView) is considered in design-mode and
will utilize the controldesigner features.
Hope this helps clarify this.
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
This seems nice in theory, but in reality it doesn't work well. When you say
the control "renders using their runtime behavior" this is only partially
true. Yes, while it is true that GetDesignTimeHtml and OnPaint methods are
only executed in edit template mode, when not in edit mode, however, the
Control.Context is null while at real runtime it is not null. This makes it
impossible for us to show a valid image.
You see, during real runtime we cache the image generated in the ASP.NET
cache using the Control.Context property. The image URL we send to the client
points to a custom HttpHandler which ends up resolving the image when the
browser asks for it. All of this functionality does not work at design time
at all because the Control.Context is always null. In order to get our image
to show up in "non edit mode", we would have to create temporary images on
the users system. This is not good. We were doing that for a breaf time,
before shipping, but when 2.0 came out the ControlDesigner.OnPaint method was
godsent. At least partially, because now Microsoft is telling us we don't
call it in certain scenarios and that is by design.
Well, the fact remains that the Context is null and Microsoft is not calling
OnPaint so what are we going to do? It looks buggy to our users to have a
broken image at design time.
Thanks for the reply Breeve,
Yes, the "renders using their runtime behavior" here just means the control
in template control's ItemTemplate won't utilize those design-time service
(getdesigntimhtml or Onpaint ...) to render design-time surface. And I can
fully understand the pain in your case since you'll need to display an
image file here.
Based on my research, it seems this limitation hasn't been added into
formal plans for next version. However, I would recommend you submit this
request on our product feedback center so that our product team can hear
more on this: