Have you ever written your own edit field-like control? I have (called the code editor in REALbasic)! I learned something new today with regards to this feature, and so... time to blab!
When the System font was switched to Tahoma, I started to notice an odd behavior in the code editor. The caret (the blinky line thinger that shows the current position) would cover up part of certain letters due to placement. This annoyed me because it was harder to read some code when the cursor was on part of the text since the cursor would obscure the glyph.
So I started looking into our cursor code, and I noticed that we almost had it right. The problem was that we weren't using the OS mechanisms to handle the caret drawing. Instead, we were using Graphics.DrawLine to do it, and that wasn't correct for two reasons. 1) the blink time wasn't correct, and 2) it wasn't drawing the line in XOR mode.
I did a bit of research, and learned that Microsoft has a set of APIs for doing exactly this sort of thing -- dealing with carets.
When the control gets the focus, you make a new caret and specify the size and shape. Then, you tell the system what x and y position the caret should be drawn at. Finally, you tell the system "make the caret visible." What happens then is that the system handles drawing the caret and erasing it for you. It handles all of that for you. When the caret needs to move (because the user did some typing, for instance), then you just tell the OS the new x and y location of the caret. It handles the rest. Finally, when the control loses focus, you destroy the caret.
Well that's not too shabby!
In the GotFocus event, you call CreateCaret, SetCaretPos and ShowCaret.
In the KeyDown event, you call HideCaret, SetCaretPos and ShowCaret.
In the LostFocus event, you call DestroyCaret.
And that's it. That handles all of the nuances of the caret, and what's more, it does it in a system-accessible fashion. w00t!
On a sad note, this nifty little change won't make it into r2 final because it's way too close to the end of the cycle to put a change like this in. But it was a nice way for me to wind down at work today since I head back to MN tomorrow morning. Hopefully, when someone is writing their own editor (such as a hex editor, perhaps), they stumble on this entry and do it the right way. :-)
On Macintosh, the calculations for the cursor's location used to be wrong (probably due to fractional differences?). The result was that, on long lines, the cursor would be offset by several characters from its true position.
That was fixed a while ago, fortunately. Now the code editor is very close to feeling 'native' on Mac OS X. The horizontal scroll bar is positioned too far to the right by a few pixels, and the grey borderline on the right of the code editor is missing unless the vertical scroll bar is visible, but otherwise it's masterful.
Here's what I mean:
http://www.cosmicsoft.net/RB/hscroll.png
http://www.cosmicsoft.net/RB/rborder.png
Now that I have won the ultra-nit picking award, I'll thank you again for a very excellent code editor...
Aaron,
I've wondered for some time what it took to implement such a thing, a code-completing editor, and what the relationship is between the grammar, the compiler, and the editor interface. Did you wing it? Is it spaghetti code or highly object-oriented? :) Since you obviously can't share the code itself, I wonder if there's a book you could recommend on the subject, or any other resources you used which I might be able to look at.
Thanks!
Does this have anything to do with RB text's frustrating drag-and-drop functionality?
@Daniel -- the code editor is entirely OO-driven. Unfortunately, I don't know of any books that discuss how to actually write one of these beasts.
What I can tell you about its architecture is that it's built off encapsulation to a large degree. There's the code editor itself. It knows what project item is being used, as well as which code item (method, property, etc) is currently being viewed. Code items know about their source code, so the code editor can ask the item to provide it's source. The source goes through translation into text lines, yada yada yada.
It's actually a very in-depth structure (obviously), with many, many moving pieces and parts.
@DeanG -- I have no idea what you're asking about (what's so frustrating about it?), but I'm pretty sure the two are unreleated since the only thing I changed (essentially) was the drawing of the caret.
RB 2005/6 IDE on OS X: When you drag a text block, the cursor disappears and there is no indicator where the text will be placed. In CodeWarrior, and this text box in Safari, when I've moved the block to a location that will move the text, a blinking cursor appears where the block will be inserted.
Ah -- you should file a feature request for that. This is the first time anyone's pointed it out to me (that I'm aware of), and it's certainly a reasonable request.
Whoa! Looks like someone beat me to it..
http://realsoftware.com/feedback/viewreport.php?reportid=mugbqtbn
Hi Guys,
totally of topic.
Since Rb2005 front end is written in RB I decided to have a look at RB in a text editor to see how the clever people program.
There is a lot which makes it to readable text and I noticed something. Where I would put
a="this string"+avar+bvar+cvar
you put
a = "this sting" + avar + bvar +cvar
after a while of wondering I realized it is so you can select the text easily ( I originally thought you were just being pretty). In my way double left mosue clicking has very fluky results to select a word but your way it hits it every time. Not about to change 10000 lines of code but will change the way I code from now on.
Actually there is a feature request for you. How about a nemu item in the IDE "Fix my crappy looking code and make it more professional looking". You might have to shorten it however!
Thanks
Damon