Decoupled CompletionList and MethodCallTip from Scintilla.

[Neverbirth]

• This includes removing the controls from the MainForm, so they can be used in floating panels, dialogs, etc.
• Removed Backspace from being a shortcut, it didn't make any sense.
• Several UX improvements.
• ScintillaControl a bit more similar to newest (old) ScintillaNet control.
• This also changes the behaviour of shortcuts like Ctrl+Space to only work if the editor is focused. Plus backspace could also trigger some special functionality when in other panels.

There is always room for improvement in some places, but maybe not worth it at the moment. And as said back in the day, custom scrollbars are lost for the moment. More details in the complete old PR: #1020

[elsassph]

@Meychi can you give it a try on crossover?

[elsassph]

I'm going to give it a try asap to code at work and then merge if nothing explodes.

[elsassph]

Trying the PR and I still get the custom scrollbars.
Great job BTW, having the list finally following the scrolling is really cool.

[Neverbirth]

Yes, the custom scrollbars are there, but are over scintilla, so it's not working 100% as it should, because the caret can go below the scrollbars and the user cannot see what is in the current line.

[elsassph]

Ow this is awkward - can't you reserve the space for the scrollbars?

[Neverbirth]

Well, it's "not" possible, the custom scrollbars are normal controls, and therefore have to be inside the client area to be visible (system scrollbars are outside the client area), but since we are inside the control itself, the client area has to fill the whole space.

Some ways around it (and for any other control):

1. Not adding the scrollbars to the control itself. The "simple" way (not so simple on escenarios with complex layout schemes), I don't like this method myself, plus maybe we'd have to wrap the controls inside other control, and bubble a lot of properties, methods, events...
2. Modify the client area, and draw the scrollbars ourselves over the non client area. This one looks like a nice option, good for every control, but requires a lot of interop (really, a lot).
3. Leave the scrollbars over the client area, and catch when we are going to run below them, and scroll ourselves. A lot of programs nowadays behave like this, with semi transparent scrollbars or the like, I don't know if it may be too tricky to implement, but for several controls we may not even need interop at all. I don't know for Scintilla how this would behave.

[elsassph]

For 3. there's a built-in option:

sci.SetYCaretPolicy((Int32)(CaretPolicy.Slop | CaretPolicy.Even | CaretPolicy.Strict), 1);

[wise0704]

@elsassph That is one solution assuming that the height of the vertical scroll bar (17px) is approx. the height of one line.
Problems are that firstly the current y-scroll policy (Jumps|Even) is lost, and secondly with small fonts the text still hides below the scroll bar (second problem could be fixed by changing the slop value according to the text size however).

[Meychi]

Does this present a breakage in the PluginCore? I tried to look but im not 100% sure.

[Neverbirth]

It should be backwards compatible, if that's what you mean. But I really wonder if there are many plugins using the affected part, I only know of one, and it isn't using it directly.

[Meychi]

By previous experiences we should expect the worst.

[Neverbirth]

Conflicts fixed yesterday.

[Meychi]

On a quick test i noticed that the used font in the hint is incorrect. Also you removed Focus event which could lead to problems if a plugin hooked to that event. What about the scrollbar issue?

Otherwise everything seems ok.

[Neverbirth]

The font issue is already fixed by Philippe in his local repository, so I didn't look into it. The focus event logic is removed, because now it's handled by .NET itself in the standard way as any other user control. The scrollbar issue I'm not fully sure, I know Philippe and Daniel looked a bit into it but I cannot tell how is it, I'd say Scintilla offers enough control and information to do it.

EDIT: Yes, you are right that if a plugin uses the old Focus event it would break, but I didn't see any (compatible with FD5 itself, for FD4 I saw some) and I'd prefer to remove the code, but it could be possible to add it rerouting it to the native .NET event.

[Meychi]

Ok, so Philippe finishes this?

[Neverbirth]

Oh, in Win 8+ or high dpi (I don't know exactly which one, or if both of them, also I don't know if it happens already with this branch, or only with the added changes by Philippe) there is a problem that pop ups randomly with the call tip. I'm working on something related, so I don't know if he prefers to wait for it.

[Meychi]

This needs to be rock solid and not introduce any compabity issues before merge. I will now test this and current dev in CrossOver.

[Neverbirth]

So what happened with CrossOver? I couldn't find any problem on Win7 so far (this was done near a year ago, and was tested for months back then, but I've been using it again just in case there was some problem because of some newer commits). Would be nice to see it already merged as is, the rest of the problems are being worked on, and it will allow me to make some new PRs.