M
magister
I am a asp.old programmer who after a year of .net is still trying to
learn not to use querystrings and form values, and instead always rely
on server events....
Thing is in the old days I got alot of milage out of the iframe, it
give you alot of flexibility to load different parts of the screen
with functionality. For instance you can set the meta tag refresh for
the iframe so the whole page doesn't lose its state but only one part
of the page updates.....
I would think this sort of things is what other developers who were
around back then are missing. It is ok loading an iframe in an
asp.net page using HtmlGenericControl and putting the runat="server"
and then loading attributes.add("src","iframe.aspx")..no problem, but
what if you want to make the parent page aware of a change. Posting
querystrings to the parent is out becuase of the asp.net server events
and state, each querystring load is considered a fresh page load and
you start at your pages beginning.....
So far I have got to the point where I put a hidden linkbutton into
the parent and get the button or linkbutton in the iframe to envoke
the __doPostBack javascript of the parent....this fools the page into
thinking the hidden linkbutton has done some work, thus page state is
perserved, and isPostBack is true...
Here is a quick summary of what I am doing
WebForm1.aspx (maybe a button, listbox, other controls)
WebUsercontrol.aspx( this contains an <iframe id=iframe1 runat=server>
and a <asp:linkbutton id="LinkButton1"
style="DISPLAY: none"
-you can set the src of the iframe in the page view or in
code behind
page_load method or your own show() method
-linkbutton style="display:none" makes sure the __doPostBack
method
gets written
IFrame.aspx ( this is the iframe which could be a datagrid with
command items
in it, linkbuttons, stuff to postback)
-here we do an
Attributes.Add("onclick","doiframesubmit()");
-and some javascript in the page
function doiframesubmit()
{ parent.execScript("__doPostBack('Iframecontainer1$LinkButton1','8989897')","JavaScript");
}
back in webUserControl we have the linkbutton method which makes a
call to the parent page.....
private void LinkButton1_Command(object sender,
System.Web.UI.WebControls.CommandEventArgs e)
{ Response.Write(sender.ToString()+e.CommandName.ToString()+e.CommandArgument.ToString());
((WebForm)this.Page).helloworld(e.CommandArgument.ToString()+Request.Form["__EVENTARGUMENT"].ToString());
}
now this is the first question, why does e.CommandArgument.ToString()
have the value of my link button and not that of the
Request.Form["__EVENTARGUMENT"].ToString() coming from my iframe
javascript...
Does it get these values from viewstate I cannot see them in the
linkbutton html output on the page???
Can I override CommandEventArgs in anyway....
In fact why do I need to do all this sneaking around to do something
as simple as making 2 classes respond to each other...I would really
like to make this into a user control, but I draw a blank as to how to
proceed. Can anyone point me in the right direction on this, or am I
hopelessly stuck in the past....
Thanks
learn not to use querystrings and form values, and instead always rely
on server events....
Thing is in the old days I got alot of milage out of the iframe, it
give you alot of flexibility to load different parts of the screen
with functionality. For instance you can set the meta tag refresh for
the iframe so the whole page doesn't lose its state but only one part
of the page updates.....
I would think this sort of things is what other developers who were
around back then are missing. It is ok loading an iframe in an
asp.net page using HtmlGenericControl and putting the runat="server"
and then loading attributes.add("src","iframe.aspx")..no problem, but
what if you want to make the parent page aware of a change. Posting
querystrings to the parent is out becuase of the asp.net server events
and state, each querystring load is considered a fresh page load and
you start at your pages beginning.....
So far I have got to the point where I put a hidden linkbutton into
the parent and get the button or linkbutton in the iframe to envoke
the __doPostBack javascript of the parent....this fools the page into
thinking the hidden linkbutton has done some work, thus page state is
perserved, and isPostBack is true...
Here is a quick summary of what I am doing
WebForm1.aspx (maybe a button, listbox, other controls)
WebUsercontrol.aspx( this contains an <iframe id=iframe1 runat=server>
and a <asp:linkbutton id="LinkButton1"
style="DISPLAY: none"
-you can set the src of the iframe in the page view or in
code behind
page_load method or your own show() method
-linkbutton style="display:none" makes sure the __doPostBack
method
gets written
IFrame.aspx ( this is the iframe which could be a datagrid with
command items
in it, linkbuttons, stuff to postback)
-here we do an
Attributes.Add("onclick","doiframesubmit()");
-and some javascript in the page
function doiframesubmit()
{ parent.execScript("__doPostBack('Iframecontainer1$LinkButton1','8989897')","JavaScript");
}
back in webUserControl we have the linkbutton method which makes a
call to the parent page.....
private void LinkButton1_Command(object sender,
System.Web.UI.WebControls.CommandEventArgs e)
{ Response.Write(sender.ToString()+e.CommandName.ToString()+e.CommandArgument.ToString());
((WebForm)this.Page).helloworld(e.CommandArgument.ToString()+Request.Form["__EVENTARGUMENT"].ToString());
}
now this is the first question, why does e.CommandArgument.ToString()
have the value of my link button and not that of the
Request.Form["__EVENTARGUMENT"].ToString() coming from my iframe
javascript...
Does it get these values from viewstate I cannot see them in the
linkbutton html output on the page???
Can I override CommandEventArgs in anyway....
In fact why do I need to do all this sneaking around to do something
as simple as making 2 classes respond to each other...I would really
like to make this into a user control, but I draw a blank as to how to
proceed. Can anyone point me in the right direction on this, or am I
hopelessly stuck in the past....
Thanks