From 4a5e9654ce0c4a6cd6c1aff452f8f9344a9849a6 Mon Sep 17 00:00:00 2001
From: Neil Last edited 10 January 2018 NH Last edited 31 January 2018 NH There is an overview of the internal design of
Scintilla. SCI_CREATEDOCUMENT → document * SCI_CREATEDOCUMENT(int bytes, int documentOption) → document *Scintilla Documentation
-
@@ -5711,7 +5711,7 @@ sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
-
+
+
This message creates a new, empty document and returns a pointer to it. This document is not
- selected into the editor and starts with a reference count of 1. This means that you have
- ownership of it and must either reduce its reference count by 1 after using
+ selected into the editor and starts with a reference count of 1. This means that you have
+ ownership of it and must either reduce its reference count by 1 after using
SCI_SETDOCPOINTER so that the Scintilla window owns it or you must make sure that
- you reduce the reference count by 1 with SCI_RELEASEDOCUMENT before you close the
- application to avoid memory leaks.SCI_RELEASEDOCUMENT before you close the
+ application to avoid memory leaks. The bytes argument determines
+ the initial memory allocation for the document as it is more efficient
+ to allocate once rather than rely on the buffer growing as data is added.
+ If SCI_CREATEDOCUMENT fails then 0 is returned.
The documentOption argument may be used in future versions
+ to choose between different document capabilities which affect memory allocation and performance.
+ The only valid value for now is SC_DOCUMENTOPTION_DEFAULT (0).
SCI_ADDREFDOCUMENT(<unused>, document *doc)
This increases the reference count of a document by 1. If you want to replace the current
@@ -5765,7 +5772,7 @@ sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
SCI_CREATELOADER(int bytes) → int
+ SCI_CREATELOADER(int bytes, int documentOption) → int
An application can load all of a file into a buffer it allocates on a background thread and then add the data in that buffer
@@ -5774,13 +5781,17 @@ sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
To avoid these issues, a loader object may be created and used to load the file. The loader object supports the ILoader interface.
- SCI_CREATELOADER(int bytes) → int
+
SCI_CREATELOADER(int bytes, int documentOption) → int
Create an object that supports the ILoader interface which can be used to load data and then
be turned into a Scintilla document object for attachment to a view object.
The bytes argument determines the initial memory allocation for the document as it is more efficient
to allocate once rather than rely on the buffer growing as data is added.
If SCI_CREATELOADER fails then 0 is returned.
+ The documentOption argument may be used in future versions
+ to choose between different document capabilities which affect memory allocation and performance.
+ The only valid value for now is SC_DOCUMENTOPTION_DEFAULT (0).
+
ILoader
@@ -6573,7 +6584,7 @@ sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
On GTK+, there are storage and performance costs to accessibility, so it can be disabled
by calling SCI_SETACCESSIBILITY.
-
+
@@ -6603,7 +6614,7 @@ sptr_t CallScintilla(unsigned int iMessage, uptr_t wParam, sptr_t lParam){
-
+
Lexer
If you define the symbol SCI_LEXER when building Scintilla, (this is sometimes
@@ -6894,7 +6905,7 @@ With Scintilla 4, 64-bit builds define these as 64-bit types to allow future imp
Methods that return strings as const char * are not required to maintain separate allocations indefinitely:
lexer implementations may own a single buffer that is reused for each call.
-Callers should make an immediate copy of returned strings.
+Callers should make an immediate copy of returned strings.
--
cgit v1.2.3