Actual request:
Export a function like:
Scintilla::IDocument * dllexport CreateDocument ();
from Scintilla DLL.
And base the Internal::Document class on a limited public interface so we can operate on a document with no views.
Scintilla_DirectFunction gives precedent to direct functions existing.
Background:
We've been using Scintilla for many years now, and recently I was having a clean up of our codebase. One thing that is strange, is that we have a doc/view model (MFC initally, but we cannot load the text into the document until the view is created. This is clunky, but we can work around it.
But we have a command line tool that needs all the scintilla wrapper classes linked into it in order to load our text as well.
We can create a Document once we have a ScintillaWnd, but not before. We can't create it independently.
(Think of it like the C++ code editor for your favourite IDE)
What goes into the 'limited public interface'? It has to be a subset that is likely to be viable for a lengthy period. Include too many methods and it starts to constrain the development of
Document. There are around 200 public methods inDocument.Since C++ ABIs can differ between compilers (and even between release and debug mode), C++ classes, including standard library classes, can't be used in an interface between executable and DLL. This is similar to
IDocumentwhich is passed to lexers which are commonly in another DLL/so.IDocumentis meant for lexers so contains no document text changing methods.ILoaderis a limited preparatory view on aDocumentjust for loading.The stability of
IDocumentcan get in the way of changes:Document::StyleAtNoExceptexists just becauseIDocument::StyleAtcan't havenoexceptadded until the next major version and its limited compatibility break. Having a specified calling conventionSCI_METHOD==__stdcallforIDocumentmay also obstruct optimizations.Weird I didn't see notifications for this! Sorry for my delay. (That's me issue, not you, just explaining my lack of followup).
Yes, you do raise good points. For my own purposes, I'd just need the ability to load / access text. Accessing text is already needed by lexers, so really only adding a SetText method would do for me. But I understand that brings in the need for a lot more, like enabling undo history etc.
The altenative I thought of was to create a zero sized invisible window, configure it, load into it, detach the IDocument then destroy the window, giving me what I wanted - but it seems rather clunky.
If you have a view, you can create an ILoader that is initially independent of any view while loading and which can then be moved into a view.
A Message-Only Window may work here but I've never tried it.
Another issue with having view-independent documents is that encoding-sensitive features, like case-independent searching, are implemented with platform-specific character-set translation provided by view objects.
Here's my attempt at a limited editable document interface:
Implemented a simple initial provisional implementation of
IEditableDocumentwith justDEVersion,AddRef, andReleasemethods as [2af035]. Still needs a view to callSCI_CREATEDOCUMENTor similar on.Related
Commit: [2af035]