I just love talking to myself. No, the bug is not going to go away, I know people from Adobe read this list. This is really a show stopper, can someone from Adobe take a look please.
has anyone on this list tried to decompile the fds swc, if so can they mail me off list and tell me how that worked out for them, kinda desperate by now.... On Wed, May 27, 2009 at 11:10 AM, Johannes Nel <johannes....@gmail.com>wrote: > Since Jeff has left Adobe, can someone from Adobe please check the source > code on this. > > We are using build 2.6.0.201390 of the fds.swc. > > > > > > > > On Tue, May 26, 2009 at 11:13 AM, Johannes Nel <johannes....@gmail.com>wrote: > >> No, tis not 1, all our error handeling uses FaultEvent. >> >> How I would have approached this with other parts of the framework. >> Copy the adobe class into my src folder, make the change needed to avoid >> the error and let my changed class override the adobe implementation at >> compile time (what are the implications for this with split framework rsl?), >> obviously this is not an option now. >> >> :( >> >> >> >> >> On Mon, May 25, 2009 at 7:28 PM, Jeffrey Vroom <j...@jvroom.com> wrote: >> >>> >>> >>> I see two possible things that could cause this error: >>> >>> 1) you have a fault handler whose function definition takes a >>> MessageFaultEvent parameter. You need to change that to the common base >>> class which is (I think) a FaultEvent so it can accept both a >>> MessageFaultEvent and a DataServiceFaultEvent. >>> 2) there is a bug in LCDS where it is doing 1). >>> >>> If you check your code and you don't have any event handlers which take a >>> MessageFaultEvent, it is probably 2). I don't have access to the source >>> anymore or I'd check into 2) for you... >>> >>> Jeff >>> >>> >>> On Mon, May 25, 2009 at 5:17 AM, Johannes Nel <johannes....@gmail.com>wrote: >>> >>>> >>>> >>>> Hi All >>>> >>>> I have a LCDS app which must stay open for ages, deal with dodgy >>>> internet connections and all such fun things. >>>> Thus far we have managed to get the NetConnection to re-establish itself >>>> nicely when the line drops, but here is a wonderful error (which does not >>>> actually break the app) that i get after having the app open for a few >>>> hours, only on OS X. >>>> >>>> So, the fact that it does not touch our code anywhere means that I have >>>> no way of trapping this. I would really like some advice on how i can >>>> suppress or even catch it. >>>> >>>> >>>> >>>> TypeError: Error #1034: Type Coercion failed: cannot convert >>>> mx.data.events::dataservicefaultev...@2cb864c1 to >>>> mx.messaging.events.MessageFaultEvent. >>>> at mx.data::ConcreteDataService/sendRefreshFault() >>>> at mx.rpc::AsyncResponder/fault() >>>> at mx.rpc::AsyncToken/ >>>> http://www.adobe.com/2006/flex/mx/internal::applyFault()<http://www.adobe.com/2006/flex/mx/internal::applyFault%28%29> >>>> at mx.rpc.events::FaultEvent/ >>>> http://www.adobe.com/2006/flex/mx/internal::callTokenResponders()<http://www.adobe.com/2006/flex/mx/internal::callTokenResponders%28%29> >>>> at mx.data::ConcreteDataService/ >>>> http://www.adobe.com/2006/flex/mx/internal::dispatchFaultEvent()<http://www.adobe.com/2006/flex/mx/internal::dispatchFaultEvent%28%29> >>>> at DataListRequestResponder/fault() >>>> at mx.rpc::AsyncRequest/fault() >>>> at NetConnectionMessageResponder/channelDisconnectHandler() >>>> at flash.events::EventDispatcher/dispatchEventFunction() >>>> at flash.events::EventDispatcher/dispatchEvent() >>>> at mx.messaging::Channel/disconnectSuccess() >>>> at mx.messaging.channels::NetConnectionChannel/internalDisconnect() >>>> at mx.messaging.channels::RTMPChannel/internalDisconnect() >>>> at mx.messaging.channels::RTMPChannel/statusHandler() >>>> >>>> regards >>>> Johan >>>> -- >>>> j:pn >>>> \\no comment >>>> >>> >>> >>> >> >> >> >> -- >> j:pn >> \\no comment >> > > > > -- > j:pn > \\no comment > -- j:pn \\no comment
