On 12/03/2012 15:34, Justin Mclean wrote:
Do you mean s:TextInput? s:TextInput uses TLF under the hood. As the event
doesn't bubble by default you might not get it at s:TextInput level but need to
listen on the text component inside it? textDisplay for instance? Just a guess
and I could be way
HI,
> No TLF loaded. I added a listener to the TextField, stage, a containing
> sprite (like I found in TLF) and the ime instance. Can not find any hints.
> (code at wonderfl[1])
Do you mean s:TextInput? s:TextInput uses TLF under the hood. As the event
doesn't bubble by default you might not
Hi,
Just a not that the generated ASdoc files have been updated in both locations.
And if anyone want help generating ASDocs just ask. I'd forgotten how fiddly
they can be.
Thanks,
Justin
On 12/03/2012 07:21, Justin Mclean wrote:
Interesting but perhaps not that surprising it's a little odd in transparent
mode. Window is the most likely wmode for a flex application. I assume it works
fin in that mode on all browsers you tested?
Yes, the other wmode settings work.
Open Quest
Hi,
Just an update on where we are with the PostCodeValidator and PostCodeFormatter
classes. The some outstanding questions at the end of this email you can skip
to.
Compared to the existing components these components.
1. Supports a wide range of postcode formats both numeric and alpha numeri
On 3/10/12 11:00 AM, "Martin Heidegger" wrote:
> Thanks Alex,
>
> lets see what to do about this. I guess I don't want to bother the Adobe
> lawyers ... as they
> have (a lot) more important things to do. Which leaves it open to write
> a new one *yey*. I am not
> sure when I will start with
This is where I was going. I wrote my own because the Adobe ones sucked
for mobile.
It comes down to this IMO.
User Interface:
- is the person familiar with RGB, et al value an can use sliders to
determine the value?
- does the user need to be guided by a better UI to find the colour.
To test
Seems one could break the color selector down into a couple of possibilities:
1. Discrete set of color values
2. A color range
Either of these could be presented using a number of layouts, such as square,
spiral, or line gradient, and a number of item renderers (maybe for discrete
values only).
The MX color picker was okay but very hard to use on mobile. Even if you
scale it, it is hdd to predict the expansion of colors based on horizontal
vs. vertical. To be honest, I like your idea. The colour class logic is
very simple (getColor, setColor). The UI component maybe needs a rethink?
Hi,
I've placed the generated ASdoc from the formatter and validator classes in the
whiteboard but it not very readable there.
So here are some alternative links:
http://cdn.classsoftware.com/apacheflex/postcodes/asdocs/mx/formatters/PostCodeFormatter.html
http://cdn.classsoftware.com/apacheflex
Hi,
> Having thought about the CP's for a while, I came to an opinion. I used
> to think that the uber-does-everything color picker was probably the best
> idea.
>
> My gut feeling is having a few different colour classes might be the
> ultimate answer and let users pick which ones they want.
Hi,
> I was curious about how that IME works in detail accross implementations and
> I stumbled upon the following:
> * It doesn't work same in the various WMODEs
> * In some WMODE settings it behaves differently in different browsers
Interesting but perhaps not that surprising it's a little odd
Having thought about the CP's for a while, I came to an opinion. I used
to think that the uber-does-everything color picker was probably the best
idea. Think of the Photoshop CP with all the different filters etc.
After using CP's in various projects though, I came to the conclusions
that there a
On 12/03/2012 06:00, JP Bader wrote:
Martin - do you have the source code on git or google that we could
look into this?
I'd be happy to look at the CPs people have mentioned so far, review
complexity and Spark-ability, and write some unit tests to cover them,
and bring that to a whiteboard.
JP
Martin - do you have the source code on git or google that we could
look into this?
I'd be happy to look at the CPs people have mentioned so far, review
complexity and Spark-ability, and write some unit tests to cover them,
and bring that to a whiteboard.
JP
On Thu, Mar 8, 2012 at 4:02 AM, Marti
Hello guys,
I was curious about how that IME works in detail accross implementations
and I stumbled upon the following:
* It doesn't work same in the various WMODEs
* In some WMODE settings it behaves differently in different browsers
Here is my test suite: [1].
I managed to find out follow
Hi,
Well that was actually quite easy - changes checked in. Just guess it goes to
show that coding can be quicker than discussion :-) I'd still appreciated
someone to supply alphanumeric unit tests (the wide character numeric tests
pass fine) and to compile and test the sample application with
Hi,
While I'm still not convinced that wide character support needs to be built
into the PostCodeValidator class I think the simplest way is to do so is use
the flash.globilization.Collator class and the equals method to compare
character by character in all operations with ignoreCharacterWidt
Hi,
> As far as I know Firefox has never been webkit based. It's based on
> Mozilla's Gecko engine.
Yep I got that wrong (it's late here)- sorry. So you know what browsers it is
supported in?
Justin
> Both HTML and flash applications? As I said it works in Safari for me
which is WebKit based like Firefox.
As far as I know Firefox has never been webkit based. It's based on
Mozilla's Gecko engine.
-omar
Hi,
> the IME has not much to do with that.
Validators are intended to be use with UI components usually text input field
which have IME support. The documentation makes it fairly clear (to me) that
the responsibility should be in with the text field (via IME) not in the
validator.
> User is
21 matches
Mail list logo
