Re: BIG trouble with 64-bit Shell_NotifyIcon() - can anyone help? - C / C++ / MFC Discussion Boards

Message Closed

modified 30-Mar-15 8:31am.

I can't answer this without knowing the library.

That depends on the library, the implementation of that 'clock' and if it can generate some kind of signal.

Hi Everyone..

I very rarely ask programming-specific questions in public forums, but this one has me completely stumped.

I just can't seem to get the Windows Native API function, "Shell_NotifyIcon" to work, no matter what I try.

This is the Windows API function that enables an application to add its "Icon" to the Windows System Tray, aka: the "System Notification Area", and then enables it to pop up "notifications", etc..

At least, in theory..

No matter what I try however, this function always fails in my app.

And when I call the GetLastError() function to try to determine what was allegedly wrong with the call, sometimes I'll get a "timeout" error (whatever that means), sometimes I'll get an "invalid window handle" (but the handle's perfectly valid), and other times the call will actually succeed, but the very next call will fail with the same variable results..

I'm compiling in Windows 64-bit using Visual C++ Express, BTW..

I've tried calling both the ANSI and Unicode versions of this function and get the same results. I've tried specifying different "versions" to this function (it's a parameter), and I get the same results. I've tried compiling both with and without "enabling Visual Styles", but, you guessed it, same results..

And I've looked at all the sample code on the Internet that uses this function, including most of the code on this site, and without exception, none of the code I've looked at is doing anything more than my own code is doing..

Which is all, needless to say, exceedingly frustrating..

My app also changes its own execution priority, so I took that out to see if it would make a difference - it didn't..

I also came across an excellent article on Shell_NotifyIcon on the Internet:

"The trouble with Shell_NotifyIcon()"]

So I implemented a retry count, as he suggested. Unfortunately, the only difference that made was that I had to wait four seconds before I could see it fail (yet again)..

The methodology involved is this:

my Main Dialog Box's WM_INITDIALOG message handler calls this:

C++

#define TRAY_ICON_ID  0xABC  // <== ..our System Tray Icon Id
#define BALL_ICON_ID  0xDEF  // <== ..our Balloon Tip Icon Id

#define MSG_FROM_TRAY  (WM_APP + 0xDAD)   // <== ..the "callback message" ID..

static NOTIFYICONDATA *NID;

static void Init_NID( HWND hDlg )
{
    if ( NID = new NOTIFYICONDATA )
    {
         memset( NID, 0, sizeof( NOTIFYICONDATA ) );

         if ( LoadIconMetric( AppInst,
                              (PCWSTR)MAKEINTRESOURCE( IDR_TrayIcon ),
                              LIM_SMALL, &NID->hIcon ) == S_OK )
         {
              if ( LoadIconMetric( AppInst,
                                   (PCWSTR)MAKEINTRESOURCE( IDR_BallIcon ),
                                   LIM_SMALL, &NID->hBalloonIcon ) == S_OK )
              {
                   bool Opning =  // <== ..amended per "Frankie-C"..
                   strcpy( NID->szTip, "My App Name" ) &&
                   strcpy( NID->szInfoTitle, "Hi There" ) &&
                   strcpy( NID->szInfo, "My notification message.." );

                   if ( Opning )
                   {
                        NID->uTimeout = 5000;
                        NID->uID = TRAY_ICON_ID;
                        NID->dwInfoFlags = NIIF_USER;
                        NID->uCallbackMessage = MSG_FROM_TRAY;
                        NID->cbSize = sizeof( NOTIFYICONDATA );
                        NID->dwState = 0;
                        NID->dwStateMask = NIS_HIDDEN | NIS_SHAREDICON;

                        return;
                   }

                   DestroyIcon( NID->hBalloonIcon );
              }

              DestroyIcon( NID->hIcon );
         }

         delete NID;
         NID = NULL;
    }
}

The same Dialog Box procedure also calls two other Tray-related functions, Min2SysTray(), which attempts to add the Tray Icon, display a notification, then hide the Dialog Box, and ProcMsgFromTray(), which processes messages from the Tray.

All three are invoked from the same Dialog Box procedure in the following way:

C++

static INT_PTR CALLBACK MainDlg( HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
    switch ( uMsg )
    {
        case WM_SYSCOMMAND:

            switch ( wParam )
            {
                case SC_CLOSE:      // <== ..as for example..

                    QuitThisApp( hDlg );
                    return( true );

                case IDM_About:    // <== ..as for example..

                    DialogBoxParam( AppInst,
                                    MAKEINTRESOURCE( IDD_About ),
                                    hDlg, AboutDlg, 0 );
                    return( true );

                case SC_MINIMIZE: if ( Min2SysTray( hDlg ) ) return( true );
            }

            break;

//      << bunch of other cases >>

        case MSG_FROM_TRAY:

            ProcMsgFromTray( hDlg, wParam, lParam );
            return( true );

        case WM_INITDIALOG:

            Init_NID( hDlg );
            return( true );

        case WM_DESTROY: PostQuitMessage( 0 );
    }

    return( false );
}

Where the code for my Min2SysTray() function is:

C++

static bool Min2SysTray( HWND hDlg )
{
    bool Success = false;

    if ( NID )
    {
         NOTIFYICONDATA Ver;
         memset( &Ver, 0, sizeof( NOTIFYICONDATA ) );

         Ver.uID = NID->uID;
         Ver.uVersion = NOTIFYICON_VERSION_4;
         Ver.cbSize = sizeof( NOTIFYICONDATA );

         NID->hWnd = Ver.hWnd = hDlg;
         NID->uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;

         if ( Shell_NotifyIcon( NIM_ADD, NID ) &&  // <== ..adds the icon..
              Shell_NotifyIcon( NIM_SETVERSION, &Ver ) )
         {
              NID->uFlags =  NIF_INFO | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;

              if ( Success = Shell_NotifyIcon( NIM_MODIFY, NID ) )
                   ShowWindow( hDlg, SW_HIDE );
         }
    }

    return( Success );
}

And the code for my ProcMsgFromTray() function is:

C++

static void ProcMsgFromTray( HWND hDlg, WPARAM wParam, LPARAM lParam )
{
    if ( HIWORD( lParam ) == NID->uID )
    {
         switch ( LOWORD( lParam ) )
         {
//           case WM_CONTEXTMENU:   // <== ..I don't need this..
//               break;

             case NIN_SELECT:
             case NIN_KEYSELECT:
             case WM_LBUTTONDBLCLK:

                 if ( NID ) Shell_NotifyIcon( NIM_DELETE, NID );
                 ShowWindow( hDlg, SW_SHOW );
         }
    }
}

And that's pretty much all of the code. Needless to say, I haven't been able to figure out what's wrong with it (yet?), if anything..

So what I need is another pair of eyes. Or two, or four.. or a thousand..

Uh! My frustration's bubbling to the surface.. please to excuse..

Anyway, if there's anyone out there who can find anything wrong with the above code, and/or can help in any other way, please respond..

Thanks in advance..

modified 16-Mar-15 23:23pm.

From code you posted it seems very improbable to me that it can work with memory dynamically allocated (new) for NOTIFYICONDAT. This memory is released when sub exits, while it is not reused may happen that it works, as soon it is reused and filled with data making nosense for IconNotify it will not work anymore.
The problem you mentioned is related only to services and program that starts before desktop (iexplorer) is started (that is the case of utilities wrote by the author of article you mentioned). In that case the solution is to wait for initialization to complete. You will find all info, if you need, here[^].
Making it static and changing the access to its members it works for me.
This is the amended code:

C++

#define MSG_FROM_TRAY  (WM_APP + 0xDAD)   // <== ..the "callback message" ID..

static BOOL Opning = TRUE;

static NOTIFYICONDATA NID;
 
static void Init_NID( HWND hDlg )
{
    //if ( NID = new NOTIFYICONDATA )
    //{
         memset( &NID, 0, sizeof( NOTIFYICONDATA ) );
 
         if ( LoadIconMetric( AppInst,
                              (PCWSTR)MAKEINTRESOURCE( IDR_TrayIcon ),
                              LIM_SMALL, &NID.hIcon ) == S_OK )
         {
              if ( LoadIconMetric( AppInst,
                                   (PCWSTR)MAKEINTRESOURCE( IDR_BallIcon ),
                                   LIM_SMALL, &NID.hBalloonIcon ) == S_OK )
              {
                   strcpy( NID.szTip, "My App Name" );
                   strcpy( NID.szInfoTitle, "Hi There" );
                   strcpy( NID.szInfo, "My notification message.." );
 
                   if ( Opning )
                   {
                        NID.uTimeout = 5000;
                        NID.uID = TRAY_ICON_ID;
                        NID.dwInfoFlags = NIIF_USER;
                        NID.uCallbackMessage = MSG_FROM_TRAY;
                        NID.cbSize = sizeof( NOTIFYICONDATA );
                        NID.dwState = 0;
                        NID.dwStateMask = NIS_HIDDEN | NIS_SHAREDICON;
 
                        return;
                   }
 
                   DestroyIcon( NID.hBalloonIcon );
              }
 
              DestroyIcon( NID.hIcon );
         }
 
         //delete NID;
         //NID = NULL;
    //}
}

static BOOL Min2SysTray( HWND hDlg )
{
    BOOL Success = FALSE;
 
    //if ( NID )
    //{
         NOTIFYICONDATA Ver;
         memset( &Ver, 0, sizeof( NOTIFYICONDATA ) );
 
         Ver.uID = NID.uID;
         Ver.uVersion = NOTIFYICON_VERSION_4;
         Ver.cbSize = sizeof( NOTIFYICONDATA );
 
         NID.hWnd = Ver.hWnd = hDlg;
         NID.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;
 
         if ( Shell_NotifyIcon( NIM_ADD, &NID ) &&  // <== ..adds the icon..
              Shell_NotifyIcon( NIM_SETVERSION, &Ver ) )
         {
              NID.uFlags =  NIF_INFO | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;
 
              if ( Success = Shell_NotifyIcon( NIM_MODIFY, &NID ) )
                   ShowWindow( hDlg, SW_HIDE );
         }
    //}
 
    return( Success );
}

static void ProcMsgFromTray( HWND hDlg, WPARAM wParam, LPARAM lParam )
{
    if ( HIWORD( lParam ) == NID.uID )
    {
         switch ( LOWORD( lParam ) )
         {
//           case WM_CONTEXTMENU:   // <== ..I don't need this..
//               break;

             case NIN_SELECT:
             case NIN_KEYSELECT:
             case WM_LBUTTONDBLCLK:
 
                 /*if ( NID )*/ Shell_NotifyIcon( NIM_DELETE, &NID );
                 ShowWindow( hDlg, SW_SHOW );
         }
    }
}

modified 16-Mar-15 19:13pm.

Apologies. I made a mistake in transcribing the original code.

Which actually has nothing to do with why this code still doesn't work - just to be clear.

In the original code, the NID->szTip, NID->szInfoTitle, and NID->szInfo structure members are not initialized by strcpy(). I changed it to a bunch of strcpy() calls to "simplify" the code (to make it easier to read)..

They are initialized in the original code by a function call whose return value sets an auto bool called, "Opning". When I substituted out that function call for those strcpy() calls (for simplicity), I also (erroneously) took out the "bool Opning =" part.

My bad.

To make a long story short, the following is a far more correct "transcription" of the existing code:

C++

#define TRAY_ICON_ID  0xABC  // <== ..our System Tray Icon Id
#define BALL_ICON_ID  0xDEF  // <== ..our Balloon Tip Icon Id

#define MSG_FROM_TRAY  (WM_APP + 0xDAD)   // <== ..the "callback message" ID..

static NOTIFYICONDATA *NID;

static void Init_NID( HWND hDlg )
{
    if ( NID = new NOTIFYICONDATA )
    {
         memset( NID, 0, sizeof( NOTIFYICONDATA ) );

         if ( LoadIconMetric( AppInst,
                              (PCWSTR)MAKEINTRESOURCE( IDR_TrayIcon ),
                              LIM_SMALL, &NID->hIcon ) == S_OK )
         {
              if ( LoadIconMetric( AppInst,
                                   (PCWSTR)MAKEINTRESOURCE( IDR_BallIcon ),
                                   LIM_SMALL, &NID->hBalloonIcon ) == S_OK )
              {
                   bool Opning;

                   if ( Opning = LoadStrings( NID->szTip,
                                              NID->szInfo,
                                              NID->szInfoTitle ) )
                   {
                        NID->uTimeout = 5000;
                        NID->uID = TRAY_ICON_ID;
                        NID->dwInfoFlags = NIIF_USER;
                        NID->uCallbackMessage = MSG_FROM_TRAY;
                        NID->cbSize = sizeof( NOTIFYICONDATA );
                        NID->dwState = 0;
                        NID->dwStateMask = NIS_HIDDEN | NIS_SHAREDICON;

                        return;   // <== i.e. RETURN to caller w/ NID != NULL..
                   }

                   DestroyIcon( NID->hBalloonIcon );
              }

              DestroyIcon( NID->hIcon );
         }

         delete NID;
         NID = NULL;
    }
}

Again, sorry for that oversight.

However, as is readily apparent from the above code, it is incorrect to say that the "memory is released when sub exits". The memory is only released if the function fails to initialize the entire structure.

Thing is though, even if the function does fail (which BTW, I've never seen it do, and I've debugged this a lot), then the NID variable would get set to NULL, which would prevent the Shell_NotifyIcon() function from ever getting called (because the function that calls it checks the NID before it does anything else).

And to forestall the inevitable question, yes, I am sure that my "LoadString()" function is not overwriting any other structure members (with strings too big)..

Anyway, the structure always initializes fine, so I don't think that's the problem.

I am curious though, about what you meant when you said that it "works for me"? Are you compiling in 64-bit?

I see, I have misinterpreted the usage of new in your code.
What I mean is that I compiled a sample with a C (not C++) compiler and it works for me.
The only problem I found compiling the code in 64bits is that a manifest resource is required.
This is my full sample:

C++

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <windowsx.h>
#include <commctrl.h>
#include <tchar.h>
#include <shellapi.h>
#include <stdio.h>
#include <stdlib.h>
#include "main.h"

#define NELEMS(a)  (sizeof(a) / sizeof((a)[0]))

static INT_PTR CALLBACK MainDlgProc(HWND, UINT, WPARAM, LPARAM);

#define AppInst ghInstance
static HANDLE ghInstance;

#define TRAY_ICON_ID  0xABC  // <== ..our System Tray Icon Id
#define BALL_ICON_ID  0xDEF  // <== ..our Balloon Tip Icon Id

#define MSG_FROM_TRAY  (WM_APP + 0xDAD)   // <== ..the "callback message" ID..

static BOOL Opning = TRUE;

static NOTIFYICONDATA NID;
 
static void Init_NID( HWND hDlg )
{
    //if ( NID = new NOTIFYICONDATA )
    //{
         memset( &NID, 0, sizeof( NOTIFYICONDATA ) );
 
         if ( LoadIconMetric( AppInst,
                              (PCWSTR)MAKEINTRESOURCE( IDR_TrayIcon ),
                              LIM_SMALL, &NID.hIcon ) == S_OK )
         {
              if ( LoadIconMetric( AppInst,
                                   (PCWSTR)MAKEINTRESOURCE( IDR_BallIcon ),
                                   LIM_SMALL, &NID.hBalloonIcon ) == S_OK )
              {
                   strcpy( NID.szTip, "My App Name" );
                   strcpy( NID.szInfoTitle, "Hi There" );
                   strcpy( NID.szInfo, "My notification message.." );
 
                   if ( Opning )
                   {
                        NID.uTimeout = 5000;
                        NID.uID = TRAY_ICON_ID;
                        NID.dwInfoFlags = NIIF_USER;
                        NID.uCallbackMessage = MSG_FROM_TRAY;
                        NID.cbSize = sizeof( NOTIFYICONDATA );
                        NID.dwState = 0;
                        NID.dwStateMask = NIS_HIDDEN | NIS_SHAREDICON;
 
                        return;
                   }
 
                   DestroyIcon( NID.hBalloonIcon );
              }
 
              DestroyIcon( NID.hIcon );
         }
 
         //delete NID;
         //NID = NULL;
    //}
}

static BOOL Min2SysTray( HWND hDlg )
{
    BOOL Success = FALSE;
 
    //if ( NID )
    //{
         NOTIFYICONDATA Ver;
         memset( &Ver, 0, sizeof( NOTIFYICONDATA ) );
 
         Ver.uID = NID.uID;
         Ver.uVersion = NOTIFYICON_VERSION_4;
         Ver.cbSize = sizeof( NOTIFYICONDATA );
 
         NID.hWnd = Ver.hWnd = hDlg;
         NID.uFlags = NIF_ICON | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;
 
         if ( Shell_NotifyIcon( NIM_ADD, &NID ) &&  // <== ..adds the icon..
              Shell_NotifyIcon( NIM_SETVERSION, &Ver ) )
         {
              NID.uFlags =  NIF_INFO | NIF_MESSAGE | NIF_TIP | NIF_SHOWTIP;
 
              if ( Success = Shell_NotifyIcon( NIM_MODIFY, &NID ) )
                   ShowWindow( hDlg, SW_HIDE );
         }
    //}
 
    return( Success );
}

static void ProcMsgFromTray( HWND hDlg, WPARAM wParam, LPARAM lParam )
{
    if ( HIWORD( lParam ) == NID.uID )
    {
         switch ( LOWORD( lParam ) )
         {
//           case WM_CONTEXTMENU:   // <== ..I don't need this..
//               break;

             case NIN_SELECT:
             case NIN_KEYSELECT:
             case WM_LBUTTONDBLCLK:
 
                 /*if ( NID )*/ Shell_NotifyIcon( NIM_DELETE, &NID );
                 ShowWindow( hDlg, SW_SHOW );
         }
    }
}

int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
{
    INITCOMMONCONTROLSEX icc;
    WNDCLASSEX wcx;

    ghInstance = hInstance;

    icc.dwSize = sizeof(icc);
    icc.dwICC = ICC_WIN95_CLASSES /*|ICC_COOL_CLASSES|ICC_DATE_CLASSES|ICC_PAGESCROLLER_CLASS|ICC_USEREX_CLASSES|... */;
    InitCommonControlsEx(&icc);

    wcx.cbSize = sizeof(wcx);
    if (!GetClassInfoEx(NULL, MAKEINTRESOURCE(32770), &wcx))
        return 0;

    wcx.hInstance = hInstance;
    wcx.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDR_ICO_MAIN));
    wcx.lpszClassName = _T("TacitoniClass");
    if (!RegisterClassEx(&wcx))
        return 0;

    return DialogBox(hInstance, MAKEINTRESOURCE(DLG_MAIN), NULL, (DLGPROC)MainDlgProc);
}

static INT_PTR CALLBACK MainDlgProc(HWND hwndDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_INITDIALOG:
			Init_NID( hwndDlg );
            return TRUE;

        case WM_SIZE:
            return TRUE;

        case WM_COMMAND:
            switch (GET_WM_COMMAND_ID(wParam, lParam))
            {
                case IDOK:
                    EndDialog(hwndDlg, TRUE);
                    return TRUE;
            }
            break;

        case WM_SYSCOMMAND:
 
            switch ( wParam )
            {
                case SC_CLOSE:      // <== ..as for example..

                    PostQuitMessage(0);
                    return TRUE;
 
                case SC_MINIMIZE:
					if ( Min2SysTray( hwndDlg ) )
						return TRUE;
            }
 
            break;

		case MSG_FROM_TRAY:
			ProcMsgFromTray(hwndDlg, wParam, lParam);
			break;
 
        case WM_CLOSE:
            EndDialog(hwndDlg, 0);
            return TRUE;
    }

    return FALSE;
}

modified 17-Mar-15 4:53am.

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:

C++

#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' 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..

Thanks Tacitonitus,
BTW my code is 64 bits, and I assure you that it works. I didn't use VC, but PellesC compiler.
You can get the working project (with even the executable) here[^] if you need.
Just to give more detail, my manifest contains:

XML

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity
    type="win32"
    name="MyOrganization.MyDivision.MyApp"
    version="1.0.0.0"
    processorArchitecture="amd64"
/>

<description>Verbal description of MyApp.</description>

<dependency>
  <dependentAssembly>
    <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        processorArchitecture="amd64"
        publicKeyToken="6595b64144ccf1df"
        language="*"
    />
  </dependentAssembly>
</dependency>

<!--
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
        <requestedPrivileges>
            <requestedExecutionLevel
                level="asInvoker"
                uiAccess="false"
            />
        </requestedPrivileges>
    </security>
</trustInfo>
-->

<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
  <application> 
     <!-- Application supports Windows 8.1 -->
     <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
     <!-- Application supports Windows 8 -->
     <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
     <!-- Application supports Windows 7 -->
     <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
     <!-- Application supports Windows Vista -->
     <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
  </application>
</compatibility>

</assembly>

This is important because if I compile without it the loader complains about a missing ordinal in commctl32:

The ordinal 380 could not be located in the dynamic link library COMCTL32.dll.

Yes, I got exactly that same error message when I tried to "disable Visual Styles", to see if it would make a difference..

So it looks like I've got to take that "very long" road I mentioned..

Well, like I said, in the long term, that's probably a good thing (I'm trying to stay positive)..

So let me ask you: what size Icons are you passing in to the LoadIconMetric() function(s)?

I'm passing in 32x32 pixel Icons, and trusting that the LoadIconMetric() function will either squash it down to the appropriate size, or return an error code if it can't. However, I can no longer trust even the most obvious of assumptions any more, which is why I'm asking..

Also, I can't download your project because you have to be a member of whatever to do so.. But that doesn't matter much - I'm.. uh.. somewhat familiar with the code.. Smile | :)

This is maddening - according to you, the code works fine - it just doesn't work for me.. 'cause I'm.. special.. or cursed.. or something.. WTF | :WTF:

Well, whatever. Ignore the previous paragraph. I guess I'll just have to keep slogging it out..

Cheers..

Icon is 32x32 256 colors.
To download the sample you have just register is not a big issue.

Tacitonitus,
I don't think that a code couldn't work because someone is marked by the obscure forces.
First of all, it was was my wrong about the new operator because it seemed to me that you destroyed the buffer exiting the function.
Of course to use a static or dynamic allocation makes no difference, what really counts is that the memory stay there when shell functions are called.
The Shell_NotifyIcon, with a lot of bugs as usual for MS products, couldn't be not functional. There is a sea of 64 bits applications out there that works.
My personal idea is that the problem is not in your code for Shell_NotifyIcon, but somewhere else. Probably you would take a tighten look to the whole code and try debugging to see if the buffer is consistent each time you use the Shell_NotifyIcon function.
Cheers

Here i created in DLL project in vc++ 2008. Following are two code files lib.h and lib.cpp.
lib.h

C++

#include "stdafx.h";

    class __declspec(dllexport) test
    {
    public:
        test();
        static void  hello();
        static void  hello1();
    };

    class __declspec(dllexport) test1
    {
    public:
        test1();
        void  hello_test1();
        void  hello1_test1();

    };

lib.cpp

C++

#include "stdafx.h"
   #include "lib.h"
   #include <stdio.h>

   void test::hello()
   {
       printf("Hello");
   }

   void test::hello1()
   {
       printf("Hello1");
   }

   void test1::hello_test1()
   {
       printf("Hello_test1");
   }

   void test1::hello1_test1()
   {
       printf("Hello1_test1");
   }

stdafx.h

C++

#include "targetver.h"
#define WIN32_LEAN_AND_MEAN 
// Windows Header Files:
#include <windows.h>

dllMain.cpp

C++

#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

I have written C# code to call the method of test and test1 classes:
consoleApp

C#

 [DllImport("lib.dll" )]
    public static extern void hello();

    [DllImport("lib.dll")]
    public static extern void hello1();

    [DllImport("lib.dll")]
    public static extern void hello_test1();

    [DllImport("lib.dll")]
    public static extern void hello1_test1();

 static void Main()
{ 
        hello();
        hello1();
        hello_test1();
        hello1_test1();
        Console.ReadKey();
    }

when i run above code i have got following error: EntryPointNotFoundException: Unable to find an entry point named 'hello' in DLL 'lib.dll' 1****<-Click 1 for image
I know about how to call function only(without using Class) of vc++ DLL from C# but i don't know how to call method of any class and how to code that in proper way in vc++.

I know somewhere is mistake in my above code, please experts guide me about my mistake because i tried all from my side.

If anyone has full example like above then suggest me.

Thanks in advance..

There are two main issues to deal with here.

1. If you want to call functions like that in a C++ DLL, you shouldn't put them inside classes.
2. There is an issue called C++ Name Mangling. This is where the linker exports the functions with additional characters that describe the function signature. To call the functions by their names directly, you must place the definitions inside an "extern C" declaration like so:

C++

extern "C"
{
    void Hello()
    { printf("Hello");}

    void Hello1()
    { printf("Hello 1");}
}

The difficult we do right away...
...the impossible takes slightly longer.

I use IAccessible and presently I can get text string from Internet Explorer. I put my code below. But how I can get one word from this text string directly under mouse pointer? Not whole string, ,only one word under mouse pointer?
Thanks in advance.

C++

CString Name; 
 
CPoint CursorPos; 
GetCursorPos( &CursorPos ); 
    
IAccessiblePtr pIAcc; 
_variant_t vt; 
    
BSTR pName = NULL; 
BSTR pValue = NULL; 
 
if( SUCCEEDED( AccessibleObjectFromPoint( CursorPos, &pIAcc, &vt ))) 
{ 
pIAcc->get_accChild( 
BSTR pName = NULL; 
if( SUCCEEDED( pIAcc->get_accName( vt, &pName ))) 
{ 
if( pName && ::SysStringLen( pName )) 
{ 
Name = pName; 
} 
::SysFreeString( pName ); 
} 
}

Hi everyone,
I'm beginner and I need a little help. I have to make RPN (postfix) calculator using stack which is implemented by singly linked list in C. Now I found that but in C++ and I'm having trouble translating it to C. Can you help me getting things to work? I have started from http://www.mediafire.com/view/q833x5sic8eq4sx/from_c__.txt and using a little code from http://www.mediafire.com/view/ewz9so6999ig5x0/using_c.txt I get to http://www.mediafire.com/view/qesca0cg0vzjzac/to_this_in_c.txt code and it debugs but when I enter anything in console it crashes and gives me some assembly code I'm using VS C++ 2010. Please help me to fix this, I can't find what's wrong.

No one is going to go to those links to see your code. You must post the relevant code snippets here along with any exact error messages.

The difficult we do right away...
...the impossible takes slightly longer.

You already posted this request in the quick answers thread.
As already told you, you don't have post links, but code (just for your knowledge the links are not even working).
Just a small direction: compile your code with debug info, open a debug session and localize where your code fails. Restrict the place, extract a small snippet showing the problem and post only that small piece if you want any help.

Back when I was in school, we made our own RPN calculator from scratch (after spending weeks discussing data structures and algorithms on the chalkboard), not converting it from one language to another. As a result, I understand how they work.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

HI all

I want to design a ui widget library , which any iDE developer can use and develop GUI applications. let say library has application widgets include menu bars, tool bars.

at starting point what are functional and non functional requirements should i consider

use cases for UI widget design

Thanks for help

This is a looooonnnnggg conversation. If you're just starting out, I'd look at what other widget libraries have done. You'll probably also find that a lot of widget libraries have grown into full out frameworks.

Here are a few to look at:
- Qt
- MFC
- wxWidgets
- GTK+

HI all

I want to design a ui widget library , which any iDE developer can use and develop GUI applications. let say library has application widgets include menu bars, tool bars.

at starting point what are functional and non functional requirements should i consider

use cases for UI widget design

Thanks for help

I am looking around for topics like MFC vs WTL. There have been many discussions regarding that.

I am trying to make a decision of what type of library to use for programming C++ GUI application on Windows7/8.

One of the strongest arguments in support for using WTL over MFC was the fact that executable of WTL will be around 4x smaller in size than statically linked MFC Application.

Now, given the fact that we are living in 2015 now, does it really matter? If your program is 8MB or 2MB?

From what I see, MFC has many more rich features, and most of all, it is very well supported.

For example, I can install Visual Studio 2013, and build MFC right away and change it the way I want.

On the other hand WTL does not even install properly with its installer under new Visual Studio unless you do some tricks/corrections.

Plus, WTL literature/examples are scattered here and there, and there is very minimal support to it. And most of all, it doesnt have as many nice UI features as MFC does.

The only thing WTL buys me is the fact that its applications will be just more compact, and smaller, but then again, does it really matter for PC's of these days?

Also, MFC gives programmer to do anything what he could do with Win32 API.

Am I missing anything else what is needed to make a decisio whether I should go with MFC or WTL?

So, if one wants to develop some big and professional Windows GUI Application, what is better invest time for coding/learning, MFC, or WTL?

Member 11203277 wrote:
WTL literature/examples are scattered here and there, and there is very minimal
support to it

Documentation, or lack thereof, would be a deal breaker for me, I vote for MFC as there are TONS of examples and lots of documentation. I can't remember the last time I really cared about the size of an executable.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment

"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst

Member 11203277 wrote:
Now, given the fact that we are living in 2015 now, does it really matter? If your program is 8MB or 2MB?

Depends.

I'm on a 3G connection with a maximum with 7Gb a month. I won't fret over 6Mb, but most setups are larger than those 8Mb, often including stuff that has already been downloaded.

Bastard Programmer from Hell Suspicious | :suss:

If you can't read my code, try converting it here[^]

Member 11203277 wrote:
One of the strongest arguments in support for using WTL over MFC was the fact that executable of WTL will be around 4x smaller in size than statically linked MFC Application.

Now, given the fact that we are living in 2015 now, does it really matter? If your program is 8MB or 2MB?

Well, when it comes to MFC, you should probably be dynamically linking to system installed dll's anyways. In that case, the size of the libraries doesn't really matter since you'd be sharing the system MFC libraries (instead of bloating the application).