I see that Tree dispatches a "change" which is of type ListEvent, whereas Button, Checkbox etc dispatch a "change" of type Event.
So if I can use "changePicker" in a variety of my components, rather than "changeDate", "changeAddress" etc., why not just "change". It's a little hard to debug, since there's no stack crawl on the 1034. On Tue, Feb 3, 2009 at 4:39 PM, Richard Rodseth <[email protected]> wrote: > As Flex, or as any others within the app? > > > On Tue, Feb 3, 2009 at 4:25 PM, Tracy Spratt <[email protected]>wrote: > >> I would not use the same type name. >> >> >> >> Tracy Spratt >> Lariat Services >> >> Flex development bandwidth available >> ------------------------------ >> >> *From:* [email protected] [mailto:[email protected]] *On >> Behalf Of *Richard Rodseth >> *Sent:* Tuesday, February 03, 2009 6:11 PM >> *To:* [email protected] >> *Subject:* [flexcoders] Another 1034 - events and event types >> >> >> >> I have a few MXML components that provide reusable pickers for things like >> date ranges. I also nest these components. >> Is it OK to reuse event types like "change" and "activate", but associated >> with different event classes? >> For that matter must an event type always be associated with one class? >> >> I dispatching non-bubbling events from these components, and set up the >> meta-info as expected: >> >> <mx:Metadata> >> >> [Event(name="activate",type="com.companyname.appname.event.picker.DateRangePickerEvent")] >> </mx:Metadata> >> >> and use them like this: >> >> <picker:DateRangePicker >> activate="onActivateDateRangePicker(event)" >> /> >> >> I'm occasionally getting an error like this: >> >> TypeError: Error #1034: Type Coercion failed: cannot convert >> flash.events::ev...@f4130d1 to >> com.companyname.appname.event.picker.DateRangePickerEvent. >> >> Who would be trying to cast an event to my type? Changing the event type >> to "activatePicker" seems to be helping, but I'd rather not have a >> proliferation. >> >> >> >> >> > >
