Is TRichView what I'm looking for?

[anothergol]

Hello,

We're in the process of enhancing Delphi's VCL to allow custom painting of graphic controls, somewhere in between the current VCL & FireMonkey.

Because it cares about backwards compatibility, we don't have to rewrite every control, however the Windows RichEdit has a bug (or feature) that makes it not able to paint in another DC (WM_PrintClient not fully working either), so we have to make a new one.
..which isn't that bad, since we also have a new font engine as well.

So we're looking for our options as for replacing our edit boxes (yes, the simple single-line ones too), & richedit controls.
While I could live with just multiline editing without much formatting, I don't mind having more, but the question is how easy would it be to hack TRichView to use another font engine (one that supports fractional horizontal positions, a bit like DirectWrite, but better), onto a custom RGBA target (no DCs, because we need to preserve alpha channel)?

Is TRichView based on a lot of Windows system calls, or just basic text out, & I would assume asking Windows about the placement of each character in a string?

Thanks

[Sergey Tkachenko]

Honestly, I am not sure. One thing is to render a document on some special canvas using non-GDI methods. Another thing is to make the whole editor working in a different environment.

[anothergol]

Honestly, I am not sure. One thing is to render a document on some special canvas using non-GDI methods.

Well, I believe my non-GDI methods are much easier (nothing can be more limited than GDI), however I probably haven't implemented (but it's doable) all the text functions that you're using.
Also, my surfaces are GDI-compatible, they have a DC/canvas. It's just that they're RGBA, & the GDI is not very (well, at all) alpha-friendly.
It works more like GDI+ than D2D, except it doesn't suck because does the base things fast, & the polygon part uses Antigrain thus looks perfect.


Actually, my font engine can't even be told the name of a font (that's pretty hard in Windows!), only filenames, so I'm not expecting full RTF support anyway (but I don't really need that either).

I believe the main problem would be support for floating point X coordinates - this said, if you ever planned to support FireMonkey/Direct2D/DirectWrite, you will meet this problem too.

I would assume you use these?
-TextOut or DrawText (I support the major features)
-GetCharacterPlacement maybe? Or a combo of the other text metric functions?

I believe the biggest problem would be kerning, but I suppose the problems will only happen when strings are drawn in chunks, like if there's a font color change in the middle of a word, so not a big problem.
I don't have functions to know about kerning, & in fact I have no substitute for GetCharacterPlacement either, but I would of course do that.

Another thing is to make the whole editor working in a different environment.

It's only my painting that's custom, the control would still be a TWinControl descendant (well, a descendant of a descendant of TWinControl), with the same input. Ideally I'd prefer it a graphic control, but then I would have to implement custom keyboard focus.

[Sergey Tkachenko]

TRichView makes all calls to GDI drawing functions via a special class with virtual functions that can be overriden.
They have Canvas parameter, so you can write something like this in overriden class:

Code: Select all

if Canvas is TMyCanvasClass then
  ...
else
  inherited;

There are many functions used, if you want, I can send a source code of this class to you by email.
However, there are still many problems:
1) Integer coordinates
2) If changes can be made using Canvas properties (like Canvas.Font.Name := ...), they are made directly, without using that class. You should try to override them on a canvas level.

Text is drawn not character by character, but by substrings as large as possible. GetCharacterPlacement is used only when support of bidirected text is turned on.

[anothergol]

Seems good to me. I don't mind hacking the base sources in depth anyway, we've done this for everything we've used so far, sure it makes updating more difficult, but when it works we rarely need updates.

Text drawn in substrings is good, it will allow to preserve float inter-character spacing as much as possible, I assume.

I thought you'd use GetCharacterPlacement to know where to start & end filling behind selected text? Well if you use basic text width there, it's good too - selection or carret don't really need precise float placement either.

It's for use in FL Studio btw, I wanna make the GUI evolve & FireMonkey doesn't look like an option, even just for compatibility reasons.
I don't use many system controls, except basic edits, memos & richedits. I don't mind losing some compatibility with rich text format, but I'm hoping that a single-line edit control will be doable easily enough.


I'm spotting a bug in the ActionTest demo btw, when you select the text under "All actions", the l of the italic Control get chopped at the end.
(I don't do clipping in my font engine to avoid this kind of problem btw)

[Sergey Tkachenko]

I sent files to email.

As for clipping, it happens because selected items are drawn one after one, and the next item can override the previous one.
This problem is solved for colored text items (because TRichView draws all backgrounds first, then all text)

[anothergol]

Thanks, will check them in depth.

[anothergol]

I see Get/SetFontHandle, do you use them in important places?

Do you believe the control is also suitable for a simple single-line edit btw?

[Sergey Tkachenko]

They are used only in ScaleRichView (and SetFontHandle is used only to restore a value stored previously by GetFontHandle)

As for a single line editor, see http://www.trichview.com/forums/viewtopic.php?t=22