rnfnCodeLite
Current 'Public' View
public sealed class rnfnCodeLite : Control{ // Methods public rnfnCodeLite(); // Properties public bool AutoIndent { get; set; } public Color BacklightColor { get; set; } public Color BorderColor { get; set; } public Color CaretColor { get; set; } public Icon CollapsableIcon { get; set; } public Icon CollapsableRegionIcon { get; set; } public Icon CollapsedIcon { get; set; } public Icon CollapseEndIcon { get; set; } public string ExternalEditorTitle { get; set; } public Color GutterColor { get; set; } public Lexer Lexer { get; set; } public Library Library { get; set; } public Color LineNumberColor { get; set; } public bool NoTabInput { get; set; } public bool OptimizeCaretDrawing { get; set; } public Color OptimizedCaretColor { get; set; } public Image PopOutImage { get; set; } public Color SelectionBackColor { get; set; } public Color SelectionForeColor { get; set; } public bool ShowBar { get; set; } public bool ShowCollapse { get; set; } public bool ShowIcons { get; set; } public bool ShowLineNumbers { get; set; } public Image StickyImage { get; set; } public Color UnfocusedBacklightColor { get; set; } public bool VirtualSpace { get; set; }}As you can tell, most of the interaction with the control will be via properties, in addition to the methods provided by System.Windows.Forms.Control. Note that these aren't all the properties, as I still plan on overloading Text(and in fact have the code still from before the rewrite) so that the line-by-line format implemented inside rnfn.Controls.CodeLite.Text will be transparent to the user. The actual text will be sent and received as a String type. Granted, this may change at some point as it deters from the ability to read large files. If it does, it probably won't be till after the first 'major' release of the control.
Scrollbar Deadspace
I talked about this in my last post. I've actually implemented it(thus the title of the post) already, and it is functional. I went with the popup function in the 'root' class and the ability to toggle whether the form/window is on top. At the moment, there are just two ugly icons(both 16x16 and monochromatic), but, like the icons used in the collapsing code feature, they can be changed(though, if you'll notice, the properties say image, not icon). Also, there is currently no 'seperate' icon to help indicate whether the external editor is on top or not(it seems it would be fairly obvious whether it was or not, but I might end up putting this 'feature' in as well.)
While you can change the title of the external editors' forms/windows, you can not, as of yet, change the icon displayed in the taskbar. I'm currently debating whether or not I should allow this to be set like the other image/icons or whether I should just remove the external editor from the taskbar display.
Other things I'm currently considering with the external editor feature involve the code-end of the control. For now, there is no keeping track of the external editors, which means you can't bring them all to the front nor can you close them all if the user so wishes. This is probably something I should implement... Also, there is the fact that this is 'forced' upon the person using the control in their application. Should this be a 'forced' feature, or should it be optional, and if it isn't turned on, just leave the deadspace dead? It'd be easier for it to be forced. :/
LITE aspect
I haven't really been giving any specs about the LITE aspect of rnfnCodeLite, so here goes. At the moment, with everything mostly-untestedly implemented except for keyboard and mouse interactions(as far as I can recall, at the moment), the Release .dll of the control is 25,600 bytes(28,672 bytes on disk, about 10kb compressed). Not overly large, and I'm hoping to keep it under, say, 50-64kb overall. Definately don't want it going over 100kb, personally. Note that this includes the resources, which are currently six monochromatic 16x16 icons. I believe this accounts for ~3kb.
As far as memory usage, I haven't been testing that, really. I've noticed that an empty Form runs at about 7-8MB on my computer, while throwing in the control bumps that up to 11-12MB. So I'd say it is roughly about 4MB of memory used, and we haven't even gotten to the actual text editing part! I'm not sure how this rates, whether it is good or bad, and what I can do to fix it, but I'm not wanting it to be overly large in memory usage, either.
[Edit: Silly me. The form was running in visual studio's host. When run from a compiled executable, the entire thing is about 4MB, form and control. Granted, this is after minimizing/restoring the window, but still. A quick test shows that removing the control from the form, and minimizing/restoring it, causes the mem usage to be about 3MB. So I guess the control, at the moment, takes about 1MB up. Not as bad as I'd thought.]
I've got all night, if I don't blow it, and most of tomorrow to work on this, so if I buckle down(HA!), I should be able to get a substantial amount done.
Also, somebody needs to tell benryves that he needs to post more.
Are you only using C# for your project?