HtmlImage

[David]

I have been trying to use an HtmlImage inside a Panel in an ASP.NET
application. I discovered that text dynamically generated by the client
persists inside the Panel across round trips but HtmlImage controls do not.
However the ListItem controls I used dynamically generated by the server and
added to a drop-down list box do persist across round trips automatically.
I also found that some of the HtmlImage control can be made to persist by
placing it in the Session. However, this is only true of parts of the
control. The Src attribute would not Stay defined in the Session object
across round trips. The ID an several other attributes were maintained in
the Session.

After spending all this time finding out what works and what appears not to
I am unable to resist the temptation of actually using the HtmlImage control
unaware of other surprises that may be in store. Considering what little I
have been able to get it to do I would have saved much time writing my own
control.

Is there any rhyme or reason to the behavior of these HtmlControls? Is there
a reason for this behavior or do they just have bugs?

Signed,
Confused and Bewildered

 

[Kevin Spencer]

A Server Control is a class that renders HTML. It resides on the server, and
is not persisted across PostBacks. What *is* persisted is (in many cases)
the HTML it renders. It all depends on how the Server Control was created to
use ViewState for persistence. Controls that are inside other Controls are
not HTML, but Server Controls themselves, classes on the server. If you add
one to another Control, it is not persisted, because it isn't part of that
Control's HTML. List Items are not really persisted across PostBacks. They
render <option> tags in an HTML <select> object (the ListBox creates this),
and the options, which are part of the HTML rendered by the server-side
Controls, is persisted by design.

Everything in an ASPX page is destroyed when the Page is sent back to the
client, because HTTP is stateless. There is a complex mechanism that
re-creates it after a PostBack, by looking at the hidden ViewState form
field, and the values of the form fields returned with the POST Request.
Again, only that HTML data that belongs to a Control, and is persisted in
ViewState, is re-created when the Page Posts Back.

If you understand how ASP.Net works, you are less likely to be surprised,
and know what to do, and when. Controls that are dynamically added to a Page
by code during one Request must also be dynamically added during subsequent
Requests, or they will not be there. The Page template contains code that
indicates what Controls are *always* present in the Page; anything else is
purely under your control.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

 

[David]

Thank you very much for the reply. I have one clarification and one
question.

Everything in an ASPX page is destroyed when the Page is sent back to the
client, because HTTP is stateless. There is a complex mechanism that
re-creates it after a PostBack, by looking at the hidden ViewState form
field, and the values of the form fields returned with the POST Request.
Again, only that HTML data that belongs to a Control, and is persisted in
ViewState, is re-created when the Page Posts Back.

When the HtmlImage control is placed into the Session object the ID, the
Style and the client side event handlers persist across round trips. The
Src attribute does not. It seems strange that there should be just one
exception. I suspect there is a problem with the code that generates the
"ViewState", that is, a BUG. I had to write the code myself to store that
value in a hidden while the server lets the client take over.

If you understand how ASP.Net works, you are less likely to be surprised,
and know what to do, and when. Controls that are dynamically added to a
Page by code during one Request must also be dynamically added during
subsequent Requests, or they will not be there. The Page template contains
code that indicates what Controls are *always* present in the Page;
anything else is purely under your control.

Page template? I'll have to look into that. Thank you.