I'm trying to use ResolveUrl() to set some paths in the code behind of a custom ASP.NET user control. The user control contains a navigation menu. I'm loading it on a page that's loading a master page.
When I call ResolveUrl("~") in my user control it returns "~" instead of the root of the site. When I call it in a page I get the root path as expected. I've stepped through with the debugger and confirmed, ResolveUrl("~") returns "~" in my user control code behind.
Is there some other way I should be calling the function in my user control code behind to get the root path of the site?
look at System.Web.VirtualPathUtility.ToAbsolute.
wonde's comment above led me to the answer --
I was attempting to use ResolveUrl before the control's page load fired. Therefore there was no context page for the function yet.
I moved my code into the page load function and now it's resolving as expected.
Thanks for the nudge in the right direction.
Take a look at this MSDN example. http://msdn.microsoft.com/en-us/library/system.web.ui.control.resolveurl.aspx. and Rick Strahl's Web Log http://www.west-wind.com/Weblog/posts/154812.aspx
I suppose if it works on the page but not the control i guess you could try
this.Page.ResolveUrl("~");
Related
So I have a slightly unorthodox application type.
I have an aspx page called AddNewBlog.aspx. This page generates XML data from database queries and it include the file AddNewBlogXSL.aspx which is an xsl style sheet.
The effect is that the AddNewBlog XML data is transformed by AddNewBlogXSL on the client side into XHTML.
So although the requested page is AddNewBlog.aspx, the layouts and controls and forms are on AddNewBlogXSL.aspx since it contains all the layout and formatting.
When on AddNewBlogXSL.aspx I do an asp:button it tries to post back to AddNewBlogXSL.aspx as is understandable.
The problem is that page is an xslt stylesheet not a webpage.. I need it to post back to AddNewBlog.aspx as this is the proper page which includes AddNewBlogXSL.aspx
The only thing I seem to be able to do is allow the default behaviour which is to submit to AddNewBlogXSL.aspx, process the page, and redirect them to the proper page AddNewBlog.aspx but then it makes it hard to handle error messages and such since I have no control over AddNewBlog.aspx after I have simply redirected to it from AddNewBlogXSL.aspx
Any ideas at all?
You are looking for PostBackUrl property.
<asp:button id="Button2"
text="Post value to another page"
postbackurl="~/Path/To/AddNewBlog.aspx"
runat="Server">
</asp:button>
EDIT:
To address your comment, IsPostBack will not be true in this scenario because it isn't a postback, it's just a post to another page. You have to access the values via the Page.PreviousPage property as outlined in the MSDN article I listed.
During a cross-page postback, the contents of the source page's controls are posted to the target page, and the browser executes an HTTP POST operation (not a GET operation). However, in the target page, the IsPostBack property is false immediately after a cross-page post. Although the behavior is that of a POST, the cross-posting is not a postback to the target page. Therefore, IsPostBack is set to false and the target page can go through its first-time code.
Also per MSDN, you would check the PreviousPage.IsCrossPagePostBack property instead of the Page.IsPostBackProperty
if(PreviousPage.IsCrossPagePostBack == true)
{
//Get values from PreviousPage
text = ((TextBox)PreviousPage.FindControl("TextBox1")).Text;
}
Cross Page Posting Details
I went ahead and wrote a little test harness (aka, I took the example off the MSDN page, :-0 )to verify and results are as follows when cross page posting:
It's not an ideal situation and it kludgey to access your values as listed, but for the model you have designed, it's the best I can think of.
In addition to the above answer, Can you please confirm that the "AutoEventWireUp" is false in this page. If so, override the page load method in this case.
Another issue I have in DNN5:
I'm currently creating a module that shows a GridView that has a "Edit" column.
When user clicks on "Edit" column, it should open an edit form in a new window.
This edit form is an ASPX-page inside my module folder and it expects a ModuleId parameter in order to access the module Settings; that part works fine and I'm able to retrieve the Module settings.
However, I still have the following issues:
How can I localize my Labels? I have tried DNN's label control, but no success. I also tried asp:Label with "meta:resourceKey", but it looks like it isn't able to access the local resource file.
It's very annoying to use Aspx-pages in my module since it will operate outside DotNetNuke's context. Does anybody knows an approach that allows me to use PortalModuleBase?
I have tought about displaying a DotNetNuke page in the new window, just by referencing the Control to load. However when I do that, it will show me the full page (so with navigation bar, footer, and so on) and I actually just want to show the control.
Besides, I'm only able to open my Aspx-page by referencing to /DesktopModules/MyModule/Page.aspx instead of DNN's NavigateUrl or so.
Thanks for your replies.
DNN will hide all other modules on the page whenever a control (or ctl=mycontrol) is specified for the page. So,
You should change your code from an ASPX page to an ASCX control.
Add the ascx control to the Module Controls section of your module's Module Definition.
Use DNN's NavigateURL function to generate the link. You'll want to use one of the options where you specify the Control Key (i.e. NavigateURL("edit", "SkinSrc=[G]" + Globals.QueryStringEncode( DotNetNuke.UI.Skins.SkinInfo.RootSkin + "/" + Globals.glbHostSkinFolder + "/" + "No Skin" ))
In the above sample, "edit" is the control key you specified for the control.
Why not load the edit interface in another ASCX file rather than an ASPX page? Check out http://dnnsimplearticle.codeplex.com for some examples in C#. It's a basic article module, but does a lot of useful things from a DNN perspective.
Mate for localization Aspx-pages operating outside DotNetNuke's context i suggest you to do it programatically. It will give you more control and you can debug it if some problem arises.
Like EfficionDave suggest use Control Key (i.e. NavigateURL("edit", "SkinSrc=[G]" + Globals.QueryStringEncode( DotNetNuke.UI.Skins.SkinInfo.RootSkin + "/" + Globals.glbHostSkinFolder + "/" + "No Skin" )) method
/Adnan Zameer
http://www.adnanzameer.com
I have a pretty simple web-form set up in .Net where I am leveraging jQuery for some of the functionality. I am using the DOMWindow portion for part of the presentation layer.
There is a login form in a div that is set to display:none. When a user clicks a button on the page, it displays the login form. However the .Net button for the login form will not fire it's event when display is set to none. If i take this out, it fires fine. I have also tried using the visibility attribute, but no luck.
the div code is:
<div id="Login" style="display:none;">
The launching code is:
click here to login.<br />
the jQuery code is:
function LaunchLoginWindow() {
$(document).append("#Login");
$.openDOMWindow({
loader: 1,
loaderImagePath: 'animationProcessing.gif',
loaderHeight: 7,
loaderWidth: 8,
windowSourceID: '#Login'
});
}
Any help or explanation that anyone can offer is appreciated.
I noticed i had some code in there defining a client-side function on the Login div. I removed this so as to eliminate it as a possible issue.
I can see in your code that you are appending the div #Login but not setting its style property back to normal like block so. Set it back to block and i am sure it will work
try adding somthing like:
$(document).append("#Login").show();
OK, after playing around with this using firebug, I found the issue: When the jQuery plug-in DOMWindow creates its display layer, it appends to the HTML node of the DOM, which places the control outside the asp.net form tag. Therefore the button and actions associated with it via the DOMWindow are not recognized by .Net. So i edited the DOMWindow source file to append to the DOM form node rather then the html node.
The drawback is that the source has now been customized and will have to be QA'd thoroughly, especially if any further changes are made. But I hope to manage this effectively via commenting in the file.
Hope this helps anyone else who hits this issue.
pbr
I am writing a website with Visual Studio 2008, C# 3.5 and ASP.NET MVC 2. I put the navigation bar in the masterpage.But there is problem that I will not know which button is needed to be highlight(current page) in the navigation bar.
I want get the current page that need to be highlight by masterpage self (not through the content page).And I don't think it is a good way to get the current page by url string.Because I have no idea about the final url is.
So how can I do this?
I guess you could set a ViewData["currentPage"] value in the Action methods, this would allow you to process that ViewData in the Masterpage. That is, however, off the top of my head and I'm sure there's a more elegant way to do this.
When you click the link in the navigation bar (in the master page) that should be triggering a controller action that will decide which view content page will be shown. In that action method you can (as Lazarus suggests) add some data identifying the current page to ViewData that will be picked up by the master page to modify the navigation bar.
I have a menu usercontrol called LeftMenu that has a bulletedlist of linkitems. It's on the ascx page as such:
<asp:BulletedList ID="PublisherList" DisplayMode="LinkButton" OnClick="PublisherList_Click" cssClass="Menu" runat="server"></asp:BulletedList>
I databind the list in the page_load under if(!isPostBack)
I'm having an issue on a page that loads the control. When the page first loads, the event handler fires. However, when the page posts back it no longer fires and in IE8, when I'm debugging, I get "Microsoft JScript runtime error: Object expected" in Visual Studio pointing at "__doPostBack('LeftMenu$PublisherList','0')." In FF I don't get the error, but nothing happens. I'm not loading the control dynamically, it's loaded on the aspx page using:
<%# Register TagPrefix="Standards" TagName="LeftMenu" Src="LeftMenu.ascx" %>
<Standards:LeftMenu ID="LeftMenu" runat="server"/>
Any ideas of where I'm losing the event handler?
I just realized this is happening on another user control I have as well. A text box and a button and I'm using the default button to make sure pressing the enter key uses that button. .Net converts that in the html to:
<div id="SearchBarInclude_SearchBar" onkeypress="javascript:return WebForm_FireDefaultButton(event, 'SearchBarInclude_QuickSearchButton')">
so as soon as i enter a key in the box I get a javascript error at the line saying "object expected." It seems like the two issues are related.
Edit Again: I think I need to clarify. It's not that I'm clicking on the menu item and it can't find the selected item on postback. I have this search page with the left navigation on it and then the main content of the page is something that causes a postback. Everything is fine with this postback. Once that page has been posted back, now if I click on the bulleted list in the left navigation I get a javascript error and it fails. The page_init for the LeftMenu control is never called.
It sounds like you might be losing the click because you are not DataBinding the list on PostBack. Therefore, the post back is trying to refer to a control (a specific bulleted list item) that does not exist.
You should try binding the list again on PostBack just to see if that fixes your issue. BUT, what should REALLY happen is that the LeftMenu and the BulletedList should store their information into ViewState so that you can ensure that the data that was shown to the user on their initial page load is the same data that the PostBack is processing and working with.
If you have EnableViewState=true for your UserControl and all controls within it, everything should work fine. With ViewState enabled, ASP will reinflate your controls from ViewState after Init has fired. This means that the postback event arg (which points to an index in your control list) will still find the control in that list position. Otherwise the list is empty on postback.
However, ViewState is the work of the devil and was designed simply to foster the illusion that you are working in a stateful environment. It is okay to use it for small amounts of data but typically not advisable for templated controls like repeaters and lists because you have no idea how much data is going to be created in ViewState.
If you are dealing with static, or relatively static data, store it in the application cache and rebind your lists in Page.Init every time (note that it has to be in Init because post-init is when ASP rebinds from ViewState; if you get in there first, your data will be used instead).
If you are dealing with volatile data, you have a problem because the data you rebind must be exactly the same as the original page request, otherwise the postback events will be firing against the wrong rows. In that case you need to either store your initial data in Session or you simply store the list of rows ids (in a hidden variable or Session) and you recreate the data to bind against from the ids each time.
An even better solution is to not use postback events at all. Try to turn all your events into GETs that have an ID on the query string. You can still create the list using binding the first time through the page (as you are currently doing), and you can even GET the same page with a new ID.
If you need to keep state on the same page but need to respond to the user changing a radio button selection (or something else), think about using Ajax calls to update the screen. You also do that with an ID that you pass to the Ajax call.
In general, the more you move from using stateful ASP, the lighter and more responsive your pages will become. You will also be in a better position to move to stateless MVC if necessary. You will also save lots of time lost to debugging obscure problems because ViewState is not available when you need it to be.
The best analysis of ViewState I've read is in the link below. If you fully understand how it works, you can continue to use it without necessarily incurring the costs.
http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/truly-understanding-viewstate.aspx
It's possible that this might be javascript related, and that a script that is loading earlier in the page is throwing an error and causing the page to not be loaded properly.
Are your usercontrols loading any javascript onto the page? Can you check for javascript errors on the initial load of the page?
I moved the code into an existing project we have and for some strange reason, I stopped getting the javascript errors and instead got:
"Invalid postback or callback argument. Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%# Page EnableEventValidation="true" %> in a page.
For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation."
I haven't quite figured out where I'm supposed to put the register event validation with a user control, but in the mean time I just set enableeventvalidation=false and it seems to work now.
It looks like the doPostBack function is missing since its arguments are literals so they couldn't be the cause. Is that one of your own functions or did you mean to call the ASP __doPostBack function?
Have a look at the Firefox error console or allow script debugging in IE and see exactly what object can't be found. Even better, download Firebug and debug it.
I had a similar issue. It turned out that Akamai was modifying the user-agent string because an setting was being applied that was not needed.
This meant that some .NET controls did not render __doPostBack code properly. This issue has been blogged here.