Some Fixes

Topics: Developer Forum, User Forum
Sep 12, 2009 at 5:51 AM

Hello,
I have worked with the Scintilla in the C/C++ and currently looking into the ScintillaNET as
an addin for SharpDevelop, and Sandcastle Assist projects.

I have "fixed" some issues with the sources and posted it in the Issue Tracker:
http://scintillanet.codeplex.com/WorkItem/View.aspx?WorkItemId=24622

1. Cursor Handling
Currently, when you click in the editor to position the caret, the cursor changes between the default
arrow of the control and the I-Beam of the editor.
Simply put, there is a conflict between the two; the .NET Control handling of the cursor and the Scintilla.
The initial fix was simply overriding the DefaultCursor property of the Control and returning the Cursors.IBeam.
This works, but when you try selecting text using the selection margin, the cursor changes to IBeam.
The final fix is to stop the Control cursor processing in the WndProc.

2. Unsafe keyword
Somehow I do not like using the unsafe keyword unless there is no other means of handling the issue or as
in the image processing, there is a significant speed difference.
In the loaded codes, I eliminated all uses of the unsafe keyword, and also used the SendMessage instead of
the DefWndProc, since they are not really the same thing and MS documentation advice against such uses.

In all my tests so far, I have not yet found any issue with the fixes and will continue to test them. I have uploaded
the projects so that others could verify.

Best regards,
Paul.

Coordinator
Oct 14, 2009 at 6:53 PM

Also jacobslusser and I discussed the whole DefWndProc vs SendMessage. It really is kind of dumb to be invoking DefWndProc but instead of going with SendMessage we're going back to DirectFunction/DirectPointer method as described here. The threading issue shouldn't be anything new to other developers since all other WinForm controls work the same way.

Oct 14, 2009 at 11:24 PM

Chris,
Surely the DirectFunction/DirectPointer is better and faster by the Scintilla documentations.

But I decided on the SendMessage for two reasons
1. Automatic support for the 64-bit platform, so that the ScintillaNET will still be compiled with AnyCPU.
   If I hard-code "SciLexer.dll" for the P/Invoke, it could lead to problems.

2. Design mode support.
    I have not reported this, but the ScintillaNET does not actually work in the design mode unless you
    have SciLexer.dll on the global path. I started having the problems when I was compiling for the 64-bit
    and renamed the SciLexer.dll, SciLexer32.dll and SciLexer64.dll.
    After tracing it, it turns out that ScintillaNET was loading the SciLexer.dll installed by my TortoiseSVN :(
    in the design mode all along.

For the design mode problem, I tried the C++/CLR mixed mode solution suggested in the Issue Tracker,
but this also failed, so I decided to compiled the whole Scintilla into a .NET dll using CLR option of the
C++ compiler (call it Scintilla.dll), with added a static function to register the Scintilla window class. This
Scintilla.dll is then used by the ScintillaNET written in the C#.

Another point that helped me settled on the .NET dll using CLR is that I was trying to extend your idea of
custom painting to the margin markers. But this does not play well with the Scintilla, your approach continuously
paints even though the Scintilla itself is not painting, which I think will slow down the Scintilla.
I went back extended the Scintilla itself so that in addition to the current standard markers and XPM markers, it could
accept user callback, which could then be created as delegate on the .NET and used to paint the markers. It worked
and I proposed it to Neil for the Scintilla, but was not accepted on the grounds that the solution does not include
the other platforms supported by the Scintilla, which I currently do not have the means to work on (especially the
MAC-OS version). With this approach too, the DirectFunction/DirectPointer could be used as part of the C++/CLR
wrapper.

The current problem is how to handle the automatic 64-bit with this approach (Problem 1)  (i.e. automatically selecting
the 32-bit or 64-bit versions of the Scintilla.dll depending on the platform) - still thinking about how
to set the projects to handle this. For now, I just decided to compile the Scintilla.dll as x86 (since it will work on the
64-bit OS too) until I find a good solution. Anyone reading this who has a better idea, please help! (a little commercial).

Best regards,
Paul.

Coordinator
Oct 14, 2009 at 11:49 PM

For the design mode problem, I tried the C++/CLR mixed mode solution suggested in the Issue Tracker,
...

Are you referring to this? I haven't explored that project yet but I planned to. If you have an improved version of it I'd love it if you posted the project to that issue.

Another point that helped me settled on the .NET dll using CLR is that I was trying to extend your idea of
...

Too true. I had a very hard time getting custom painting to work with Scintilla. I also remember seeing that feature on the Scintilla boards. If we ever decided to completely fork the Scintilla implementation we could do some really cool things and also get around a lot of the clunkyness that exists today. Problem is propagating changes when the main Scintilla changes and basically loosing all support from Neil.

I wish I could help out on the whole 32/64 problem but I've don't really have the experience. I don't even have any 64bit hardware to start learning on. I should go out and get one though, I can find old refurbished AMD Sempron64 for under $200 USD.

Good luck and thanks for all the insight you've provided

Oct 15, 2009 at 1:23 AM

Chris >> Are you referring to this?
Yes, I was thinking the single combined dll could solve the problem.
I did not create improved version, I tried several things with it, but could not solve the problem.

Chris >> Problem is propagating changes when the main Scintilla changes and basically loosing all support from Neil.
So far, I only planned to extend the support to your indicators, and so the changes could easily be marked and updated
with new releases of the Scintilla, it is not a fork.

Chris >> ...but I've don't really have the experience. I don't even have any 64bit hardware to start learning on.
Me too, no experience. I recently gave up my Pentium 4 machine (loved slow machine for development) for Core2Duo,
and that is my latest sin. Just trying to make sure my works are ready when needed, without having to do interface changes.

Chris >> Good luck...
Thanks, I really needed it :) I am doing a lot of changes to the code base, and will propose it when done as another
version branch, since it is not going to be compatible with the current.
If not accepted, I could keep it as a fork, NScintilla. Hope at least you will find something there useful for ScintillaNET.

Best regards,
Paul.

Coordinator
Oct 16, 2009 at 7:06 AM

mkay I did some investimigating and found that my processer is 64bit. In fact most newer processors are these days. I'm just running 32bit Windows. Furthermore with VMWare can run a 64bit guest on a 32bit host. Yes you read that correctly, I was quite shocked and didn't fully believe it.  Except that I'm now running XP 64 on my Win7 32 host as I type this.

This is wonderful because now I can ensure full 64 bit compatibility in ScintillaNet.

 

Oct 16, 2009 at 8:21 AM
Edited Oct 16, 2009 at 8:22 AM

Chris >> mkay I did some investimigating and found that my processer is 64bit.
Nice you read my post well. Most people still do not know they are using 64-bit and running 32-bit OS/applications.
I intentionally mentioned the Core2Duo, since I know most developers use that.

Chris >> This is wonderful because now I can ensure full 64 bit compatibility in ScintillaNet.
Have fun, and let me also now say, Good luck :)

Also, if you have Vista Ultimate retail, there is 64-bit on the DVD. For all other editions, MS will send you a 64-bit Vista if you
fill a form online.

Best regards,
Paul.