marks: 5/10
most of you would have found the hideselection property of the richedit control. when it is set to true and the richedit looses the focus (the user clicks onto another control) the selection bar (the black stripe) is hidden. in fact if you try it out by selecting some text in the richedit1 then clicking in the edit1 control at the top of the "editor" you'll see the selection disappears! [tab] back into the richedit control and it reappears. lets do this programmatically:
begin
edit1.setfocus;
~~~~~
myre.setfocus;
end;
take my word for it, but if you look closely, the black strip is gone. pity we got stuck with a new one in the edit1 control :-(
if your programmed in delphi you may know a little trick:
delphi rule #4: you can't setfocus on a disabled control.
the converse however is also true:
delphi rule #4b: a disabled control is not "focused"
so try instead we can just disable (then enable) the richedit control like this:
begin
myre := trichedit(sender);
myre.enabled := false;~~~~~~
myre.enabled := true;
end;
oops. i should have known. after all i said it: a disabled control is not "focused" - barely ten lines ago! when the richedit is enabled again, we also have to setfocus back to it. shees.. :-)
begin
myre := trichedit(sender);
myre.enabled := false;
~~~~~~
myre.enabled := true;
myre.setfocus;
end;
try it again. this time things are working better, and we're leaving poor old edit1 control alone. thats good practice, as it may have had an [onfocus] event that does wierder things than what we're trying to do. maybe not now, but it could in the future!
marks: 10/10
on the other kind, some of you may have found instead the em_hideselection message in the win32.hlp. if you had delved in, you would have found something very interesting. the delphi hideselection property only implements half the capabilities of this message. you can also, by calling it direct, tell it to temporarily hide the black stripe even when the control has the focus. so instead you could use the following lines of code:
begin
myre := trichedit(sender);
myre.perform(em_hideselection,1,0);
~~~~~~
myre.perform(em_hideselection,0,0);
end
yummy. nice clean coding:
death to the flicker
the next major problem is this bloody flicker. you should pop back into delphi for a second, and types some lines in its editor, to see if it flickers at all. it does. but only when it is changing colors when it recognizes a change has occured. otherwise it doesn't bother. now look at what’s happening in our "editor". do you see?
the problem is that we are not "conserving" what we are doing. if something is still the same tokentype it doesn't need to be re-highlighted because it already correct on the screen. we need to check if the tokentype of each token has changed since last time we repainted this line, and only then repaint to.
in fact we don't need to do even that - we can just check whether the selattributes (which represents the current selection's attributes) is any different from what we want to change it to i.e. fparsefont[mytokentype]. this way if even the tokentype had changed, but the new and old tokentype shared the same display attributes, we would still conserve our drawing.
| actually the problems is that the richedit isn't doing the conserving. in the old text based system i used to use, if you printed something to the screen, and it was the same as something already on the screen, in the same position, then the program would not rewrite it to the screen. it would "conserve" the amount of writing it did, as in the old days 1200 baud screens were slow, and printing the same characters was a waste of time.
huh - and people said we have come so dar with windows. sloppy, sloppy, sloppy i say! :-) |
