Cause a JavaScript Function to run after update (update panel postback)

Hello,

I ran into a problem that im not sure if the Atlas framework addresses.

I need to fire off a javascript function (which is decided server side)on a postback. To do this I am going to be using a hidden input field.(since I already have one on the form I use to send information forserver use.) From the server side, I can place the function names intothe hidden input field. But I can't cause them to run, on each postback.

I suppose that is confusing, let me try something simpler.

1. I fire off a postback in javascript - This is done using the__dopostback() and the server side fires off its if statements and doesits functions based on what has been placed into my hidden input field.(this is all good so far) (if I had to I could use the body's on formload ability to fire off the javascript functions I desire, but thatwont work for the next step, and is really ugly)

2. I include Atlas to make my postback not refresh the whole page. This is done by using UpdatePanels.

3. On the server side I need to somehow tell it to run certainjavascript functions when that postback finishes loading. (so like onpartial page load)

How do I do step 3?<script type="text/javascript">
function AfterPostback()
{
alert("This is where we check the hidden input and run the functions.");
}

function PageRequestManagerPropertyChanged(sender, args)
{
if (args.get_propertyName() == "inPostBack")
{
if (!$object("_PageRequestManager").get_inPostBack())
AfterPostback();
}
}

function pageLoad()
{
$object("_PageRequestManager").propertyChanged.add(PageRequestManagerPropertyChanged);
}
</script
<div>
<atlas:ScriptManagerEnablePartialRendering="true" ID="ScriptManager1" runat="server">
</atlas:ScriptManager>
<atlas:UpdatePanel runat="server" Mode="Conditional" ID="UpdatePanel1">
<ContentTemplate>
<%= DateTime.Now.ToLongTimeString() %>
</ContentTemplate>
<Triggers>
<atlas:ControlEventTrigger ControlID="UpdateTime" EventName="Click"/>
</Triggers>
</atlas:UpdatePanel>
<asp:Button ID="UpdateTime" runat="server" Text="Update Time" />
</div
Thats the solution I rigged up.
Hi,

Thanks for posting your solution. It works very well and solves a whole bunch of missing stuff with AtlasPanels. One problem dough. I had to move the call to JS function pageLoad() to the end of the html file part instead of putting it to body onload event.
Another option for doing this is theUpdateProgressSignup extension.

CascadingDropDown in User Controls

Hi all,

I ran into a problem the other day using CascadingDropDown and I thought I'd share it. It is this:

When using CascadingDropDown within a user control (or a custom control for that matter) you have two options for filling your dropdown list controls:

1. Use a web service method. This apparently (and I could be wrong here) makes it impossible for you to tune your results according to some information stored in the session. So it's fine for "static" data, but not fine for "dynamic" data which may depend on say, the current user.

2. Use a page method. That poses another problem; you don't know on what page your control will run, you can't decouple by using interfaces 'cause the methods the page has to implement need to be static (Shared in VB), so the best I could come up with is define a dummy interface which "reminds" the developer to implement those methods - and of course you need to implement them on every single page you use your user/custom control.

Now both these alternatives are not very appealing. Wouldn't it be better if CascadingDropDown could look in its container for the static methods instead of the Page?

Cheers

In this case,

u can just use normal dropdownlist control make it like cascadingDropDown, then put everything in the updatePanel

I am currently working on a composite control that creates multiple (1-xxx) controls inside of it dynamically (based on XML) one of them being a Cascading Drop Down control.

Once I get it working i'll post here to let you know how I did it.

Hi,

I just posted inanother thread about this issue. I agree it's a problem and think we should try to get it fixed in the Toolkit.

Thanks,
Ted