Add-in not correctly displayed ()

[ Edited ]


Hi all,

I have created an add-in for solid edge (x86) using the add-in wizard in visual studio 6 (C++). In order

to make an 64-bit version of this add-in, I have migrated the VC++ 6 project to visual studio 2005. The Add-in is

after registration successfully loaded in solid edge but not correctly displayed. All icons inside the toolbar

are a gray/black rectangles. This problem occurs when the development environment (Visual C++ 6, Visual Studio 2005)

are not installed. I mean only Solid edge (x64) is installed of my test partition. Of my development partition

my Addin is correctly displayed!





hInstance = AfxGetInstanceHandle();   



VERIFY_OK(m_pCommands->GetAddIn()->SetAddInInfo((long) hInstance, EnvironmentCatid,


                   IDR_TOOLBAR_LARGEMONOCHROME, NUMBER_OF_COMMANDS, &pCmdStrings, &pCmdIDs));


Test results:


# Test partition  (Windows 64-bit + Solid Edge 64-bit)              

-> hInstance   (wrong)


# Development partition (Windows 64-bit + Visual Studio 6 + Visual 2005 + Solid edge 64-bit)   

-> hInstance > 0  (OK)


Why the instance handle value is negative of the test partition? Some Dlls are missing ?

Should I use another function to get the instance handle in visual Studio 2005?


any suggessions ?


Thank you very much!


Posted by: Abou Mimin
Post date: 12/21/2008 6:14:33 AM


RE: Add-in not correctly displayed ()

[ Edited ]

A module handle (and window handles) only have 32 bits of significant data on the 64 bit OS. This allows for window handles to be passed between 32 and 64 bit processes. Normally when I look at a handle in the debugger, the first 8 digits are zero when running as a 64 bit program. Hence the handle should not be negative. Microsoft does have a "HandleToLong" and "LongToHandle" API but it essentially just does casting to soothe the compiler. However changing the code above from (long) hInstance to HandleToLong(hInstance) might help or at least avoid any compiler warnings. I am not sure why not having Visual Studio on the partitiion makes a difference. It does sound like something is missing. Try running depends.exe on the module. You should see a few "missing" MFC/C Runtime DLLs when running depends. Depends doesn't look at the winsxs directory to resolve those dependencies and I usually ignore those. However it could be that your "bad" partition does not have the needed DLLs in winsxs. You could step into the AfxGetInstanceHandle to see what is going on. However I assume your resource instance handle and your module instance handle are the same. So if the add-in DLL loaded on the bad partition, that would mean the resources loaded too and there would be no dependency issue. Visual Studio 2005 comes with a "redistributable" sub-directory that contains the MFC/C Runtime DLLs that can be deployed to the winsxs directory. You may be able to deploy them to your bad partition. I am not sure but you may be able to simply drag&drop them into the winsxs directory (mine is on c:\windows\winsxs). In the very least, you can open that directory on both partitions and see if the MFC DLLs and C runtime are present in both.


Posted by: R.D. Holland
Post date: 12/30/2008 3:52:20 AM

RE: Add-in not correctly displayed ()

[ Edited ]



Thank you for your help.

In order to check whether a DLL  from the directory WinSxs is missing, I have copied the entire WinSxS  dir from the

Development partition into the test partition. Unfortunately my Toolbar is not yet correctly indicated. Visual studio 2005 creates additionally two files during the x64 release build:

- A res file

- A manifest file.

I have also copied these files into the installation directory but unsuccessfully . It seems like the Addin-DLL needs other components to work correctly. So I have to check again the required dependencies (MFC-Dlls, Manifests, ...)




Posted by: Abou Mimin
Post date: 1/10/2009 7:54:36 AM

RE: Add-in not correctly displayed ()

[ Edited ]



before we started to support 64-bit in our addins, we compiled our 32-bit code with the 64-bit compatability mode flag set (/Wp64).

We used the HandleToLong and LongToHandle macros as RD has mentioned to fix all compiler warnings, then we tested this code under 32-bit SE. Finally, we compiled everything for x64, this time without the /Wp64 compile flag, and could run the addin successfully under x64 OS and SE x64.

We had no issues doing the port from 32-bit to 64-bit.




Posted by: Martin Bernhard
Post date: 1/11/2009 10:10:51 AM

RE: Add-in not correctly displayed ()

[ Edited ]



Did anyone ever resolve this issue? - I have the same problem in a C++ addin that I am working with now....


I have tried modifying the call to "SetAddInInfo((long)hInstance, ..." into "SetAddInInfo(HandleToLong(hInstance), ..." but still get exactly the same results - black icons when run using SE x64 builds!


The rest of the addin appears to work correctly - only problem seems to be the icons on the toolbar / menu!


Any help or prompts greatly appreciated!





Posted by: chris mann
Post date: 4/14/2011 7:56:49 AM

RE: Add-in not correctly displayed ()

[ Edited ]

You have to use the ISEAddInEx interface method SetAddInInfoEx. With that function you pass in the resource module filename and not the handle. If you module loads into high-memory (above the 4 gig address), passing the module handle as a long will not give Edge the correct module handle and your bitmaps will not be found.


For C++ programmers do this:


ISEAddinExPtr pSEAddinEx = pSEAddin; // assuming pSEAddin is the add-in interface edge passes into the OnConnectToEnvironment api - your name depends on your variable dec.


if( pSEAddinEx )


pSEAddinEx->SetAddInInfoEx( MyResrouceModuleFilename, .... ); // all other args are identical to those of SetAddInInfo.



The appxsdk\samples\addins\VC sample shows how to use this interface.


Note that failure to use the new interface introduced in V20 to support 32 and 64 bit add-ins can result in a crash deep in windows if the system DLLs are also loaded into high-memory. Or so I have found.


One other advantage to the newer API is that if you build a separate resource module, and you forget to remove the entry point (DLLMain stuff), the DLL will still be loaded by Edge even if you did not build a 64 bit specific target for the resource module. That is because Edge calls LoadLibraryEx and sets the "load as data" flag.


Posted by: R.D. Holland
Post date: 4/21/2011 6:21:22 AM

RE: Add-in not correctly displayed ()

[ Edited ]

Thankyou, thankyou, thankyou!!!

That seems to be exactly what I was missing!


Posted by: chris mann
Post date: 4/26/2011 2:40:02 AM