@Dail,
I’ve found the root cause. It’s because my plugin has a toolbar icon and here is what Notepad++ does with it:

in DockingManager::createDockableDlg:

_vContainer[iCont]->createToolbar(data);

where DockingCont::createToolbar calls DockingCont::viewToolbar, where the following is done:

// show dialog and notify parent to update dialog view
if (isVisible() == false)
{
	this->doDialog();
	::SendMessage(_hParent, WM_SIZE, 0, 0);
}

So the docked dialog is forced to be shown by that code :(

1. NPPM_MODELESSDIALOG with MODELESSDIALOGADD
2. NPPM_MODELESSDIALOG with MODELESSDIALOGREMOVE
3. NPPM_DMMREGASDCKDLG

I think 1 and 2 are just a side effect of how the class inheritance works within Notepad++. So, it would appear that NPPM_MODELESSDIALOG may not even be needed for docked dialogs. I will look into this more if I get a chance.

Try calling NPPM_MODELESSDIALOG first.

Cheers
Claudia

that is strange, indeed.
Npp, does more or less the same checkings before creating the dialog

	case NPPM_DMMREGASDCKDLG:
	{
		tTbData *pData = reinterpret_cast<tTbData *>(lParam);
		int		iCont	= -1;
		bool	isVisible	= false;

		getIntegralDockingData(*pData, iCont, isVisible);
		_dockingManager.createDockableDlg(*pData, iCont, isVisible);
		return TRUE;
	}

…

bool Notepad_plus::getIntegralDockingData(tTbData & dockData, int & iCont, bool & isVisible)
{
    DockingManagerData & dockingData = (DockingManagerData &)(NppParameters::getInstance())->getNppGUI()._dockingData;

    for (size_t i = 0, len = dockingData._pluginDockInfo.size(); i < len ; ++i)
    {
        const PluginDlgDockingInfo & pddi = dockingData._pluginDockInfo[i];

        if (!generic_stricmp(pddi._name.c_str(), dockData.pszModuleName) && (pddi._internalID == dockData.dlgID))
        {
            iCont				= pddi._currContainer;
            isVisible			= pddi._isVisible;
            dockData.iPrevCont	= pddi._prevContainer;

            if (dockData.iPrevCont != -1)
            {
                int cont = (pddi._currContainer < DOCKCONT_MAX ? pddi._prevContainer : pddi._currContainer);
                RECT rc;
                if (dockingData.getFloatingRCFrom(cont, rc))
                    dockData.rcFloat = rc;
            }
            return true;
        }
    }
    return false;
}

…

void DockingManager::createDockableDlg(tTbData data, int iCont, bool isVisible)
{
...
// if floated rect not set
if (memcmp(&data.rcFloat, &rc, sizeof(RECT)) == 0)
{
	// set default rect state
	::GetWindowRect(data.hClient, &data.rcFloat);

	// test if dialog is first time created
	if (iCont == -1)
	{
		// set default visible state
		isVisible = (::IsWindowVisible(data.hClient) == TRUE);
...

This would lead to the assumption that you might, maaayyyybeeee, checked
the false config.xml?? I know you are familiar with npps configuration
but, at least for me, sometimes you don’t see the wood for the trees.

Cheers
Claudia

Take a look at this section of code which is how I’ve been doing it.

isVisible="no".

And here is some verification code:

::OutputDebugStringA(::IsWindowVisible(hDialogWnd) ? "1. Visible\n" : "1. Not visible\n");
SendNppMsg( NPPM_DMMREGASDCKDLG, 0, (LPARAM) &dockData );
SendNppMsg( NPPM_MODELESSDIALOG, (WPARAM) MODELESSDIALOGADD, (LPARAM) hDialogWnd );
::OutputDebugStringA(::IsWindowVisible(hDialogWnd) ? "2. Visible\n" : "2. Not visible\n");

It shows:

1. Not visible
2. Visible

If there was isVisible=“yes” in the “config.xml”, there would be an additional explicit call of the function which functionId was specified as the dockData.dlgID. But in my case isVisible=“no”, there was no explicit call of the plugin’s function - but the docked window became visible…

Though there’s another thing I don’t understand, this time in Notepad++. Why a docked dialog becomes visible immediately after NPPM_DMMREGASDCKDLG and MODELESSDIALOGADD? I mean, logically MODELESSDIALOGADD means “add a dialog” - correct? - so a dialog should not be shown before NPPM_DMMSHOW is sent explicitly!

For me it sounds like you are running into some kind of race condition.
One thread might receives the window messages whereas the other
threads expect it. Did you check this?

Cheers
Claudia