Showing posts with label fact. Show all posts
Showing posts with label fact. Show all posts

Saturday, March 24, 2012

how difficult is it to retrofit a webapp with the ajax toolkit

Hi folks, haven't posted in any of the ajax forums before in fact I haven't used the toolkit or the ajax framework extensions for asp.net at all. All my ajax to this data has been regular javascript functions. Anyhow for the current web app I'm building I really want to pull out all the stops for the client so was consdering using some toolkit controls namely collapsible panel, calendar and autocomplete. However my app is about 50% complete and i want to finizle the core functionality of it before getting down with ajax so I'm wondering how easy or difficult is it to retrofit a webapp with controls from the toolkit. Am I better of stopping right now and implemented the ajax controls or do I need to start form sratch? or can I simply tweaks a few things to make ajax controls work when I 99% done with CS code behind stuff.

Thanks for your thoughts.

The quickly you convert your website to ASP.NET AJAX website the better. Toolkit controls are really easy to use, but if you are planning to use lot of update panels then u might to change your aspx pages a bit so if you are thinking about moving to AJAX website you should do so as quickly as possible.

And to convert your website, all you have to do is change your web.config file. Generate one blank ASP.NET AJAX enabled website through VS and copy the content of web.config file to your current web.config file at appropriate places.

Hope it helps.


I'd start implementing the AJAX control now if you've decided that's the route you want to take. Thisdocumentation will help you get started.


Thanks guy, I really don't want to have to delve into ajax yet if at all avoidable. I will basically needed two or three controls thats all. 2 collapable panels and autocomplete (calendar I can live without). I'm putting together an advanced fine panel at the moment, with textboxes checkboxes etc. I will be wanting to move that from a regular panel to a collapable panel, thats all. Will even this be a pain in the neck to retrofit?


You'll still have to go through all of the conversion process regardless of how many controls you choose to use.

Wednesday, March 21, 2012

How can I prevent floatingBehavior being draggable via the right mouse button?

Hi there,

I'd like to be able to handle a right-click in a region that has the floatingBehavior. Unfortunately, the fact that floatingBehavior allows the region to be dragged via the right (context) mouse button as well as the left is interfering. (In fact, even if it weren't causing problems for me, having the regions draggable by the right mouse button breaks a lot of the UI conventions I'm hoping to capitalise on.)

So, I'd like to stop the right mouse button from dragging. How can I do this?

There's no built-in option, but that's OK. I'm happy to inherit and override the floatingBehavior class, but the important bits don't seem to be overridable (unless I'm doing it wrong) and anyway floatingBehavior is sealed.

How can I accomplish this?

Many thanks,

Geoff

1. You can't inherit from the class and would have to rewrite it. I WISH!!!
2. Button definition within browser means different things on different browsers, systems, no real way to tell which button was pressed.
3. If you write your own you can do this only for some of the browsers and os. From memory button and which returns 0 on some browsers for left, on some it returns 1, no real way to tell which is clicked for all browsers.
4. Whatever you're trying to capitalize on assumes there is more than 1 button. What abour our Mac friends? (ahem, I admit it I use a Mac on occassion).


Hi,

1:. I was afraid of that.

2, 3 and 4: I'm not convinced. The DOM specifies the button used for events (http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent-button) and says how to handle buttons being swapped etc. And isn't one of the main drivers of Atlas being able to abstract away browser differences?

Fundamentally though I just don't think allowing drags by any button other than the left one is proper for many UIs. For instance, you can't drag the browser window in XP by grabbing the title bar with the right mouse button. You can't drag and drop messages in Outlook with the right mouse button. You can't drag and drop text in this very edit control with the right mouse button. All those actions only work with the left mouse button (with the right mouse button operating a context menu sometimes). I just want to be consistent with those expected behaviors.

I'm not against writing code to solve this, I'd just rather not have to reimplement the whole floatingBehavior for this one change.

Geoff


Like I said you won't be able to do this for every browser in every type of event. Here's a snippet that works for most browsers but I would only use it if you have strict requirements. I would also be careful about referring to buttons as left and right as some operating systems give you the option to switch left and right button (think left handed users) so better names are primary, secondary. The tertiary is either the 3rd button or the mouse wheel, no real definition here. Here's what you'd use inside your event.

var btn = Event.Which(e);
if (btn != Button.Primary) return;

Type.createEnum('Button','None', 0,'Primary', 1,'Secondary', 2,'Tertiary', 3);


Type.registerNamespace('Event');
Event.Which =function(e) {
if (typeof(e) =='undefined') e = window.event;
var isIE =(Sys.Runtime.get_hostType() == Sys.HostType.InternetExplorer); if (isIE ? (event.button & 1) > 0 : (event.button==1 ||event.which==1))return Button.Primary;
if (isIE ? (event.button & 2) > 0 : (event.button==3 ||event.which==3))return Button.Secondary;
if (isIE ? (event.button & 4) > 0 : (event.button==2 ||event.which==2))return Button.Tertiary;

return Button.None;
}