My real concern is the fact that findLeaf() is used in so many places. It makes
the assumption that you can find a leaf by index anywhere in a text flow. That
assumption falls apart with tables. I make a clear separation between tables
and their contents. As far as the text flow is concerned, th
Thanks, Have one runtime exception.
ReferenceError: Error #1069: Property
http://www.adobe.com/2006/flex/mx/internal::gridDimensions not found on
spark.components.Grid and there is no default value.
in the code
const dimensions:GridDimensions = grid.mx_internal::gridDimensions;
On Sat, Jun 7,
Hmm, was that posted to the group?
On Thu, Jun 5, 2014 at 11:04 PM, Oleg Konovalov wrote:
> Hi,
>
> I tried to introduce Adobe Deep Linking to my Web App.
> That created a problem when I run it in IE9 - it often shows "#" on page
> title (if no URL params used)
> or even "#param1=x@param2=y" if
IE deep linking used to use an Iframe. I haven't looked at IE9 to know if
it still does, but that might be adding the #. The iFrame is not used in
Chrome or other browsers.
Do a small test with Apache Flex 4.12.1 and see if you have the same
problem.
-Alex
On 6/8/14 9:06 PM, "Oleg Konovalov"
Hmm. The doc says that FlowLeafElement doesn't have any children. But
Tables can certainly contain other tables, right? And aren't the
headers/rows/cells considered children?
FlowLeafElement also has a text property. Are you going to be overriding
that?
Is it just too hard to make a TableElem
Please see this issue. I’m sure there are plenty of related bugs.
https://github.com/Harbs/TLF-Table-Work/issues/28
I’m thinking of changing the base-class of TableElement to change it to a leaf
element rather than a group element. I don’t see any reason off-hand not to do
that, but I very like
