WishmasterI'm sorry, I don't think I'll be able to keep up with the discussion, because I don't have a good general picture of miranda's architecture. But "a lot of other plugins using it" sounds like a result of an initially bad design decision, rather than a reason to maintain it. Anyway I failed to find those lots of plugins using for example the
bIsVisible flag. I found only two: W7UI declared deprecated and SimpleStatusMsg which seems to just reimplement the functionality of
fnGetProtocolVisibility in an unfortunate way. I.e. if we look at the following piece of code:
for (int i = 0; i < accounts->count; ++i)
{
if (!IsAccountEnabled(accounts->pa[i]))
continue;
if (!CallProtoService(accounts->pa[i]->szModuleName, PS_GETCAPS, PFLAGNUM_3, 0))
continue;
if (!(CallProtoService(accounts->pa[i]->szModuleName, PS_GETCAPS, PFLAGNUM_1, 0) & PF1_MODEMSGSEND))
continue;
if (!accounts->pa[i]->bIsVisible)
continue;
if (hProtoStatusMenuItem[i] == (HANDLE)lParam)
{
box_data->m_szProto = accounts->pa[i]->szModuleName;
box_data->m_iStatusModes = CallProtoService(accounts->pa[i]->szModuleName, PS_GETCAPS, PFLAGNUM_2, 0)&~CallProtoService(accounts->pa[i]->szModuleName, PS_GETCAPS, PFLAGNUM_5, 0);
box_data->m_iStatusMsgModes = CallProtoService(accounts->pa[i]->szModuleName, PS_GETCAPS, PFLAGNUM_3, 0);
idvstatusmsg = TRUE;
break;
}
}then we see, that it does five (!) lookups by name for the information directly available from the
PROTOACCOUNT structure. Using a utility function similar to
fnGetProtocolVisibility could reduce the number of lookups to zero, if it was taking a
PROTOACCOUNT pointer only. Moreover there would be no need to access the fields of
PROTOACCOUNT directly.
As you can see pfnGetProtocolVisibility does something else then checking that flag
It doesn't do something else. It just does more. Btw. it's functionality is limited to evaluating the fields of the structure. A careless programmer could decide to reimplement the functionality just because an instance of the
PROTOACCOUNT structure is already available to him (why doing a lookup by name, right?). And that would be a result of making the fields of the structure public.
For the reason specified in the first sentence of this post I refrained from some large code improvements and only fixed the two bugs: memory leak and wrong contact menus. The patch is attached. I was surprised to find out, that there's no way to retrieve a native menu handle for an account. There is
cli.pfnGetProtocolMenu, but for unclear reasons the structure defined by the returned handle (HGENMENU) does not contain the corresponding native handle. There is an ugly (fortunately nowhere used) function
FindMenuHanleByGlobalID, that does not even match it's own prototype from genmenu.h, which performs a reverse lookup. But aside from it's ugliness it's also not publicly accessible, which is good, btw.
P.S. I didn't manage to compile an installer for the latest development version and didn't want to tamper with my stable installation by converting it into some development mix. Thus I could not test the patch, but it should work correctly now.
