Re: FormattedText in Memory
- From: Bob Keeney <bobk@xxxxxxxxxxx>
- To: ftcdev@xxxxxxxxxxxxx
- Date: Thu, 13 Jun 2013 11:48:47 -0500
I feel your pain. The tight integration between FTDocument and the Canvas
subclass makes it difficult to work with sometimes. The only way I've been
able to get around it is to initialize a window containing FTC but keep it
invisible (like what FTProxy does). I think the key limitation to the control
is that it needs a Graphics object from the OS so it can do all of its
initiation.
We've talked about refactoring the FTDocument class away from the Canvas (and
visa versa) and putting a rendering layer in between the two but that would
require a substantial rewrite and that we're not in a position to do so this
point.
However, I think you might be complicating your project a bit too much. Just
because you have 100's of text areas to display doesn't mean you need 100's of
FTC's in memory. Since you can only edit 1 at a time you only need to keep one
around in memory. The FTC is just a canvas subclass that is essentially just
drawing a picture. Capture that picture after the first render (I believe this
is done through DisplayPicture) and then when you're editing the event you can
replace the image with the FTProxy.
That's the rough 10,000 foot overview - I'm sure the devil is in the details
but that's the approach we've taken on a couple of projects. Hope that helps.
Bob Keeney
BKeeney Software Inc.
http://www.bkeeney.com
On Jun 13, 2013, at 11:33 AM, Jim Pitchford <jim@xxxxxxxxxxxxxxxx> wrote:
> I'm feeling a bit thwarted in trying to do something that maybe FTC wasn't
> designed to do.
>
> My app currently uses TextAreas to allow editing of text on screen. My app
> allows viewing and editing of events on screen - each event will contain a
> title, a description and any number of notes, each of which is edited within
> a self sizing textArea. There maybe 100's of events available to view at
> anyone time.
>
> By using TextArea I am also able to use the graphics classes to get
> g.stringHeight to be able to calculate the desired sizes and positioning of
> the textAreas - both for presentation on-screen, and for scaled presentation
> for printing. It is close to a WYSIWYG display.
>
> I was hoping to be able to drop in a FormattedText class instead of textArea
> to be able to do similar, by using the getDoc.getTotalPageLength, but I am
> finding a key limitation, that is I don't seem to be able to instantiate and
> manipulate the class in memory.
>
> It seems that FTC requires itself to be placed on a Window or
> ContainerControl somewhere so that the Open event will trigger to initialise
> itself, and establish the correct linkages to the associated FTDocument. It
> doesn't seem possible to initialise the FTC in memory only (as that doesn't
> trigger an Open event).
>
> Thus, in its current format, I think I would have to create a new FTC
> instance on an, albeit hidden, window - or multiple windows(potentially
> thousands of them for larger documents). That would seem to create an
> unnecessarily large management overhead.
>
> I've tried FTProxy, but that has the same requirement of being placed on a
> Window/ContainerControl. I've also tried creating the FTDocument and placing
> in FTC directly, but many of the methods required to initialise (equivalent
> to the Open event) are protected.
>
> Am I missing a trick somewhere?
>
> Jim
>
>
>
>
>
>
>
> FTC Website: http://www.bkeeney.com/products/formatted-text-control
> Set List Options (digest and vacation modes): www.freelists.org/list/ftcdev
> List Archive: www.freelists.org/archives/ftcdev
> Unsubscribe: Send email to ftcdev-request@xxxxxxxxxxxxx with "unsubscribe" in
> the subject field.
>
>
FTC Website: http://www.bkeeney.com/products/formatted-text-control
Set List Options (digest and vacation modes): www.freelists.org/list/ftcdev
List Archive: www.freelists.org/archives/ftcdev
Unsubscribe: Send email to ftcdev-request@xxxxxxxxxxxxx with "unsubscribe" in
the subject field.
Other related posts:
