Disappearing caret when container is scaled

[Aaronius9er9er]

Make a text flow with a large font size, then scale down the container.  Suddenly we have a faint and oft-disappearing caret.  See it here:

http://aaronhardy.com/transfer/scalecaretbug/ScaleCaretBug.html

Right-click the sample app for source. This appears to be because the caret isn't drawn using a hairline (in which case it would supposedly show up at any scale) but instead a one-pixel-wide rectangle.  This is gleaned from TextFlowLine.computePointSelectionRectangle() and ContainerController.drawPointSelection().

Which brings me to my questions:

(1) Has this been reported as a bug?

(2) Is there a workaround?  Currently it appears that I'm going to need to extend ContainerController to implement my own caret drawing.

Thanks.

Aaron

[Aaronius9er9er]

And if any of you from Adobe are reading this, please stop marking so many things private!  It makes it nigh unto impossible to fix/modify anything.  I can hear you snickering at your desks as you type "private" snorting under your breath, "Now why would anyone else want to touch this? It is MIIINE!  All MIIIINNNE!"

[brycebarrand]

I totally agree with Aaronius9er9er. Why in the blue blazes are so many freaking things private? What is the reason?  Do you understand why this makes our lives difficult?  I'd be happy to provide examples of plenty of times where making something protected would have saved hours of work and frustration.

Sorry to distract from the caret issue.

[MediaRainMan]

The private vs. protected issue has been one of my pet peeves for a  long time.  I recall recently that I needed to override a method in

a  Flex 3 component and was pleasantly surprised to find that every  property that was referenced within the method was protected instead of  private.

And that's the problem.  Why was I surprised  to find that I could actually override something in a Flex component?   It seems that that should be rule, not the rare exception.  As with brycebarrand, I, too, have spent hours of needless work simply to get around properties that should have been accessible, but were not, namely anything that is private referenced within a method that is not.  Once something private is referenced from within something that is not, that component and any of its subclasses suddenly become code-locked.

The only exception that I can think of are private holder vars within getters and setters.  Since getters and setters can be overridden if they're not private, the holder vars may be private and nothing is hurt, as long as the holders are only referenced by their getters / setters.  Once a private holder var is referenced anywhere else, then the behavior of the getter / setter pair is no longer encapsulated, and all is spaghetti.

The bottom line is that private properties and methods that cannot be accessed and therefore not overridden make Flex components inextensible.  My team has resorted, at times, to copying the entire code from Flex components and creating new ones just to override the private properties, when that's even possible.

What's the goal of using private properties instead of protected ones?  Yes, they have their place, but it is a very, very small place - like using chemo therapy.  Use it only if you absolutely have to and there is no better alternative.

I  had hoped that the issue would be remedied for Flex 4, but I guess  enough people haven't complained about it?

[Guest · Accepted solution]

Thanks, I've reported the bug.

We've recently co-located a bunch of the TLF team into the same hallway, and I can say that I rarely hear snickering and almost never any snorting. Please report here anything you find that you'd like changed from private (you can also make the change yourself and recompile TLF, if you like).

[brycebarrand]

Off the top of my head, I ran into a weird issue with Slider.as where I would have loved to have been able to overwrite setValueAt() 

But there are too many to list.  We run into an issue every couple of weeks.  I think it is beyond just a few fixes here and there. It should be a philosophy change on the Flex team of what is private and protected.

[Aaronius9er9er]

Alan, thanks for the response and for reporting the bug.  My take is that protected (or even a custom namespace for that matter) is superbly delicious and should be used quite liberally.  Oh the privelege of extending an "extensible" framework!  Private--oh no you didn't!  To me you best be saying, "WTF OMG!  If you touch this piece of code your app will explode into a thousand pieces and take the internets with it!  You'll be out of work and begging on the streets for a single loaf of bread!"  Freaking unleash protected and let us breath free!  If I feel motivated enough I'll start compiling my list and posting here, but let's start with making containerScrollRect* and startBlinkingCursor() protected or custom-namespaced.  Oh what a pleasure it would be to override drawPointSelection() and actually accomplish something!  Sure, I could recompile TLF every time I wanted to make a change...if I wanted to drown myself in my tears when a TLF update came along.  Bloody tears--'cause I would've already stabbed my eyes out with a dull fork.

[robin_briggs]

I've opened a bug for these requests to move from private to tlf_internal -- if you have other things you'd like to see moved, please add them on to the thread.

Thanks!

- robin

[Aaronius9er9er]

Much appreciated.

I would highly encourage taking everything currently marked as private and marking it as protected.  Then, one by one, go through and ask yourself, is there an honest, valid reason why we would NEVER want an external (to Adobe) developer to access this?  It seems like the philosophy has been to mark everything as private unless there's a reason to do otherwise.  It's my perspective that it should be the other way around.  Like brycebarrand said, it's not just a few items here and there that should be changed, it's an overarching philosophy throughout the whole Flex SDK.

[Aaronius9er9er]

..and everything that EditManager.doOperation() and EditManager.finalizeDo() touches.

[Aaronius9er9er]

Next items I would like protected instead of private: UndoManager.undoStack and UndoManager.redoStack