Ah, silly me, disregard that code. I was working around the issue but I didn't have to, here's the correct code:
foreach (ubyte[] buf; file.byChunk(4096)) { sendEditor(SCI_ADDTEXT, buf.length, cast(LPARAM)buf.ptr); } Now, the explanation. The sendEditor function takes an opcode (uint), and 2 arguments. It uses message passing to communicate with scintilla, the two arguments are aliased to uint (which is usually a length argument but is sometimes ignored) and LPARAM (a pointer's address as ULONG). Scintilla converts the address back to a pointer, and passes it (and the first argument) to the relevant function based on the opcode. Here's the header of that function: SCI_ADDTEXT(int length, const char *s) The reason my first code was working is because the wrapper has two overloaded sendEditor functions. With one you can pass an opcode, a length and pointer address, with the other you can pass an opcode, a length and a string, and the function makes a copy of the string, adds a null terminator and uses its address and the other arguments to send a message. The ADDTEXT function creates a copy of the pointed-to contents to it's internal scintilla buffers, so I don't have to keep any pointers around after the call. I hope I've explained this right (and didn't mess something up). :p On Mon, Sep 13, 2010 at 3:47 AM, BCS <n...@anon.com> wrote: > Hello Andrej, > >> Here's a little snippet of code that interfaces with Scintilla (it >> works btw.): >> >> File file = File("test.txt", "r"); >> foreach (ubyte[] buf; file.byChunk(4096)) >> { >> sendEditor(SCI_ADDTEXT, buf.length, (cast(char[])buf).idup); >> } >> The cast looks ugly, but I *have* to send a copy. > > What do those have to do with each other? > >> Am I doing it right, > > It doesn't seem right to me either, because you are allocating memory in > chunks and passing it to C without keeping pointers around. Also what does > that function do with them? If it keeps them around, you might be faster to > load the whole file in one go and make a single call (fewer allocations, > fewer calls, no-extra memory usage, etc.) > >> or can I make this a bit simpler? Otherwise I can use file.byLine, but >> I think this would be much slower (unless D reads the entire contents >> at once into memory, but I think it does not). >> >> Actually, I shouldn't even complain. I can't believe how easy it is to >> open a file, use buffers and send it all to a C interface. This is a >> 4-liner, the C equivalent spans 20+ lines. Ha! >> > -- > ... <IXOYE>< > > > >