JohnsHandle

"ASP.NET is compiled on the server, so to answer your question, no, you can't." and JavaScript can not do this either as it'd be a serious security hole. What you could do. page1 opens page2 (page1 remains open also) page2 does some work, posts back to the server and stores the information in the session, then closes itself(page2) page1 uses refresh or AJAX to check for updated status on the server. page1 then refreshes itself etc. Maybe a wizard control would be easier?

You should be able to use frames in asp.net the same way you use them in 'HTML'. What error do you have? If you are using frames for layout you can use table or divs to handle the layout and you should take a look at master pages.

I first though one click also. I think I'd probably go with a download client. I foresee problems monitoring the downloads, completed, timeouts, disconnects etc. I'd imagine you'd need something on the client sending its status to the server. This client would then be able to show that the user is queued and where they are in the queue. I think maintaining a queue and reporting a user�s position using ASP should be very doable. You could then also have a "current downloading" list and if anyone tried to download without being in the list you can redirect to the queue page. The queue page I think would use AJAX to poll a web service which returns their position or redirects them to the download when it's available. I just don't know how you would get the queue to update correctly with downloads, which is probably the information you were after :)

You shouldn't need to refresh the page when using JavaScript. Labels render as text within a div or span so you need to set the innerHTML directly. Try somthing like: var control = document.getElementById("labelID"); control.innerHTML = sender.value;

I feel sorry for you sounds like a bad requirement. Has she forgotten the name of the file she picked a second ago :) I don't know if option A is possible for option B though you can use the onchange event for the control and have some JS populate a label or something. <script language="javascript" type="text/javascript"> function test(sender, args) { alert(sender.value); } </script> <asp:FileUpload ID="FileUpload1" runat="server" onchange="test(this)"/>

The blogs tend to rather specific look at small aspects of the .net framework. I follow a few asp.net ones: Scott Guthrie is one to watch for the latest developments http://weblogs.asp.net/Scottgu/ Also take a look at the community link on http://www.asp.net a few blogs there.

Like PlausiblyDamp says you can capture the session end event in the global.aspx page. public class Global : System.Web.HttpApplication { .... protected void Session_End(object sender, EventArgs e) { //tidy up code } }

(Session["CustomSessionId"] == null) Will never be true. If your session expires it will just create a new one the next time the user makes a request. You Session_Start event will fire and set the value again right away. It looks like you want the user to login again when the session expires so you should be setting the Session["CustomSessionId"] when the user authenticates.

What have you done in page load? Does it similar to this: if(!IsPostback) { rbShowWearersAll.Checked = true; }

Interesting problem you found. :) It doesn't set the onclick event to the checked radio button like you say. This makes sense as clicking on the selected radiobutton isn't a change event so shouldn't cause a postback. However, as you are using the update panel you prevent a full postback and only the content inside the update panel is updated. This means your radio buttons will not be rerendered and remain in the initial state which is now wrong. Obviously you have a solution that works but you could also move the radiobuttons inside the update panel to fix it. Anyway thanks for finding this.

I think that maybe the problem. Writing files to the server is not something that is normally allowed. On your local machine are you using "http://localhost"? because this behaves differently to remote access and has more trust. Which would explain why it works locally. If you are, try accessing it remotely on your XP machine and see if this will reproduce the error.

If you are dealing with dynamically created controls you need to be aware of the life cycle of the page to make sure the state gets persisted. Do an image search for "ASP.Net page lifecycle", a must have resource for asp.net programmer. You'll see the state is persisted between OnInit and Load. Therefore, for you checkbox to have the state set automgically you'll need to create it in OnInit and then you can access the value after the Load event. I suspect that's your problem but you haven't shown when or how you are getting the value. Alternatively you can get it yourself from the request if you know the client ID of the control. string value = Context.Request.Form["clientId"];

If it works in IE and not in Firefox you can be almost certain it's a JavaScript problem and not a problem in the server side code. If you have written your own Javascript that's most likely where the problem is. If you haven't written any JavaScript it could be a bug in the the update panel and I think you best bet is asking in http://www.asp.net forums.

The idea of encrypting the URL to prevent the user modifying is as Nate says is security through obscurity and any links in your website that accidently exposed the real argument names would render it completely useless. If you really need security for you site I think you�d have to use asp.net security and authorisation. You�ll find it a lot more secure and well supported. If you only want to store some information in the page that users can not alter or see then the view state would be the ideal candidate for this, which is encrypted by default. @Nate. HTTPs wouldn�t prevent the client altering the URL/Form values. It would only stop a 3rd party getting access to it. I �think� in this case rfazendeiro doesn�t trust his users.

If you need to protected the data the user enters than I think Nate Bross is right. HTTPS is your best bet. Any sort of client side code to encrypt it before posting the form is going to be easy to reverse engineer. Could you explain more about what you are trying to encrypt as I don�t understand how you can be using a HttpModule to encrypt the query string before submitting the form.