|Thanks very much Frankie-C, that information is (I hope) fairly indicative of what I've been suspecting (actually dreading) about this whole fiasco since shortly after it began..
And that is that I don't think the 64-bit Shell_NotifyIcon() works.. like, at all..
That's the only logical explanation that I can think of for what I'm seeing (and what you're saying)..
So this is good; this is progress..
Fortunately, the manifest resource issue that you mentioned is easily rectified. Just add the following #pragma in your StdAfx.h:
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' "\
"version='188.8.131.52' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
Then set the following option in your Project Property Page:
Linker ==> Manifest File ==> Generate Manifest ==> Yes (/MANIFEST)
and voila! No need to create a manifest resource.. Assuming, of course, that you're using some reasonably recent version of Microsoft Visual Studio..
Of course, as you may have already surmised, I'm telling you this in the hope that you'll try compiling your code in 64-bit, and apprise me of the results that you get..
If my suspicions are correct, your code, like mine, won't work in 64-bit..
If I'm wrong about that, then that would be almost as good (actually better in the long term). Then I'll just take your code verbatim, and start adding in bits of my other stuff until it fails. In my experience, bugs are rooted out far more easily when you're adding to code that works, as opposed to attempting to subtract from code that doesn't..
But I kinda need to know that the 64-bit Shell_NotifyIcon() works for someone, *anyone*, before I go down that (very long) road.. Because at this point, I don't think it will..
Anyway, thanks again for your help. I see that you're still insisting on a static NID as opposed to a static NID pointer.. Well, six of one, half dozen the other - you know. The reason I made it a pointer (and yes, in my own code, it's still a pointer) is because the whole System Tray thing is an End-User option, so why allocate memory that might never be used? And because making it a pointer allows it to double as a kind of boolean - if it's not NULL, it means that all steps of the initialization succeeded, and if it is NULL, then don't use it at all.. Kind of an all-or-nothing approach..
And last and least, I think we both know that that silly "Opning" variable doesn't need to be in either your code or mine. To be sure, it still serves a purpose in my original code, but I left it in here (this forum) only out of respect for the narrative - it is completely superfluous..
Anyway, I'm being far too verbose - it's late; too much coffee.. Need to..