I found that you can send information from another page to another with
"Server.Transfer" and load it from second page which "Context.Handler"
(
http://msdn.microsoft.com/library/de...weenpages.asp).
Becouse it's possible to set forms target attribute to
another frame (in my case Bottom), in my mind came, that it possible to
send page´s information there and load right page with Server.Transfer
to that frame with previous page´s information. But, read below..
Hermit Dave wrote:
well your workmate got it wrong bigtime :)
working with frames is not any easy.. infact the change in programming model
actually makes it difficult to use the old asp techniques.
you still can use javascript to do the dirty work for you. but i would
suggest that you stay away from frames if possible.
That I was thinking. It's a matter of course, but is there any source
for this fact, maybe in MSDN?
if you want to use frames then consider using iframes yes you can have
horizontal / vertical scrollbars with iframe you do have work arounds but again you will have to resort to javascript.
I don't want to use frames but scrollbars without frames. But I found
that I can use CSS for it (overflow: auto) or ASP.Net server control
Panel which becomes div-tag in HTML-code. you can still use session to ferry the data around but it still isnt the
best way.
consider using user controls. with user controls it belongs to the parent
aspx on to which you drop the control.
I need to use some user controls in many pages so them state wouldn't
last to all these pages (?), so I must use Session-variables
then. If browser feels the need for parent to have scrollbars it will set it (unless you opened the page in custom
window using window.open())
I haven't noticed that importing user control to a page would check that
fits some place (it by the way haven't got properties to set its size
but it´s auto-align)whereit to space. However we can of course put User
control into a panel (or better put it inside a panel and let it decide
its sizes) and set scrollbars for it.
Patrice wrote: As a side note he may talk of user controls or master pages both
allowing to "pack" a part of a page so that it can be reused at will
on multiple pages, simulating in a sense the benefit of frames...
As you pointed, ASP.NET is anyway just a programming model and just
uses "classic" HTML...
Might be..but he misunterstood how _real_ frames works still in ASP.Net.
User controls are indeed very good alternatives for frames. I think only
when we have a lot data loaded rarely in a certain place of the page,
frames may be better than user controls..
By the way, I am doing an online shop application which includes a
shopping cart. In the bottom the page I have information what belongs to
the shopping cart at the current moment. In left there is list of
product groups. When user selects product group, page loads product list
to the left side of center area. When user selects product, it's
information shows at the of right side the list and center area. This is
pretty much given thing..
If I keep the shopping cart in a separate frame in the bottom of the
page and want updates its information from another frame, I
need to have form´s target attribute "Bottom" (read above). But it's
very much given to me that I must put product list and product into the
same page, not in separate pages. So this causes problem because product
list must send form from browser back to the same page and load it in
the same target frame. But product info form must change the shopping
cart frame´s state when user adds a product, so then forms target
attribute must be "Bottom". So I need two form-tags, another without
target-attribute and another set it to "Bottom". But ASP.Net´s
limitation and the way to handle forms restricts me to use only one form
tag per page..
One solution would be to use client scripting in the button which
changes the shopping cart frame´s information inside it (?Refresh=1).
But I wouldn' like to use client scripting in this project.
I am becoming persuaded that I would use CSS positioning for the
shopping cart which is located in the bottom of the page. There are some
problems but it seems to work in new and nowdays common browsers (which
presumably will be target browsers of users) (and I get away from tables).
Bottom-frame in online shop applications seems fairly common, but that
its common isn't merely reasonable reason for using it. About body´s
style "height: 100%" (and div´s style "bottom: 0"): "People seem to
think this is a very difficult problem, but it isn't." (source:
http://www.quirksmode.org/css/100percheight.html). What do you others
think about this?
