Opening new window

[eramgarden]

I have 3 radiobuttons, and an "OK" asp:button.

When second radiobutton is clicked, i want to open a new window ( a new aspx) page.

Anyone with an example on how to do this?

 

[PWNettle]

I have 3 radiobuttons, and an "OK" asp:button.

When second radiobutton is clicked, i want to open a new window ( a new aspx) page.

Anyone with an example on how to do this?

I think the only way to open a new window from the browser is with client-side javascript. Even if there is some way to do it in code behind it almost certainly generates client-side javascript for you to do the same.

Simple javascript to open a new window:

window.open('yoururlhere.aspx', null, '');

You cause javascript like that to fire by using javascript events for HTML elements (an ASP:CheckBox is rendered as an Html input of type 'checkbox') - perhaps by sticking that script into the 'onclick' event for your ASP:CheckBox:

<asp:checkbox id="chkTest" onclick="window.open('yoururlhere.aspx', null, '');" text="Click Me!" runat="server" />

You'd need to put that into the raw html of your ASPX. I don't think you can add javascript event text in the WYSIWYG editor, but I'm not positive since I don't use it.

If you have a click handler for your checkbox in your code behind you could have it generate and register a script block that would fire after the postback when your page displays again. Generating the script would go like:

//  C#
string sScript = "<script language=javascript>";
sScript += "window.open('yoururlhere.aspx', null, '');";
sScript += "</script>";
Page.RegisterStartupScript("blah", sScript);

I try to avoid doing postbacks unless they're truly necessary. IMO, something like opening a new window, which can only be done with client-side script (or on a link that has a target="_new" attribute), should be done purely on the client side (unless there is critical code-behind processing that must occur to build up the URL you want to open).

Paul

 

[eramgarden]

Thanks Paul.

The second solution works but the first one doesnt. There's no onClick event for asp:checkbox or asp:radiobutton.

 

[Arch4ngel]

in Page_Load... you could do this :

// C#
YourControl.Attribues.Add("OnClick", "Your Client Side Script");

With this... client-side script will be added dynamicly.

 

[PWNettle]

Thanks Paul.

The second solution works but the first one doesnt. There's no onClick event for asp:checkbox or asp:radiobutton.

Well, the "onclick" event is actually a javascript event, not a .Net event. .Net will render the 'onclick' event as part of the html it creates even though it claims to not recognize it. The key thing here is that if your client-side script is static then you might as well just include it in the aspx as a javascript event. If you need to do some processing (that can't easily be done in yet more client-side javascript) then using postback process (which you ended up using) is a better option. Anyways...it works for you which is the important thing.

in Page_Load... you could do this :

// C#
YourControl.Attribues.Add("OnClick", "Your Client Side Script");

Yeah, I use this too to add javascript events to my .Net controls if I need to do some codebehind processing involved with the event. It's a nice little trick (since MS doesn't explicitly give us a way to add javascript events to controls, like a JSEvents collection *grin*). Usually I would use this for the initial control creation though, not necessarily in reaction to a click that's being handled in a postback - although situations do vary.

Paul

 

[Arch4ngel]

YourControl.Attributes refer to HTML attributes. So the OnClick will work.

Even if it's not an .NET event... you want to open a window... don't have to bother with that.

Some processing might be done in the Page_Load (like linking the OnClick to the correct page or something).

However ... you're right on process in the onclick... server-side must be used.

 

[PWNettle]

YourControl.Attributes refer to HTML attributes. So the OnClick will work.

onclick is a javascript event handler, not an attribute per se. Whatever you stick in the 'yourControl.Attributes' collection gets rendered as an attribute of the html element and it just so happens that javascript events follow the same 'name=value' format as html attributes - so using the Attributes to setup dynamic javascript events from codebehind works out well. .Net doesn't care what you stick in the Attributes collection - it just renders into the html tag.

However ... you're right on process in the onclick... server-side must be used.

As long as the javascript event you want to add doesn't conflict with a like-named .Net event (like, onclick for a button for ex) you can just plop the javascript event in the declaration of your ASP.Net control.

The example I posted earlier:

<asp:checkbox id="chkTest" onclick="window.open('yoururlhere.aspx', null, '');" text="Click Me!" runat="server" />

...will properly render the javascript onclick event in the checkbox tag. There's nothing wrong with setting up your javascript events from codebehind but it's not necessary - and since your codebehind is compiled and your aspx is not - it can be easier to maintain/change a piece of static script if it's in the aspx and not in the code behind. The only times I personally generate my javascript for tags in codebehind is when my javascript event is dependent on codebehind processing (maybe I need a database ID stuck on a URL or something) or if the javascript event name conflicts with and confuses the ASP.Net control events (like the 'onclick' of a button or something).

/begin rambling/ranting

I kind of find it annoying that ASP.Net doesn't expose the javascript events via intellisense and provide a way to distinguish between client-side (javascript) and server-side event handlers, like in the case of the button's onclick event. Postback processing is cool for a lot of things but to make a robust web app you're still going to use a lot of dhtml/javascript. It's ridiculous to think that you'd do a postback for every little page change or event response - that's just not practical for commercial internet-based apps - clients don't want to be waiting for 20 posts per page. Not to mention that the client-side validators use javascript. Hopefully this is something that'll be straightened out in .Net 2005, which is supposedly gonna have better web design support.

/end rambling/ranting

Paul