Auto-Completion Popup is unexpectedly shown when handling SCN_CHARADDED

Coises

@Vitalii-Dovgan said in Auto-Completion Popup is unexpectedly shown when handling SCN_CHARADDED:

Could you suggest why the Auto-Completion Popup is shown and what can I do to prevent it to be shown? Or, at least, to detect that it is shown and then to hide it immediately?

I don’t have an answer to your question, but maybe a place to get started.

Notepad++ processes Scintilla notifications here; it sends notifications to the plugins first, then sends them to its own processing routines. The routine for SCN_CHARADDED is here. The plugin notification routines (here calling here) copy the notification to make sure the plugin can’t change it.

At least that should give you a clue where to look to follow what Notepad++ is doing and see if you can find a way to suppress the unwanted behavior.

Vitalii Dovgan

Hmm, yes, Notepad++'s SCN_CHARADDED handler explicitly shows the Auto-Completion Popup:

Buffer* currentBuf = _pEditView->getCurrentBuffer();
if (currentBuf->allowAutoCompletion())
{
	AutoCompletion* autoC = isFromPrimary ? &_autoCompleteMain : &_autoCompleteSub;
	bool isColumnMode = _pEditView->execute(SCI_GETSELECTIONS) > 1; // Multi-Selection || Column mode)
	if (nppGui._matchedPairConf.hasAnyPairsPair() && !isColumnMode)
		autoC->insertMatchedChars(notification->ch, nppGui._matchedPairConf);
	autoC->update(notification->ch);
}

And what is even more interesting, the _pluginsManager.notify(notification); sends a copy of the notification to plugins. Which means there’s no sense to modify e.g. notification->nmhdr.code inside a plugin.
So… Seems I have two options:

temporarily tune some settings to make currentBuf->allowAutoCompletion() return false;
find a way to hide the AutoCompletion Popup if it was shown.

Some hint or additional advice of how to achieve that would be appreciated.

Coises

@Vitalii-Dovgan said in Auto-Completion Popup is unexpectedly shown when handling SCN_CHARADDED:

hint

Well, there is a “nuclear option”…

Nothing stops a plugin from using SetWindowSubclass to subclass the main Notepad++ window in order to intercept and preprocess messages.

Example:

I say “nuclear option” because you really need to be careful that you’re not messing up expectations for some other function or plugin. This should be a last resort, because it leaves you free to mess things up entirely.

Vitalii Dovgan

Ah, yes, I believe it is something similar to SetWindowLongPtr with GWLP_WNDPROC. I did it in NppExec many years ago and have forgotten about this approach :)
Well, if there will be no easier option suggested, then I’ll take this way. Thank you!

Vitalii Dovgan

I’m preparing a big update to XBrackets Lite, by the way, hence mentioning the quote characters.
Now it will inherit more functionality from XBrackets for AkelPad.

Ekopalypse

@Vitalii-Dovgan

I assume you could also use SCI_CHANGEINSERTION within the modified notification.
To do this, however, you must request the necessary additional SC_MOD_INSERTCHECK in nppn_ready.

Vitalii Dovgan

@Ekopalypse

Thank you, SC_MOD_INSERTCHECK is an interesting way indeed.
In this case, how can I understand whether SC_MOD_INSERTCHECK is the result of a character being typed or the result of pasting from the clipboard?

Ekopalypse

@Vitalii-Dovgan

being typed or the result of pasting

hmm … I think you need to subclass the Scintilla control and check for the WM_PASTE message. The scintilla api, to my knowledge, has no way of letting you know that. But is it even important to know the difference?

Vitalii Dovgan

@Ekopalypse
In terms of XBrackets behavior, the difference between typing and pasting is important.
When a user types ‘[’, XBrackets will autocomplete it with ‘]’.
When a user pastes “[”, XBrackets will not react.

Vitalii Dovgan

Eventually, it seems the best solution is to subclass Scintilla’s WndProc (for both Main and Secondary Scintilla window) and to handle WM_CHAR there.
The benefits:

no need to bother with Scintilla’s native notifications and their nuances;
full control and clarity of what happens and when it happens: within own WM_CHAR handler, we are able to process a character before it goes to Scintilla and after it goes to Scintilla;
simplified code because all the logic is controlled by you and there is no need to conform to Scintilla’s way of processing the events.