sorry, wrong email
> On 06 Sep 2016, at 16:27, Greg Sedlock wrote:
>
> Payment for what?
>
> -Original Message-
> From: Jefferey rawdon [mailto:jeffere...@apache.org]
> Sent: Tuesday, September 6, 2016 3:56 AM
> To: Recipients
> Subject: Copy
>
> This mail is to inform you that the p
Payment for what?
-Original Message-
From: Jefferey rawdon [mailto:jeffere...@apache.org]
Sent: Tuesday, September 6, 2016 3:56 AM
To: Recipients
Subject: Copy
This mail is to inform you that the payment as be made, Download attachment
for the payment slip.
Jefferey rawdon
Re #2. Don't know for sure but I'd bet they didn't think about custom
styles and thought they could get everything they needed on the clipboard
in a more generic format so it would be more multipurpose and handle data
to from other applications and SWFs.
There is a way to serialize objects to tex
Agree on 1, it should be more “pluggable” (unless it improved since the
last time I checked).
Regarding 2, clipboard class (see [1]) seems to support object references
in clipboard. If the TextScrap is completely independent from its
originating TextFlow, placing itself in the Clipboard (probably
I'm not sure. Is there any way to deserialize to resolve to a reference to a
class instance?
For the most part, I'm using custom styles to track character and paragraph
styles. setStyle() and getStyle() writes and reads references to common styles
that can be applied to any number of TextLayout
It does work this way, yes. I also remember that there was no easy way to
extend the default exporter and/or to use this custom exporter for a text
component instances, due to the complex class hierarchy and to missing
properties to directly control this, but it could have been improved since
I loo
So is it as simple as serializing non-strings to text and de-serializing
on import?
On 11/3/13 11:12 PM, "Harbs" wrote:
>Here is a simple test case which illustrates the problem. I can change my
>app for custom handling of copy/paste, but it seems to me that this is a
>general short-coming in t
Here is a simple test case which illustrates the problem. I can change my app
for custom handling of copy/paste, but it seems to me that this is a general
short-coming in the was copy paste is handled in TLF.
Note: customStyle1 is preserved when the TextFlow is exported because it's
simple text
In a similar situation, I handled cut/copy/paste text operation events and
put data in clipboard using a custom clipboard format... You may also try
to subclass the editmanager to have it use a custom exporter..
Il 04/nov/2013 06:21 "Alex Harui" ha scritto:
> I'm not sure what user styles are and
I'm not sure what user styles are and why the aren't in the markup. Can
you provide more details?
Consider whether this is a general TLF issue or just something you should
do in your app to add functionality. A general TLF issue probably can't
bypass the Clipboard because you should be able to c
Is it an AIR app or browser? What
1. Where are you pasting it into? If you're pasting into another location
in the same document then I would override and update the export method to
include your custom styles. How are the styles complex? They should be
inherited or if it's actual styles and class
Okay. After researching this, it looks like the problem is as follows:
The TextFlow is saved to the clipboard as a string which is the markup
representation of the TextFlow. The markup is produced using
BaseTextLayoutExporter.export(). The markup produced from that is missing
custom user styles
12 matches
Mail list logo
