The OS is Vista and I’m using VS2008. I created a new WIN32 project a and I
added CreateWindowEx to the message handler for the About box as follows:
---------------------------------------------------------------------------
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
UNREFERENCED_PARAMETER(lParam);
switch (message)
{
case WM_INITDIALOG:
HWND hwndLink;
INITCOMMONCONTROLSEX iccex;
iccex.dwSize = sizeof(INITCOMMONCONTROLSEX);
iccex.dwICC = ICC_LINK_CLASS;
InitCommonControlsEx(&iccex);
hwndLink = CreateWindowEx(0,
WC_LINK,
L"<A HREF=\"http://www.mycompany.com\">Test",
WS_VISIBLE | WS_CHILD | WS_TABSTOP,
10,55,120,30,
hDlg,
0,
hInst,
NULL);
return (INT_PTR)TRUE;
---------------------------------------------------------------------------
The project is linked with comctl32.lib.I believe that I’ve done all the
steps required in http://msdn.microsoft.com/en-us/library/bb760706.aspx
however nothing is drawn on the DialogBox when the code executes. What is
wrong?
--
Mark Wilson
I had a similar problem which was cured by calling
LinkWindow_RegisterClass instead of InitCommonControlsEx:
http://msdn.microsoft.com/en-us/library/bb776464(VS.85).aspx
Richard.
http://www.rtrussell.co.uk/
Thinking about it further, that's unlikely to be the problem because I
was using the "Link Window" class not the "SysLink" class. A more
probable explanation is that you don't have the necessary manifest to
enable the COMCTL32 version 6 controls:
http://msdn.microsoft.com/en-us/library/ms997646.aspx
Richard.
http://www.rtrussell.co.uk/
To reply by email change 'news' to my forename.
Hi,
All new functionality defined in ComCtl32.dll supports only
Unicode, thus you need to create a Unicode version of
SysLink control.
Kellie.
Yes, I can reproduce this problem with your code. Actually, Richard is
correct; the problem is caused by not using the 6.0 version of ComCtl32.dll
while SysLink control is only defined in 6.0 version above ComCtrl32.dll.
This requirement is documented in the MSDN link below:
"The SysLink control is defined in the ComCtl32.dll version 6 and requires
a manifest or directive that specifies that version 6 of the DLL should be
used if it is available. See Enabling Visual Styles."
http://msdn.microsoft.com/en-us/library/bb760706(VS.85).aspx
To verify this, you may use Process Explorer and examine your running
application and view its "Dll Panel". Then you can find ComCtrl32.dll which
is not 6.0 version.
We can resolve this problem by adding the following "app.config" manifest
to the project:
"
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
"
Then, I go to project property dialog->"Configuration
Properties"->"Manifest Tool"->"Input and Output"->"Additional Manifest
Files" and specify the above manifest file "app.config". After compiling
the following code will show SysLink control correctly on the About dialog
now:
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM
lParam)
{
UNREFERENCED_PARAMETER(lParam);
switch (message)
{
case WM_INITDIALOG:
HWND hwndLink;
INITCOMMONCONTROLSEX iccex;
iccex.dwSize = sizeof(INITCOMMONCONTROLSEX);
iccex.dwICC = ICC_LINK_CLASS;
InitCommonControlsEx(&iccex);
hwndLink = CreateWindowExW(0,
WC_LINK,
L"<A HREF=\"http://www.mycompany.com\">Test</a>" ,
WS_VISIBLE | WS_CHILD | WS_TABSTOP,
10,55,120,30,
hDlg,
0,
hInst,
NULL);
return (INT_PTR)TRUE;
...
}
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Also in http://msdn.microsoft.com/en-us/library/bb760706.aspx
The call to CreateWindow is not specifically UNICODE. Should it be
CreateWindowExW for clarity?
--
Mark Wilson
""Jeffrey Tan[MSFT]"" wrote:
> ....
Thanks for your feedback.
Yes, basically, I agree that it would be clearer that if we change
"CreateWindowEx" to CreateWindowExW. But normally this will not be a big
problem because the VC++ project will define "UNICODE" by default, which
means that "CreateWindowEx" will be defined as CreateWindowExW during
preprocessing:
#ifdef UNICODE
#define CreateWindowEx CreateWindowExW
#else
#define CreateWindowEx CreateWindowExA
In the worest case, if someone explicitly remove the definition of
"UNICODE", the VC++ compiler will detect the parameter incompatibility
issue for CreateWindowExA and emit an error message so that developer will
correct it to CreateWindowExW.
Anyway, yes, it is better if the MSDN sample uses CreateWindowExW. You may
report this MSDN doc issue by using the "Click to Rate and Give Feedback".
Our comment for the feedback will arrive at the owner for this doc page and
I think he will help to correct it.
Thank you for the carefully review. If you need further help, please feel
free to post, thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Alternatively, remove the L" in the third parameter (lpWindowName).
You can create a SysLink control perfectly well using CreateWindowExA
and specifying an ANSI string for the control's text. Even though
version 6 controls support only Unicode, this does not mean you have
to use CreateWindowExW (in my experience - I don't know whether or not
this is 'by design').
In fact, much of the time you don't need to be aware that version 6
controls are 'Unicode only' because the 'automatic two-way translation
(Unicode to ANSI) for window messages' takes care of things:
http://msdn.microsoft.com/en-us/library/ms633529(VS.85).aspx
Really? I have never tested this before. Sounds cool.
It seems that CreateWindowExA did the correct job; it will just perform the
parameter translation and then calls the unicode version for the real work.
Thank you for the sharing.
I followed the guidance in
http://msdn.microsoft.com/en-us/library/ms997646(printer).aspx for
“Extensions, Plugins, or a DLL That is Brought into a Process”.
I added the string ‘CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST
"mydll.manifest"’ to the .RC file and put the XML data into the file
mydll.manifest. When it compiles it creates a file called mydll.dll.manifest.
I put the file mydll.dll.manifest in the same directory as mydll.dll and ran
Outlook. When the AboutBox is displayed there is no SysLink drawn. Do you
have any ideas that would help debug this?
Thanks.
--
Mark Wilson
Thank you for the feedback.
To troubleshoot this issue, the first thing I would check is the
ComCtl32.dll loaded version. You may download Process Explorer from the
link below and find your application process in the process tree, then you
can find the ComCtl32.dll from this process' "Dll Panel". What is the
version of it? Is it 6.0?
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Also, I suspect if the mydll.dll.manifest is correctly used. It would be
easy for us to use Process Monitor to log the file system activity of your
process. We can use the "Path" contains "mydll.dll.manifest" as the
"Include" filter. This monitoring helps us to check if the
"mydll.dll.manifest" is probed by the loader. You can download the Process
Monitor tool from the link below:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926
I will wait for your further information. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Thank you for the feedback.
To troubleshoot this issue, the first thing I would check is the
ComCtl32.dll loaded version. You may download Process Explorer from the
link below and find your application process in the process tree, then you
can find the ComCtl32.dll from this process' "Dll Panel". What is the
version of it? Is it 6.0?
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Also, I suspect if the mydll.dll.manifest is correctly used. It would be
easy for us to use Process Monitor to log the file system activity of your
process. We can use the "Path" contains "mydll.dll.manifest" as the
"Include" filter. This monitoring helps us to check if the
"mydll.dll.manifest" is probed by the loader. You can download the Process
Monitor tool from the link below:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx?PHPSESSID=d926
I will wait for your further information. Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Both versions of ComCtl32 are loaded.
This seems to be the case whether my addin is enabled or not.
mydll.dll.manifest was never requested by the loader. I have a COM Addin
that is also loaded and I see the registry being queried for a manifest name
for that DLL (it does not have one). myaddin.dll is not a COM addin. It is
an Exchange client extension so it has no entry at
HKLM\SOFTWARE\Microsoft\Office\Outlook\Addins\<addin-name>\Manifest
Does it need one? Will this only work for COM Addins?
--
Mark Wilson
I am Feng Chen from MSDN Online Community Support team. Since Jeffrey is
out of office now and participating in training, I will work with you on
this issue. This is a quick note to let you know that I am performing
research on this issue and will get back to you as soon as possible. I
appreciate your patience.
Best regards,
Feng Chen
Based on my understanding, it is the Exchange client extension (myaddin.dll)
which has this problem. If I have misunderstood you, please let me know.
However, we’re not very familiar Exchange related technologies, so could
you please post here the detailed steps so that we can reproduce this issue
locally? Or could you please send a sample project to my email box in case
if this is convenient for you? My email address is
(v-fe...@online.microsoft.com, remove '.online'). In this way, we can work
on this issue more efficiently.
I look forward to hearing from you and appreciate your time and patience.
Best regards,
Feng Chen
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
news:839B07F3-7087-4123...@microsoft.com...
Since you are not familiar with Exchange Client Extensions, I think I can
reproduce the problem in an Outlook COM addin based on KB 230689.
(http://support.microsoft.com/kb/230689/EN-US/)
I'll see if I can add the code to that sample and e-mail you the project.
--
Mark Wilson
"Feng Chen[MSFT]" wrote:
> Hello Mark,
>
> Based on my understanding, it is the Exchange client extension (myaddin.dll)
> which has this problem. If I have misunderstood you, please let me know.
>
> However, we’re not very familiar Exchange related technologies, so could
> you please post here the detailed steps so that we can reproduce this issue
> locally? Or could you please send a sample project to my email box in case
> if this is convenient for you? My email address is
> (v-fe...@online.microsoft.com, remove '.online'). In this way, we can work
> on this issue more efficiently.
>
> I look forward to hearing from you and appreciate your time and patience.
>
> Best regards,
> Feng Chen
> Microsoft Online Community Support
> =========================================
> Delighting our customers is our #1 priority. We welcome your comments and
> suggestions about how we can improve the support we provide to you. Please
> feel free to let my manager know what you think of the level of service
> provided. You can send feedback directly to my manager at:
> msd...@microsoft.com.
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>
> "Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
> news:839B07F3-7087-4123...@microsoft.com...
I receive your project today and appreciate your time.
I reproduce this issue on my machine, and I can see in the Process Explorer
that the two versions of the ComCtl32 loaded by Word.
After that, I modify your project by removing the Manifest from the .rc
resource file and adding a config file to the project exactly like Jaffrey
has posted. Then I can see in Process Explorer that only the 6.0 version of
the ComCtl32.dll is loaded.
However, the link and icon is still not displayed in the dialog. It is
really strange since the correct version of ComCtl32 has already been
loaded. I’ll perform more research on this issue and get back to you as
soon as possible.
Thanks!
Best regards,
Feng Chen
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
news:0F5AEF86-9D68-46E7...@microsoft.com...
After debugging this issue, I found a very strange symptom:
The InitCommonControlsEx function returns 'true', this means that the
registration of Syslink control from the comctl32 succeeded. But the next
function CreateWindowExW fails and returns 'NULL', then I get the error
information using GetLastError: “Cannot find window class.” - An
application tried to use a window class that was not an application-specific
class registered with the system or one of the predefined control classes.
And I’ve sent this issue to our product team and will get back to you as
soon as possible. I appreciate your patience.
Best regards,
Feng Chen
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
news:0F5AEF86-9D68-46E7...@microsoft.com...
I think I have the COM Addin now working.
I added the line
#define ISOLATION_AWARE_ENABLED 1
just before including WINDOWS.H
I'll now try the same for the Exchange client extension.
--
Mark Wilson
"Feng Chen[MSFT]" wrote:
> Hello Mark,
>
I’m so happy to hear that this works for you. Actually, I’ve already came
to the same conclusion and I’d like to elaborate on it:
Since the TestAddin.dll contains a manifest in the resource, it is
considered an isolated application of which all the components are
side-by-side assemblies. A side-by-side assembly is a collection of
resources—a group of DLLs, windows classes, COM servers, type libraries, or
interfaces—available for an application to use at runtime.
For this issue, the window class registered in the COMCTL32.dll is not
available in the TestAddin.dll’s activation context. So we can let windows
perform automatic context management for us. To do this, we can define
ISOLATION_AWARE_ENABLED in our code just like you’ve done.
I admit this is not very easy to understand, and I’d like to provide the
following references about it:
• Specifying a Default Activation Context -
http://msdn.microsoft.com/en-us/library/aa376607(VS.85).aspx
• Fixing Activation Context Pollution -
http://blogs.msdn.com/jonwis/archive/2006/01/07/510375.aspx
• RT_MANIFEST resource, and ISOLATION_AWARE_ENABLED -
http://blogs.msdn.com/junfeng/archive/2007/06/26/rt-manifest-resource-and-isolation-aware-enabled.aspx
If you have any other concern or need more help on this issue, please don’t
hesitate to tell me.
Best regards,
Feng Chen
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
news:126037C7-6F05-47C3...@microsoft.com...
#define ISOLATIONAWARE_MANIFEST_RESOURCE_ID
#define ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID
The only way to get it to work was to put the manifest information in a
.config file and specify it as an input to the manifest tool as Jeffrey
mentioned earlier.
I’m currently having problems with a larger project in which I think I’ve
made all of the required modifications. InitCommonControlsEx returns TRUE
however CreateWindowEx returns:
Error: (1407)
Cannot find window class.
What would some of the reasons for that be?
Our managed newsgroup is focused on break fix issues that are neither
urgent, nor complex. Since the project with the problem is a large project,
it is recommended that you contact Microsoft Customer Support Services (CSS)
via telephone so that a dedicated Support Professional can assist you in a
more efficient manner. Please be advised that contacting phone support will
be a charged call.
You can contact Microsoft Product Support directly to discuss additional
support options you may have available, by contacting us at 1-(800)936-5800
or by choosing one of the options listed at
http://support.microsoft.com/common/international.aspx?rdpath=fh;en-us;cntactms.
Best regards,
Feng Chen
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
"Mark Wilson" <mwmsdnma...@newsgroups.nospam> wrote in message
news:0ADABCAF-B928-4158...@microsoft.com...
In this case the project has several CPP files. In DllMain() I called
InitCommonControlsEx() and then did a call to DllGetVersion()
http://msdn.microsoft.com/en-us/library/bb776779(VS.85).aspx to find the
version of comctl32.dll. It was version 6 so I knew the manifest was working
correctly. However in one of the other CPP source files where I tried to
create the SysLink the same routine returned version 5. As it turns out that
particular file did not have
#define ISOLATION_AWARE_ENABLED 1
#define SIDEBYSIDE_COMMONCONTROLS 1
before the statement
#include <WINDOWS.H>
Hence there was no wrapper created for CreateWindowEx() to make sure it
loaded version 6 of comctl32.dll
Now it all works.
Thanks for your assistance.