Showing posts with label implement. Show all posts
Showing posts with label implement. Show all posts

Wednesday, March 28, 2012

UpdateProgress: how to implement different ones?

hi all. i started exploring the march ctp of atlas today, and i must say i'm really impressed (completely new to ajax/atlas). one thing i can't find out for myself tho...

when using an updateprogress control, is it possible to have multiple, and bind each one to a different callback?
i want to implement kind of a thing like pageflakes.com has; different loading indicators for different parts of the page... the problem is that no matter what i do, if i have more then one updateprogress, they all seem to respond to *any* callback, so i'm seeing multiple progress indicators with no matter which callback i do to my code-behind...

i hope i'm making myself sufficiently clear with this issue :)

in any case, thanks in advance for reading this far!

Yes, currently the UpdateProgress is 'bound' to the PageRequestManager and therefore listens to the async call, regardless of what control is making the call. This is something we are looking into ..


Sorry to duplicate posts, but I made comment of similiar nature in 'performance issues' post:

My controls are flashing on update panels. they turn 'grey' then are filled.

Also - the first callbacks are slower - which gives a pause to the user. This is troublesome. I have a page with 5 update panels. I'd like to have 5 different progress indicators, but all 5 fire at once.

I hope that is fixed.

Most of my use of update panels is used with dropdownlists, and selection of checkbox, etc... where in the past I would have had to postback to have a change. It's super fast locally of course, but when I move it to the server - it's too slow. This will be a problem for others as well, especially with dial up.

I think the development team needs to really investigate ways to let the user know there is activity - a good start would be only firing a progress indicator if it is in the updatepanel being called.

Also - it would help if a setting was available on the progress indicator where it would only show a message if the callback takes 'x' amount of time. This way, if you are on modem, you would get a indicator on a slow connection - however, if you are a on the LAN, there is no need to flash some 'processing' message up if the call only takes 1 second.

I hope this type of discussion is going on when examing solutions.

Thanks


oh ok, thanks a lot for the reply!
Thank god! Hope it'll be released soon.

Monday, March 26, 2012

Updating GridView control in a ModalPopupExtender

I feel that this should be a simple enough pattern, but I'm having trouble figuring out what's best to do, and how to implement it...

Offically sactioned best practices needed!

I've got a page with a gridview on it, where a link button in each row can pop up a panel using the ModalPopupExtender in order to allow the user to edit details from another table. The panel that pops up has a gridview on it that allows for in-line editing of rows in this secondary table. I show Edit and Delete buttons for each row, and when in Edit mode, I show the user Update and Cancel buttons. The panel itself has only a Close button referenced as the OKControlID of the ModalPopupExtender. The first gridview is enclosed in an UpdatePanel to avoid unnecessary page reloads since nothing the user does on the popup will affect the results of the top gridview.

My question is this: What is the best way to ensure that the user has clicked either Update or Cancel in the gridview before closing the popup? I would like to do this so that I ensure that the gridview on the popup is returned to ReadOnly view for the next possible edit and not left in Edit mode.

First Attempted Solution:

No validation needs to take place, so ideally I would simply like to automatically update whatever the user may or may not have done in order to return the gridview to edit mode. I tried to remove btnClose as the OKControlID of the popup extender and put server side code in the OnClick event of the button instead to detect if the gridview was in edit mode (EditIndex<>-1) and then call the UpdateRow method for the current row. This worked, but the page reload caused by this button is undesirable. If there was some way to fire off the UpdateRow method from the client side (i.e. from the OnOKScript of the popup extender), this would be ideal.

Second Attempted Solution:

I also tried to simply disable the Close button on the panel via client side script when I click the Edit button in the gridview and then re-enable it when the user clicks Update or Cancel, thus preventing the closing of the popup until the user has performed one of those tasks, but I can't figure out the javascript needed for those buttons' OnClientClick properties.

Any help with either method (or suggestions on an alternate one!) would be greatly appreciated...

- Ronn

I found my own workaround to this by simply not utilizing an OKControlID button on the panel at all. I put code in the ItemUpdated and ItemDeleted events of the GridView itself to call back to a public method of the form which calls the ModalPopupExtender.Hide() method.


I use this technique when making a progress bar visible/invisible:

var imgBar = document.images.namedItem("imgProgBar");
imgBar.style.visibility = "visible";

Perhaps you could use this idea within your OnLoad() and OnUnLoad() functions.

Either that or I believe you could use the "enabled" attribute as well. You should verify that, though.

Good luck,

Bob

Wednesday, March 21, 2012

use httpHandler of AJAX in web application

Hey all,

I want to implement AJAX in my current running web application.

I am going to use .

<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>
</httpHandlers>

in my web application.

I want to know ...

(1). will there be any side effect of the above code,

(2) will my current functionality got affected.

(3)what this code is all about and what it does.

1. No your should not see any side effects

2. The functionality should remain intact.

3. All this does is tell the webserver that when it gets a request for an .asmx page, to use the System.Web.Script.Services.ScriptHandlerFactory, and System.Web.Extensions classes to handle the request. for all verbs. So you .aspx, .ascx, etc will go unchanged and will continue to use the default HttpHandler. It then tells the web server to that when you recieve a GET or HEAD request for the ScriptResource.axd to use the System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions classes to handle te request. But since these classes extend the default classes that would normally handle the .asmx requests, then all your existing .asmx requests will work as originally intended. The above classes add the ability to JSON serialize requests for use with AJAX webservice calls.

Hope this helped clear things up.


thnx aquillin.

When I was not using the above code , I was getting error like "sys is undefined".
Yesterday I was reading an article and it said that the code generates the required javascript as AJAX uses it.

you said "All this does is tell the webserver that when it gets a request for an.asmx page, to use the System.Web.Script.Services.ScriptHandlerFactory...........,"

I have one dought that what is the link of .asmx (asp.net web services here). I am not using any web service .

Am i using them as hidden ?


The code actually doestwo things. One is the handling of .asmx web services. The other is handling of calls to ScriptResource.axd. That's required to deliver the Microsoft AJAX Library to the client.

It shouldn't affect your application unless for some reason you were already using something called ScriptResource.axd (extremely unlikely, but just being complete).