I have two user controls that sit on a page which determines which should be displayed. The user controls generate some html that is passed into an asp:literal and subsequently manipulated via javascript. It is done this way due to the lack of a suitable control that I am allowed to use on the project.
When a user clicks a view change button, a WebMethod is called on the main page (the one that holds the controls) from the control's javascript. From here, a static method on the control is called. The control then needs to regenerate the html and place it into the asp:literal for the view change to be complete.
My problem is that I am in a static method on the control's page, and have no access to the non-static genorateHtml function. I have tried a singleton pattern with no success (this could have been due to improper implementation). Any ideas on how to make this call? THANKS!
I used to hit similar issues at with one of the projects i worked on. The solution we ended up adopting was implementation of System.Web.UI.ICallbackEventHandler with partial rendering to return just the needed content depending on arguments. ICallbackEventHandler runs in the page lifecycle.
The only trouble we had then was performance issues relative to implementation which posts back the whole form instead of just the arguments you want.
Maybe the best way for you would be through this method in which they render the control from a static method. That would probably suit your needs.
Hope this helps!
Related
I have a single-page site that has an UpdatePanel. Within that UpdatePanel, there are UserControls that are dynamically loaded.
All linking between 'pages' (which are just UserControls) is done by using a WebMethod that changes a Session variable that stores the UserControl to load. The page reloads, with a new UserControl, and everything works great!
The downside to this methodology, however, is that I'm aware that Session variables don't scale well. Too many of them kicking around is not a good thing, so I've heard. I've unsuccessfully attempted to use different methods but not have been able to succeed. I'm looking to set the UserControl to load very early in the Page Lifecycle.
I've tried HttpContext.Current.Items, UserControl public properties and even UserControl HTML injection. It's just a big mess.
Is there a best practice for this type of scenario? Any helpful links or suggestions?
All is much appreciated.
Clarity update
I'm looking to change the UserControl to be loaded by the C# code-behind file through either jQuery method calls or a Webmethod. Session variables work, but don't scale.
I would use localStorage, you can store lots of information like this
localStorage.setItem('var', 'data');
and get the data back like this
var data = localStorage.getItem('var');
I understand that this will causes a page reload (partial or full, depending on how your UpdatePanels are set up)
But,
where in the code I should put it (client or server side)?
which control should I send to the method? Is it must be inside the UpdatePanel?
does this method work only for controls inside update panels?
must the control have a postback capability?
what is the engine behind this? How does this method work, so I could use it properly.
Thanks.
The function call returns a string of executable JavaScript, which you need to write to the client somewhere in your response.
Typically, you're sending your Page (this/Me) unless you have a control that you specifically want to handle the postback (ie, that implements IPostBackEventHandler)
GetPostBackEventReference is not related to UpdatePanels; if you have one, it will handle the postback.
No (see #2)
This makes a postback to the page. If you want it to raise an event when it posts back, you need to implement IPostBackEventHandler, either on your page or on one of your controls.
http://msdn.microsoft.com/en-us/library/ms153112.aspx
In my asp .net C# project I have a page defualt.aspx on which I have placed 2 components.
So in all I have:
1) default.aspx (main page, not doing much code in it)
2) wuc_Lookup.ascx (doing a lot here, grabbing data, setting session, etc)
3) wuc_PageMessages.ascx (has a couple of panels and labels for message output
)
The intent is to use 3) in any page in my application. 1) and 2) are already working. My issue is that the Page_Load sequence is:
1st default Loads
2nd wuc_pageMessage loads
3rd wuc_lookup loads
The problem with this is that The wuc_pageMessage is relevant only after wuc_lookup runs.
My intent was not to put code in Page_Load for the message wuc_pageMessage control because I wanted to be able to call a method to post the message during the component load of wuc_lookup. I do this because only after wuc_lookup do I set the session which I use for the message value.
I actually got values showing up if I put the code in wuc_lookup to manipulate the code-in-front server control (panels and labels) using this.parent.findControl syntax...
But then when I try to rip that code and put it into the code-behind for wuc_pageMessage, and then call the method from the wuc_lookup it has fallen out of scope or context...
So I tried to change this.Parent by passing httpContext.current.handler as casting it as page...that didn't work...then I tried passing Object sender from the calling component...that didn't work either. Neither of them had the Parent property and or it was null which led me to believe that once the wuc_PageMessages.ascx loaded it was a dead deal until a repost happens and that is ugly and something I don't want to do.
I am having some implementation issues and I am not sure what to do. I have been stunk on this for eight hours and Is there just something I am not seeing?
I want to keep away from spagetti code. I don't want to have to scatter code-behind in 3 different files. Theoretically I should only need 2 of these to talk to eachother. i don't want code-behind in default..it's basically just a container. I want to trigger the wuc_pageMessage from wuc_Lookup.ascx without having it be "in" wuc_Lookup.ascx (peer web user controls) I want that to always be a peer relationship. Any advice would be great ...thanks...
Try moving the wuc_PageMessages logic from the page_load to the page_prerender event.
If you are going to use the preRender you would do it on the default.aspx preRender because this event fires after the wuc_lookup. Prerender will not fire on the components for some reason. So yes, this only solves part of the issue. I am not sure how you would get the alreeady loaded component of wuc_PageMessages to get back into scope. If you try to reference components on a component that has already loaded, you will get a null, like they are not there or not in scope anymore... anyone have any ideas?
I get this error when I try to have my C# class change the skin of an asp control:
The 'SkinId' property can only be set in or before the Page_PreInit
event for static controls. For dynamic controls, set the property before
adding it to the Controls collection.
My goal is to provide a panel, call it ID="response", on every page, and then dynamically change it's CSS class from Error to Success, or Success to Error (so it's red or green). And also I make it visible = true, when a response is created.
Apparently, I am forced to use CssClass attribute, which is the only way this will work.
As a side-off-topic note:
In PHP, you would not have a problem of using different "pre-init" "post-init" etc. A completely unnecessary process. You would simply change the html before you send it back to the user. I'm a bit confused why ASP.NET decides to overcomplicate everything. It's a bit silly for me to take time to learn all these different complicated processes to simply display a webpage. It takes time to learn all the quirks written in difficult-to-read ASP life-cycle documents on microsoft. Not to insult any microsoft people, but it's just not practical.
If it is a static control, that is you are defining the Panel in your .aspx page, then the only place to change the SkinId is in the PreInit method e.g.:
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
String panelSkin = ViewState("panelSkin").toString();
panel1.SkinId = panelSkin;
}
Of Course, the PreInit method is only called when the Page is being first Initialized -- not on a PostBack.
You could save the skinId you wanted to use to the ViewState and then call a Response.Redirect("myPage.aspx")... and as seen above grab the skinId string from the ViewState and set the Panel skinId accordingly.
Alternatively, rather than using a Panel try using an UpdatePanel from the .Net Ajax library. Clicking a button in the UpdatePanel (provided it's setup to Trigger an ASyncPostBack) will run the OnPreInit method.
That said, provided you are changing the background, going with the CssClass property would be the most efficient way to do this.
ASP, and its child ASP.NET, is basically a huge hack of vanilla HTML and the IIS page renderer. It hooks into various stages of the lifecycle that already existed in IIS, rather than having its own lifecycle like PHP. As such, there are things you can do in certain areas because the things it depends on either aren't set in stone so you can change them, or are so you can work with them. The great power of ASP.NET, which is the interop with .NET classes and the .NET Framework, IMO makes up for some of its idiosyncracies.
Anyway, Skins are part of Themes, which are loaded early in the process so the controls can be initialized with their proper default Styles. That's the key; the Theme is locked after PreInit, but the Styles (and CssClasses) behind the Skins are editable right up to and including PreRender, which includes event handlers (which fire validation). So, set the Style or the CssClass dynamically.
To do it without a full postback, you can put the controls that should change color in an AJAX UpdatePanel, which can be re-rendered separately from the other elements of the page and will keep its current contents until the DOM is modified via the JavaScript client-side.
Setting the CssClass attribute is much closer to what you'd do with PHP, so why not just do that?
The two real benefits of Skin files are setting defaults for all controls (no skinId at all) or setting properties that can't be controlled with css.
I'm presently in the process of reworking a MultiViewControl based wizard process for our web application. I am having an rough time trying to make sense of the order that events are happening (Page_Load, Init, prerender, etc). Does anyone out there on the interwebs have details on dealing with one of these controls? Please don't just say 'google' it. I've done that and have yet to find a good, comprehensive site yet.
Admittedly, I haven't really elaborated on the problems I'm having with this control, so I'll try to do that:
Primary problem is the initialization of UserControls that live in different Views. In the existing codebase, the programmer was using a combination of multiviewcontrol.ActiveViewIndex = WHATEVER and Response.Redirect("PageWithMultiView.aspx?nextstep") and it made it all very convoluted. My task is to attempt to remove the Response.Redirect calls and use only the setting of the ActiveViewIndex. Is this even possible? Also, there are some cases where I need to initialize a control in a particular view only on the initial load and not on subsequent postbacks. I can use something like the IsPostBack flag but this is only ever set to false on the initial load. Subsequent reloads IsPostBack == true. I basically want to have IsPostBack set to false for the initial load of each View. Can this be done without doing a Response.Redirect to itself?
Hopefully this will make some sense to someone out there.
Thanks.
Greg.
I am having an rough time trying to
make sense of the order that events
are happening (Page_Load, Init,
prerender, etc).
Here you have all details about ASP.NET page lifecycle and events: http://msdn.microsoft.com/en-us/library/ms178472.aspx .
In terms of MultiView - you should NEVER use Response.Redirect when you work with MultiView.
If user can not switch to previous view then you can check previous ActiveViewIndex value before setting it to the new value, e.g.
if (mv.ActiveViewIndex != newIndex)
{
// this view is displayed for the first time
}
If user can switch to the previous views, I suggest to place an information about already used views in session or by placing hidden field on the form with ids of the views that have already been displayed and to use that information instead of IsPostBack.