Success - (NEARLY ...)
I think you'll agree we are pretty close. There is just a little bit of flicker. This flicker is the SelStart jumping the Cursor position around the text. We need to hide this. This "Cursor" is also known as a Caret. Looking throughning Win32.hlp Again We Find The Lovely, And Appropriately named, hidecaret () function.
Lets Try this Then: Everytime We change The value of myre.selstart letts call hidecaret (myre.handle) immedierately before.
I'll Be Kind - That Doesn't Work. I Tried 2 x hidecaret (Myre.handle), And It Still Didn't Work. Neither Did Three, Four OR 25X. So Close - But Yet - So Far. I think ITS Time for Another Delphi Rule:
Delphi rule # 5 - if you bother to get your way through the atrocious index of the win32.hlp file to find what you are looking for - make you real ie you find protroperty!
The key was the last paragraph in the description of not HideCaret but ShowCaret (which I had also read as I thought we were going to need it, especially to reverse my 25x HideCaret ()) You also need another Delphi Rule to understand it.:
THE CARET IS A Shared Resource; There IS Only One Caret in The System. A Window Should Show a Caret Only When The Window Has The Keyboard Focus or is Active.
Delphi rule # 6 - Everything (Basically) IS A Window
You See the richedit is a windows control and is also .. in a weird sense .. a window. It has a handle, Which is why hidecaret wouldcept it. So re-recaping the last line again we get:
THE CARET IS A Shared Resource; There IS Only One Caret in The System. A [Richedit] Should show a caret only when the [richedit] HAS the keyboard focus or is active.
So - in the end - we're back to were we started -. We have to disable the RichEdit to stop the final bit of flickering This also (co-incidentially) means that EM_HIDESELECTION is not needed anymore (if HideSelection is set properly during Design Time). So in the ends # 10/10 for Marks! ASH VERSION 0.9B
Procedure tform1.richedit1change (sender: TOBJECT); VAR
SaveOnChangeIn: TNotifyEvent; WasSelStart, WasRow, Row, BeginSelStart, EndSelStart: Integer; MyRe: TRichEdit; MyPBuff: array [0..255] of char; MyTokenStr: string; MyTokenState: TTokenState; MyRun: PChar; MySelStart: Integer;
Begin
Myre: = trichedit (sender);
SaveOnchangein: = myre.onchange; myre.onchange: = nil;
Myre.enabled: = false;
WasSelStart: = MyRE.SelStart; WasRow: = MyRE.Perform (EM_LINEFROMCHAR, MyRE.SelStart, 0); Row: = WasRow; BeginSelStart: = MyRe.Perform (EM_LINEINDEX, Row, 0); EndSelStart: = BeginSelStart Length (MyRE .Lines.strings [rot]);
Strpcopy (mypbuff, myre.lines.strings [row]); mypbuff [length (myre.lines.strings [rower)]: = # 0; myselstart: = beginselstart; myrun: = mypBuff;
While (myrun ^ <> # 0) do begin
Myrun: = Pascon.getToken (MyRun, MyTokenState, MyToKenstr);
Myre.selstart: = myselstart; myre.sellength: = length (MyToKenstr);
IF myre.selattributes.name <> pascon.fparsefont [myTokenState] .name dam = pascon.fparsefont [myTokenState] .name;
IF myre.selattributes.color <> pascon.fparsefont [myTokenState] .COLOR THEN Myre.selattributes.color: = pascon.fparsefont [MyTokenState] .color;
IF myre.selattributes.style <> pascon.fparsefont [myTokenState] .stylezhen myre.selattributes.style: = pascon.fparsefont [myTokenState] .style; myselstart: = myselstart length (MyToot length
END;
Myre.Selstart: = WasselStart; myre.sellength: = 0; myre.onchange: = saveonchangein; myre.enabled: = true;
Myre.setfocus;
END;
Towards - ASH VERSION 1.0B
Couple of Problems with the last version if you try it out for size:
Its slightly inefficient in that everytime SelAttributes is changed it forces a repaint of the same token in the control We should instead use some variable (eg var DoFormat: Boolean). To decided if we need to reformat, and then check the value of DoFormat at THE End of this checking, and do it all damu (fParsefont [myTokenState]). this means we can also change the seperate "if" statements to a single if ... then .. else .. if ... then .. else which should code faster - especially if you put the various test situations in the order of likeliness to occur (eg font changes less frequently than the color, so should be further down the if..else..if ) For Some Reason if you type a {style comment} on a line, after the 4-7 characters it reperts to diffreent colors. I can't Seem to work out yet why this happens - But I understand why its not beings picked Up So if you select t text which starts off black and then becomes blue, SelAttributes.Color will equal clBlack We must also examine SelAttributes.ConsistentAttributes to ensure that the entire selection is consistent in the way it is highlighted If it is not -.. then we want to Force it to be rehanght - its obviously not in the correct format. Multi-line Comments Are A Big Pain EG {Words
{ "Anywhere in the code The highlighting can force a repaint of the entire 2,000,000 lines of text in the control We could catch that situation -.. Ie if the last token on the line is a tsComment and it does not end in '} 'we could increase SelLength until it did or we reach the end of the RichEdit.Lines. (that basically what the tokeniser does anyway with all that inc (Run).) that easy. But what happens if you then delete the "{" ? You need to go forward 2,000,000 liss and put the highlighting back Again? We Could Decide to Keep Going Until the ... dam..Elese..List Didn't set doFormat: = true. But what happens if We're . in a colour mode were Comment highlighting style = KeyWord highlighting style We would stop prematurely So this "logic" wont help in all situations you can still get the "someone is chasing you effect" -.. except now its "someone is fleeing from YOU "Effect. It happens when you have (* this is a comment *) and delete the first * -character. The control takes an appreciable time to rehighlight the text. While looking for a fix for the last problem, I remembered the Richedit.Lines.BeginUpdate function. But that did not help either. What we need is a Richedit.BeginUpdate. What would that do? It would increase an internal counter by one everytime it was called. RichEdit.EndUpdate would do the opposite. Then we would create our own WM_PAINT message handler. This is received everytime Windows wants the control to repaint a portion of itself. If we catch this Message the we can stop processing of these message until the intence counter =
0 again Then, and only then, will the Control repaint itself - ditching we would hope most of the intervening steps Fixing the mult-line comments:.. My current idea is to use the RichEdit.Lines.Object to store the TokenType of the . first token on each line This way we could easily know how far we need to go when re-hightlighting multi-line comments Initially this would be set to nil I think this will work [Editor update:... This did not actually work - as the RichEdit.Lines.Object is not implemented in TRichEdit control It is always nil regardless of what you assigned to it] Upgrading to RichEdit98: I'm also in the process of updating to the RichEdit98 components for Delphi 3.0-. .. 4.0 version 1.34 Author Alexander Obukhov, Minsk, Belarus This control has a number of advances on the standard RichEdit control that ships with Delphi Included in this are:. BeginUpdate, EndUpdate Independant background colours Margins Hotspots (Source code in full)
Anyway I hope you have enjoyed the adventure.I'm sorry if not all the examples compile as written. They may need some fixing to compile if you copy straight from the Browser into the Delphi Editor. Please send any comments to jonhd @ hotmail. COM.
Jon hogdog
