Gordon, True that their have been times I was required to use the stopPropagation's as well but for the question at hand it did the job. I find it quite rare that I need to use either, however sometimes you just cant let the event bubble or get through.
Sean, Wow. That could put you in a pickle at a later date. If it's not top secret, what were some of the requirements/problems that drove the decision to do this? jason -----Message d'origine----- De : flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] la part de Sean Sell Envoyé : vendredi 9 mars 2007 21:12 À : flexcoders@yahoogroups.com Objet : Re: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? I would like to chime in on this as well. I have practically re-written the form classes to make them implement our "standard look and feel" all of this should have been able to be done via sub-classing but SO MANY private variables and functions prevented it, I basically copied and recreated all the form classes for our application what w waist, can't wait to try to update this stuff with the next version just updating them to have the hooks for automation (Flex 2.0.1) has me concerned. ----- Original Message ---- From: Gordon Smith <[EMAIL PROTECTED]> To: flexcoders@yahoogroups.com Sent: Friday, March 9, 2007 1:50:14 PM Subject: RE: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? Actually, preventDefault( ) does NOT prevent other listeners from executing; this is what stopPropagation( ) and stopImmediatePropag ation() do. preventDefault( ) simply sets the flag returned by isDefaultPrevented( ) to be true. However, some event-dispatching code in the Player or the framework is written like this (and you can do the same thing in your apps): dispatchEvent( event); if (!event.isDefaultPr evented() ) doSomethingByDefaul t(); So calling preventDefault( ) prevents doSomethingByDefaul t() from being executed. But doSomethingByDefaul t() is not a listener. - Gordon ---------------------------------------------------------------------------- -- From: [EMAIL PROTECTED] ups.com [mailto:flexcoders@ yahoogroups. com] On Behalf Of Danko Kozar Sent: Friday, March 09, 2007 1:52 AM To: [EMAIL PROTECTED] ups.com Subject: [flexcoders] Re: Are other developers hesitant to extend existing classes in Flex? Jason, this was an eye-opener! Till now I didn't realize that an event listener can cancel another listeners. But the "preventDefault( )" method of the Event class does exactly that. This is the way I should go with a PagableGrid. Thanks! --- In [EMAIL PROTECTED] ups.com, "Jason Hawryluk" <[EMAIL PROTECTED]> wrote: > > As a follow up to the last response, take note of the > event.preventDefaul t(); in the handler for HEADER_RELEASE, and the fact that > I don't do a refresh on the ListCollectionView after adding the > > sort to it. > > jason > > > > > > -----Message d'origine--- -- > De : [EMAIL PROTECTED] ups.com [mailto:[EMAIL PROTECTED] ups.com]De la > part de Danko Kozar > Envoyé : jeudi 8 mars 2007 11:48 > À : [EMAIL PROTECTED] ups.com > Objet : [flexcoders] Re: Are other developers hesitant to extend existing > classes in Flex? > > > Private methods and variables drive me nuts.. > > For example, I'd like to make a simple DataGrid change: make headers > clickable without refreshing the grid (just toggle a sort icon). > (I need this behaviour because I'd like to have a paging DataGrid > which only propagates the sort column/direction info to a record- > feching routine on a server) > > So, I try to remove a "collection. refresh() ;" line from > the "sortByColumn( )" function, but I can't - because it's private. > > Then, I try to make a new function called "sortByColumn2" (that's a > copy of the first one, but without "refresh" stuff) and alter > the "headerReleaseHandl er" which calls it, but I can't - cause it's > private. > > And finally, I am trying to add the following code to the > constructor (yes, the constructor is public, huh.. :-)) > to "neutralize" the event listener: > > removeEventListener (DataGridEvent. HEADER_RELEASE, > headerReleaseHandle r, > false, EventPriority. DEFAULT_HANDLER) ; > > ... but I can't cause "headerReleaseHandl er" is private and can't be > seen from a subclass! > > And then, I give up.. :-) > > My conclussion is that Flex framework classes are not extensible > enough and I really can't see a reason. > Copying the whole DataGrid class and it's renderer, style, etc. > classes isn't a solution, we all agree. If not other reason - it's > not the OOP way. > > So, I'm tempted to go to a "C:\Program Files\Adobe\ Flex Builder 2 > \Flex SDK 2\frameworks\ source\mx\ " folder and make a global search > and replace on all files in this folder. You guess... > replace "private" with "protected". .. :-) > > --- In [EMAIL PROTECTED] ups.com, "Dana Gutride" <dgutride@> > wrote: > > > > Recently on this list, somebody said that the Flex framework team > has been > > surprised at the resistance many developers have to subclassing > and they'd > > like to understand it better. I'd like to put my 2 cents into this > > discussion because maybe we can come up with some good answers. > > > > I think the ability to extend the existing framework is fabulous, > but I find > > that I am hesitant to subclass or extend the existing classes. > Recently, I > > spent several days trying to override the placeSortArrow function > on the > > datagrid. I ended up ditching my code because there were so many > private > > variables used by the existing placeSortArrow( ) function that I > would need > > to rewrite most of the datagrid.as file. > > > > I've bought books and searched online for answers, but I haven't > found > > anything satisfactory yet. Maybe if there were more resources > (even if we > > had to pay for them), we would find more developers extending the > flex > > framework. > > > > Dana > > > ---------------------------------------------------------------------------- -- Don't get soaked. Take a quick peek at the forecast with theYahoo! Search weather shortcut.
