Creating a docked window from a background thread

[dail]

AFAIK it is not shown by default. You might check your config.xml file because it stores information about docked dialogs (position, visibility, etc). It might think it is supposed to be open already.

[Vitaliy Dovgan]

Nope! In the “config.xml” there is:

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…

[dail]

My LuaScript plugin uses a docked dialog and is not shown by default (assuming the config.xml doesn’t contain any info about it).

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

[Claudia Frank]

@Vitaliy-Dovgan

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

[Vitaliy Dovgan]

Ah, looks I’ll need to debug Notepad++ to understand what is wrong.
Which is not straightforward because I’m having exactly the same issues with VS 2013 Express as mentioned here:
https://notepad-plus-plus.org/community/topic/11388/errors-building-current-repository
If you ask my opinion, I’d rather suggest to get rid of these CStringW in Notepad++'s code - these things are not true and pure Win API way!

[Claudia Frank]

If you aren’t concerned about the new license agreements I would use the community edition
as this should behave like the pro versions.
If you still want to use express - didn’t the changes help?

Cheers
Claudia

[dail]

@Vitaliy-Dovgan

Try calling NPPM_MODELESSDIALOG first.

[dail]

Actually, if you look in Notepad++'s source where it uses these messages internally it normally calls:

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.

[Vitaliy Dovgan]

@Claudia,
Yes, installing the WinDDK fixes that.
Though, as I said, I really don’t like Notepad++ to use ATL. Moreover, it’s just for a small feature, which could be rewritten.

@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 :(

[dail]

That’s interesting. Can’t say I know for sure why that is calling createToolbar(). My plugin also uses a toolbar icon but it registers it during NPPN_TBMODIFICATION.