flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clint M <cmod...@gmail.com>
Subject Re: Scout - What does this mean?
Date Tue, 15 Nov 2016 21:29:37 GMT
Inline below

On Tue, Nov 15, 2016 at 12:43 PM, bilbosax <waspence41@comcast.net> wrote:

> The big question is do Exceptions take up time?


> I am finally able to get some good data into Scout to profile my mobile
> application, and I am quite confused.  The compiler finds no errors,
> debugging throws no errors, my application is displaying all of the correct
> data, but when I run Scout and look at a frame that is taking nearly
> 4000ms,
> I find that hundreds of exceptions are being thrown.  They don't show that
> they are taking any time in ms, but surely hundreds of them have to be
> taking up some significant time.  They are all TypeError Exceptions.  I
> assume that they mean that I assigning an incorrect value to a datatype of
> some sort.  Here is a picture of a grab of the error list:
> <http://apache-flex-users.2333346.n4.nabble.com/file/n14126/scout2.jpg>
> If I mouse over any of the exceptions, it gives me a ton of data that I
> don't really understand.  It does not give you a line-number of where the
> exception is being thrown, so I don't know exactly what variable is being
> cast wrong.  If anybody could take a look at this and help me narrow down a
> value that I am assigning incorrectly, I would greatly appreciate it.  I am
> assuming that it is an itemrenderer value that I use "data" to assign
> values
> to labels. Do you think  that hundreds of these exceptions are taking any
> appreciable amount of time?
> Exception: TypeError
> MethodInfo-12677
> mx.binding::Binding/wrapFunctionCall
> mx.binding::Binding/innerExecute
> mx.binding::Binding/wrapFunctionCall
> mx.binding::Binding/execute
> mx.binding::BindingManager$/executeBindings
> renderers::targetListRenderer/_targetListRenderer_Label3_i
> renderers::targetListRenderer/_targetListRenderer_Group5_i
> renderers::targetListRenderer/_targetListRenderer_HGroup2_c
> renderers::targetListRenderer/_targetListRenderer_Group4_c
> renderers::targetListRenderer/_targetListRenderer_HGroup1_c
> renderers::targetListRenderer
> mx.core::ClassFactory/newInstance
> spark.components::DataGroup/createRenderer
> spark.components::DataGroup/createVirtualRendererForItem
> spark.components::DataGroup/getVirtualElementAt
> spark.layouts::VerticalLayout/updateDisplayListVirtual
> spark.layouts::VerticalLayout/updateDisplayList
> spark.components.supportClasses::GroupBase/updateDisplayList
> spark.components::DataGroup/updateDisplayList
> mx.core::UIComponent/validateDisplayList
> mx.managers::LayoutManager/validateDisplayList
> mx.managers::LayoutManager/doPhasedInstantiation
> mx.managers::LayoutManager/validateNow
> mx.core::UIComponent/commitCurrentState
> mx.core::UIComponent/setCurrentState
> mx.core::UIComponent/set currentState
> views::RealDealsTabletRealDealsMainView/compClickedHandler
> flash.events::EventDispatcher/dispatchEvent
> mx.core::UIComponent/dispatchEvent
> views::RealDealsTabletRealDealsMainViewInnerClass0/myEventDispatcher
> views::RealDealsTabletRealDealsMainViewInnerClass0/___
> RealDealsTabletRealDealsMainViewInnerClass0_Button1_click
It could be a null pointer 1009. The data property can be set to null
especially when using binding.

Here's a util to debug bindings.

You may want to avoid using mxml for itemRenderers and also avoid using
bindings inside the item renderers all together.

> --
> View this message in context: http://apache-flex-users.
> 2333346.n4.nabble.com/Scout-What-does-this-mean-tp14126.html
> Sent from the Apache Flex Users mailing list archive at Nabble.com.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message