You already have that in some way.
What kind of drag and drop behavior ?
De : Sumudu Chinthaka [csum...@gmail.com]
Envoyé : mardi 10 décembre 2013 06:32
À : users@flex.apache.org
Objet : Drag and Drop Support for Mobile
Hi all
will there be any chance to h
Hi all
will there be any chance to have drag and drop support for mobile in future
releases of Apache Flex.
if not do we have any workarounds to achieve this
Regards
Sumudu
Hi All :)
Similar mechanism to described by Alex is a part of Fabrication Framework.
"Events" in fabrication called "Reaction". Every view is managed by mediator
whitch contain methods: addReaction, removeReaction, disposeReactions and
hasReaction - such methods into some utility could be really u
Ok, thanks Alex.
-Mark
On Mon, Dec 9, 2013 at 5:40 PM, Alex Harui wrote:
> True, but in the five minutes I've spent thinking about this, I'm thinking
> this is for listeners added by a developer's AS code, not by code
> generated by MXML or by the framework, and it will be up to the developer
True, but in the five minutes I've spent thinking about this, I'm thinking
this is for listeners added by a developer's AS code, not by code
generated by MXML or by the framework, and it will be up to the developer
to be disciplined enough to use it.
So, if instead of writing: foo.addEventListener
Just a side thought on your proxy idea. The only complication to it is
this... We could have one that can be enabled at anytime, but it would only
have visibility over what has happened since it was enabled. I like the
idea, just need to find an angle that works and provides the functionality
as w
I wouldn't mind looking into that. Maybe using Dictionary's/Map's to group the
data better. But I like the idea to only have it enabled exactly where it's
needed. My proof of concept code was a bit overkill to make feasibility
testing easier.
More idea's for it would be great. I did make
Yes, it cannot be done as fast as the player code. And also, it is often
backwards from what you want. The references pinning an object in memory
is not the calls to addEventListener on that object, but the
addEventListener calls that object made to other objects. Remember:
foo.addEventListener(
That's probably installed then. Have a look in /opt
Tom
On 06/12/2013 17:40, Ludovic Bertin wrote:
Préparation... #
[100%]
Mise à jour / installation...
1:org.apache.flex.installapacheflex#
[100%]
On Thu
Starling uses their own, but I believe the agreed reason for us not doing it
was a performance issue. The flash player is running native code at something
like 40 times more efficient I believe... or at least that was what was stated
in someone's tests.
-Mark
-Original Message-
From:
Well you can add some redundant code to removeAllListeners if you would like,
but we can't modify the flash player code. The dispatching ultimately gets
handled by the player. I made an example[1] a while back on duplicating the
tracking of the event listeners and ultimately it can remove them
Hi,
> Also, implement something like removeAllListeners to a base class such as
> UIComponent
Sadly not 100% possible without Flash Player changes.
Thanks,
Justin
+1 on the skin upgrades.
Also, implement something like removeAllListeners to a base class such as
UIComponent or possibly have a utility class that has the same effect. I
saw a patch a while back but I don't think it was ever added.
13 matches
Mail list logo
