Here's a fun problem. The page in question is wizard like page. here's the scenario-
User clicks on a link button to get to step 2 of the wizard. (The post back can't be avoided. URL based navigation isn't an option.)
User clicks on a radio button/link button/any control that requires a postback for client-server interaction.
The page reloads as if nothing happens.
User repeats step 2. Things work fine.
What I do is this -
I have just one page for all steps of the wizard. Based on the step, the appropiate control is loaded into the page. This control is added to a placeholder control in the OnLoad event. Doing so in OnInit or OnPreRender doesn't work. This step of adding introduces the odd behaviour I've described above.
Any ideas?
Since you're adding controls to your page at runtime to get the wizard to appear on one page, I think this is a simple matter of rearranging some of your code.
Refer to this article at CodeProject - specifically the section that discusses viewstate and dynamic controls in the section called - "Walkthrough 6: Viewstate and Dynamic Controls".
Very simple, you have to re-add control on each postback, re-attach event handlers and give dynamically loaded control same Id.
The application uses a custom control framework. The issue is related to the framework. Had to redesign the approach.
Related
I am creating an ASP.NET application which contains an update panel and adds components to it dynamically at runtime. I will have a button which the user clicks to add new fields to the update panel, however, I face a problem in that server controls can only be added to the update panel in Page_Init or Page_Load methods, and page execution will not reach the button click event handler until after these methods have been executed.
Is there any way that the button click event could be handled before Page_Load (but still after the postback data is available)?
Thank you in advance.
I have not understood what you are actually trying to do. The answer is no. The asp.net lifecycle is specific.
Hope I helped!
I have a solution in ASP.Net 2008 (C#) with:
- A Project with a Composite control (with some buttons and textboxes).
- Another project (application) just to test the control.
I started to test the control inside a page or webform. It had some design time errors
so when I dragged the control to the page it showed the "Error Rendering Control" in design time. I corrected the errors, rebuild the project with the control,
and the control appears fine in design time.
But I added another webform, I dragged the control on it, and the "Error Rendering Control"
appears again. I added another webforms and drag the control on them and that error appears too.
Any help would be appreciated.
Sorry, because I have a lot of code in my composite control, I didn't noticed that I had a .FindControl sentence inside my composite control. I put that senrtence just for testing, but I forgot to delete it from my code.
So the page when it worked fine had the control specified in FindControl, the other pages
had not.
Problem:
I am loading one of several user controls based on a selected tab within RadTabstrip Control which is on the parent page. I've captured the Selected Tab and assigned it to a Session variable within the OnTabClick event to use in each User Control to determine if that particular control needs to be rendered.
The reason for this is because each User Control queries a database to render different charts and I don't want unneccesary processing occuring on every post back to the server. I'd like to add that each User Control has several Labels in their Markup that only gets the Text values assigned during runtime based on the content retrieved from the database.
When I load the main page, the selected tab variable is checked by each User Control and everything works fine from that scope. (The first tab at index 0 has no Charts)
Problem is when I select a Tab which has a User Control, the appropriate code to acquire the data from the database and build the chart works fine but the TEXT value of the Label controls in the Markup don't show up on the Page, although the TEXT values are being set in the Code-Behind at the same time the data is being retreived.
If I perform a Post Back of the same page, the TEXT values of the Label controls appear.
I believe this is because the 1st stages of the Page Life Cycle which include the rendering of the Markup aren't firing on the initial loading of the User Control, but get fired on subsequent Reloads or Refreshes of the Page.
Is there a way to work around this? I am figuring a call to the Render event after hitting the database would work but I may be way off base on my thoughts.
Can anybody provide some advice or a potential solution???
Thanks
I was never able to resolve the late binding issue which prevented the text of the labels from appearing until after a manual refresh of my page so I approached the issue from a different angle. I still retained the logic that only allowed the data of each User Control to get populated if their corresponding Tabs were selected by the user, but I moved the in-line code which was embedded in my Markup to my Code-Behind file.
I was not 100% certain as to the order that the mark-up vs. the code-behind got processed, so I researched and found that anything done declaratively in the aspx page is processed first, and the objects are created before being accessed or updated in the code behind.
So with this information I totally separated the two and was able to get the Text to render on the labels without any issue.
I still would haved liked to have known the appropriate way to force a page to call the Render event to simulate or mimick a manual Postback after the initial Page_Load, but going with the flow of the Page Cycle is the much easier and probably a more preferable way to do things.
One way to approach your problem is to consider use of the "Update Panel". It will allow you to render the entire page and then on an event only refresh the area of the update panel.
Generally I would love this feature for performance reasons but there is a catch. Some browsers (e.g. versions of Safari and Opera) do not render these correctly. Is your application a web application intended for general use by consumers? If so you may need to consider a full page refresh on the same page and pass the user data (unless Opera / other browsers have fixed this shortcoming - I have not tested in in 4 months).
I'm developing a custom URL Rewriter for a ASP.Net 3.5 project. This rewriter is not functionally different than most rewriters out there, the only difference being that the friendly URL collection is not loaded from a web.config file -- it's coming from a database instead. I made the naive assumption that it would be easy to develop a custom rewriter module from scratch, but now I know the mess I put myself in. I digress; let's go straight to the technical issues.
While testing the rewriter, I set up a friendly url that would take the user to a web form. Postbacks from this form should not alter the friendly address, as anyone would expect, so
http://my.web.site/app_root/FriendlyURL is always rewritten as http://my.web.site/app_root/not_friendly/form.aspx
Things are fine when the browser first loads the FriendlyURL. The page comes up and is completely functional. However, when the form is posted back to the server, the page simply reloads but, at server-side, IsPostBack is false. It's like F5 was hit, except that a HTTP POST had indeed occurred.
Unsurprisingly, when the interaction occurs through the "unfriendly" URL, the POST action triggers the postback as expected. This evidence suggests that HttpContext.RewritePath is somehow messing with the page lifecycle in a way that it loses sense of the postback operation. Any directions? Thanks.
Thanks to StackOverflow, another nearly-duplicate problem gave me hints about the core issue. In short,
Server-side components that set the PostBackUrl attribute mess up with path rewriting system during postbacks. Or the postback system is messed up during the path rewrite. (The causal relationship is unclear, but the effect is what I described in the question.)
Any asp:LinkButton, asp:Button or asp:ImageButton that sets PostBackUrl (either at form, master page, or user control levels) will cause web forms to include a __PREVIOUSPAGE hidden element whose contents are opaque, but it has some role during postbacks. This was my problem: there were several asp:LinkButtons that set the PostBackUrl attribute.
When the page (form + master page + user controls) is free of PostBackUrl'd elements, __PREVIOUSPAGE disappears and the postback mess up is gone. So after I reviewed each asp:LinkButton in the entire site, and transformed them into ordinary <a> elements, the problem was solved.
I am using this jQuery context popup menu extension:
http://www.trendskitchens.co.nz/jquery/contextmenu/
This context menu is bound against an ASP.NET treeview adding a context menu to all items.
All contained within an update panel.
In order to select the item when right clicking, I am using JQuery to parse the postback from HREF that would normally fire when the tree item is being clicked, and using eval() against this HREF. This results in a post-back to IIS. Immediately after is my JQuery code for displaying the context menu. The context menu appears briefly however goes as soon as IIS returns the updated page data.
Just after some general advice on how people think is best to approach this. I can avoid this by making users LEFT click the tree node prior to right clicking it, but that just seems unintuitive.
Hey Sam, as far as I see it the whole idea is kind of wrong from the start, I am a .Net developer but I've always avoided introducing an update panel in my applications, if you look behind the curtains you will see that update panels insert a form tag within the application which kind'a runs at server, try to insert two forms with runat server attribute one within the other in a VS see what they say :). To be honest it's fairly easy to build a contextual menu with templates as layout; it's about 3 hour work and several others for testing.
Getting back to your issue. I see that you have two options here: either learn how to open the menu from javascript and retain the position inside a hidden field before postback(on click/open) and after the postback occurs reopen the menu at the desired position/components, either search for the code which actually does the post back and prevent it in your case. Could be a click and if so all you need is an ev.preventDefault(), could be a submit and then you would need to set up a variable and on submit return false or something like that. Can't really give you the actual code solution without seeing the page which has this "bad" behaviour, anyhow left clicking is, as you said, not intuitive and frankly not an option in this case.