Strange Win 7 behavior using ComDlg32.OCX

[-mhd]

I have written an Outlook addin that uses ComDlg32.OCX to pop the Font dialog.

A few (very few) users report that when they click the button to pop the font
dialog all they see is a flicker or flash indicating something happened but no
dialog is presented. It seems they are all Win 7 users and I believe mostly
using Outlook version 2010.

I had been using the API method sample code from Randy Birch's
http://vbnet.mvps.org/ when I initially got the bug reports and decided to
switch to the common dialog ocx in case I wasn't implementing the API method
properly. Same result - same people with the original problem.

Using ComDlg32 Version 6.01.9816

'get hDC
Printer.Print
With CommonDialog1
.hDC = Printer.hDC
.flags = cdlCFBoth Or cdlCFEffects
.CancelError = True
.ShowFont
End With
Printer.KillDoc
If Err = cdlCancel Then Exit Sub
With CommonDialog1
AddrText.FontName = .FontName
AddrText.FontSize = .FontSize
and so on...

In my Inno script I install the file using the following (ignore the linebreak)
Source: c:\vbfiles\sp6\ComDlg32.OCX; DestDir: {sys}; Flags: restartreplace
sharedfile regserver

Any ideas?

Thanks -mike

[CoderX]

FWIW, I've been using the API version from vbAccelerator for years, and
works under w7. www.vbaccelerator.com


"-mhd" <***@invalid.com> wrote in message news:***@4ax.com...
I have written an Outlook addin that uses ComDlg32.OCX to pop the Font
dialog.

A few (very few) users report that when they click the button to pop the
font
dialog all they see is a flicker or flash indicating something happened but
no
dialog is presented. It seems they are all Win 7 users and I believe mostly
using Outlook version 2010.

I had been using the API method sample code from Randy Birch's
http://vbnet.mvps.org/ when I initially got the bug reports and decided to
switch to the common dialog ocx in case I wasn't implementing the API method
properly. Same result - same people with the original problem.

Using ComDlg32 Version 6.01.9816

'get hDC
Printer.Print
With CommonDialog1
.hDC = Printer.hDC
.flags = cdlCFBoth Or cdlCFEffects
.CancelError = True
.ShowFont
End With
Printer.KillDoc
If Err = cdlCancel Then Exit Sub
With CommonDialog1
AddrText.FontName = .FontName
AddrText.FontSize = .FontSize
and so on...

In my Inno script I install the file using the following (ignore the
linebreak)
Source: c:\vbfiles\sp6\ComDlg32.OCX; DestDir: {sys}; Flags: restartreplace
sharedfile regserver

Any ideas?

Thanks -mike

[-mhd]

Post by CoderX
FWIW, I've been using the API version from vbAccelerator for years, and
works under w7. www.vbaccelerator.com

I have many users on Win7 as well and I have Win7 for testing and don't get the
issue either which is what baffles me. However there have been enough users
reporting the problem I can't write it off as some random hosed system issue.

-mike

[Eduardo]

Post by -mhd

Post by CoderX
FWIW, I've been using the API version from vbAccelerator for years, and
works under w7. www.vbaccelerator.com

I have many users on Win7 as well and I have Win7 for testing and don't get the
issue either which is what baffles me. However there have been enough users
reporting the problem I can't write it off as some random hosed system issue.

Do you know whether it was on Windows 7 32 bits or 64 bits or other
information that
could help to identify the environment that is causing the problem?

[-mhd]

Post by Eduardo

Post by -mhd

Post by CoderX
FWIW, I've been using the API version from vbAccelerator for years, and
works under w7. www.vbaccelerator.com

I have many users on Win7 as well and I have Win7 for testing and don't get the
issue either which is what baffles me. However there have been enough users
reporting the problem I can't write it off as some random hosed system issue.

Do you know whether it was on Windows 7 32 bits or 64 bits or other
information that
could help to identify the environment that is causing the problem?

I have gone through all support emails and best I can determine it happens with
both 32bit and 64bit versions of windows 7.

Also Outlook 10 seems to be the common host for my addin as well.

I have gone back to an all API method again using Karl Peterson's code
http://vb.mvps.org/samples/Dialogs/

I also removed the flag for printer fonts so it can't be blamed on offline
printers.

Same users report nothing has changed on their end - just a flicker or flash
when they click the button font choose button.

I don't think the killbits issue can be involved either so I am totally
mystified.

-mike

[Karl E. Peterson]

Post by -mhd
I have gone through all support emails and best I can determine it happens
with both 32bit and 64bit versions of windows 7.
Also Outlook 10 seems to be the common host for my addin as well.

2010, you mean? No chance it's the 64-bit version, is there?

Post by -mhd
I have gone back to an all API method again using Karl Peterson's code
http://vb.mvps.org/samples/Dialogs/
I also removed the flag for printer fonts so it can't be blamed on offline
printers.
Same users report nothing has changed on their end - just a flicker or flash
when they click the button font choose button.

Crap. Well, I liked Mike's idea of a dirt-simple EXE that did nothing
but pop the font dialog on those machines, to take Outlook out of the
mix.

Another thought for debugging would be to use OutputDebugString to
capture what, if any, return codes that failed dialog call is offering.

Executing Debuggables -- Visual Studio Magazine
http://visualstudiomagazine.com/articles/2008/11/17/executing-debuggables.aspx

[-mhd]

Post by Karl E. Peterson
2010, you mean? No chance it's the 64-bit version, is there?

No or else my 32bit addin wouldn't even load.

Post by Karl E. Peterson
Crap. Well, I liked Mike's idea of a dirt-simple EXE that did nothing
but pop the font dialog on those machines, to take Outlook out of the
mix.

I have one waiting for my tester to agree to use - just waiting for a reply
before I start sending him attachments.

Post by Karl E. Peterson
Another thought for debugging would be to use OutputDebugString to
capture what, if any, return codes that failed dialog call is offering.

That will be the next step if I'm still not getting anywhere.

-mike

[Karl E. Peterson]

Post by -mhd

Post by Karl E. Peterson
2010, you mean? No chance it's the 64-bit version, is there?

No or else my 32bit addin wouldn't even load.

Yeah, that's what I thought. I believe it's possible to call out of
process, but probably not as an add-in.

Post by -mhd

Post by Karl E. Peterson
Crap. Well, I liked Mike's idea of a dirt-simple EXE that did nothing
but pop the font dialog on those machines, to take Outlook out of the
mix.

I have one waiting for my tester to agree to use - just waiting for a reply
before I start sending him attachments.

Cool.

Post by -mhd

Post by Karl E. Peterson
Another thought for debugging would be to use OutputDebugString to
capture what, if any, return codes that failed dialog call is offering.

That will be the next step if I'm still not getting anywhere.

Yeah, if the VB6 thing is popping them outside of Outlook, there's
something pretty hinky going on. I used to know a couple Outlook
add-on devs, I might be able to ask if they've ever seen anything like
that.

You probably don't know if it happens with any of the other common
dialogs, do you? That font one isn't used by anywhere near as many
apps as, say, the File one.

[-mhd]

Post by Karl E. Peterson

Post by -mhd

Post by Karl E. Peterson
2010, you mean? No chance it's the 64-bit version, is there?

No or else my 32bit addin wouldn't even load.

Yeah, that's what I thought. I believe it's possible to call out of
process, but probably not as an add-in.

True, an out of process 32bit app can still refer to the Outlook object in 64bit
Office.

Post by Karl E. Peterson
Yeah, if the VB6 thing is popping them outside of Outlook, there's
something pretty hinky going on. I used to know a couple Outlook
add-on devs, I might be able to ask if they've ever seen anything like
that.

That would be nice if they could relate to any similar experience.

Post by Karl E. Peterson
You probably don't know if it happens with any of the other common
dialogs, do you? That font one isn't used by anywhere near as many
apps as, say, the File one.

Unfortunately the Font dialog is the only one I use.

-mike

[Mayayana]

A few (very few) users report that when they click the button to pop the
font
dialog all they see is a flicker or flash
Are you sure they have a printer installed? I once had a
program that wouldn't start at all because I was enumerating
fonts on-load. That stopped it if there was no printer
installed, with no error. I'm assuming that referencing a
printer as you've done also won't work when no printer is
installed.

If that turns out to be the problem you might want to
switch to screen fonts. There's no reason to assume that
someone using Outlook has a printer hooked up.

[-mhd]

Post by Mayayana
If that turns out to be the problem you might want to
switch to screen fonts. There's no reason to assume that
someone using Outlook has a printer hooked up.

It's a printing app :-)

However see my follow up message I'm posting after this,

-mike

[Mayayana]

Post by Mayayana
If that turns out to be the problem you might want to
switch to screen fonts. There's no reason to assume that
someone using Outlook has a printer hooked up.

| It's a printing app :-)

Woops. Another thought might be to try running Filemon
or Procmon. There may be a clue, like an operation that
suddenly quits after failing to find a file, or something
like that.

[-mhd]

Post by Mayayana

Post by Mayayana
If that turns out to be the problem you might want to
switch to screen fonts. There's no reason to assume that
someone using Outlook has a printer hooked up.

| It's a printing app :-)
Woops. Another thought might be to try running Filemon
or Procmon. There may be a clue, like an operation that
suddenly quits after failing to find a file, or something
like that.

From a quick Google I see that Procmon has replaced Filemon and Regmon

Problem is not only can I not reproduce the problem on my PC, but I also don't
have any experience with Procmon and wouldn't be able to give a willing user a
quick tutorial on setting filters. I'm not even sure if I even have a user
willing to go that far.

I've downloaded Procmon and I'll see if I can get an understanding on how to
filter only my addin dll.

-mike

[Mike Williams]

Post by -mhd
I had been using the API method sample code from Randy Birch's
http://vbnet.mvps.org/ when I initially got the bug reports and decided
to switch to the common dialog ocx in case I wasn't implementing the
API method properly. Same result - same people with the original
problem.

Both the API method and the common dialog method work under Win7 here, but
that's when using them in a standard VB6 project and not as an addin for
Outlook. Have you tried creating a simple quick stand alone VB project which
does nothing other than pop up the font dialog (perhaps using the API
method) and which has no error checking and send it to your own users who
have the problem and ask them to run it for you as a simple test. At least
then you'll have an idea as to whether it is an Outlook problem or not.

Alternatively, how about sending a new version of your DLL (purely for test
purposes) to the users with the problem, one in which you create a simple
font dialog yourself in code and populate the list using EnumFontFamiliesEx,
just to see if it works okay. Check it first at your own end of course.

Mike

[Karl E. Peterson]

Post by Mike Williams

Post by -mhd
I had been using the API method sample code from Randy Birch's
http://vbnet.mvps.org/ when I initially got the bug reports and decided
to switch to the common dialog ocx in case I wasn't implementing the
API method properly. Same result - same people with the original
problem.

Both the API method and the common dialog method work under Win7 here, but
that's when using them in a standard VB6 project and not as an addin for
Outlook. Have you tried creating a simple quick stand alone VB project which
does nothing other than pop up the font dialog (perhaps using the API method)
and which has no error checking and send it to your own users who have the
problem and ask them to run it for you as a simple test. At least then you'll
have an idea as to whether it is an Outlook problem or not.

Interesting thought!

[-mhd]

Post by Mike Williams

Post by -mhd
I had been using the API method sample code from Randy Birch's
http://vbnet.mvps.org/ when I initially got the bug reports and decided
to switch to the common dialog ocx in case I wasn't implementing the
API method properly. Same result - same people with the original
problem.

Both the API method and the common dialog method work under Win7 here, but
that's when using them in a standard VB6 project and not as an addin for
Outlook. Have you tried creating a simple quick stand alone VB project which
does nothing other than pop up the font dialog (perhaps using the API
method) and which has no error checking and send it to your own users who
have the problem and ask them to run it for you as a simple test. At least
then you'll have an idea as to whether it is an Outlook problem or not.
Alternatively, how about sending a new version of your DLL (purely for test
purposes) to the users with the problem, one in which you create a simple
font dialog yourself in code and populate the list using EnumFontFamiliesEx,
just to see if it works okay. Check it first at your own end of course.
Mike

I have emailed my client who is working with me and offered him a test stand
alone project and am awaiting a reply.

-mike

[-mhd]

Post by Mike Williams
Both the API method and the common dialog method work under Win7 here, but
that's when using them in a standard VB6 project and not as an addin for
Outlook. Have you tried creating a simple quick stand alone VB project which
does nothing other than pop up the font dialog (perhaps using the API
method) and which has no error checking and send it to your own users who
have the problem and ask them to run it for you as a simple test. At least
then you'll have an idea as to whether it is an Outlook problem or not.
Mike

I have finally got the results back from a single tester to whom I sent the same
project modified to run outside of Outlook. This is with using the API and not
the common dialog control.

The font dialog pops just fine. Running inside Outlook it just gives a brief
flash/flicker.

I cannot Google any reference to Outlook 2010 causing this behavior to com
addins.

It only happens to a few users (that bother to tell me - maybe they just move on
to another product) and I cannot replicate the behavior on my PC. Other than
knowing it happens only with Outlook 2010 32bit running on Win 7 32 or 64 bit.

-mike

[-mhd]

I am testing a new theory based on the fact the user saw a flicker. I pass
Me.Hwnd to the dialog function and I'm not sure what Outlook hosting my form can
do to affect that value so I changed the "Me" reference to the form name
instead. Sure would be nice if its that simple.

I guess I'll just have to wait until my user gets back to me.

-mike

[j***@gmail.com]

Post by -mhd
I am testing a new theory based on the fact the user saw a flicker. I pass
Me.Hwnd to the dialog function and I'm not sure what Outlook hosting my form can
do to affect that value so I changed the "Me" reference to the form name
instead. Sure would be nice if its that simple.
I guess I'll just have to wait until my user gets back to me.
-mike

Hi Mike,

I'm having a similar issue, except it's with an ActiveX control that should pop up the font dialog in the browser. It was working in Windows XP with IE 6, and possibly even working in Win 7 up until this year, then it stopped working. The symptoms are just as you described - a flash, then nothing happens.

Did you manage to come up with a solution? I've tried all I could to no avail so far.

Regards,
Justin

[Mayayana]

On Thursday, September 13, 2012 at 2:50:04

Did you manage to come up with a solution?
Who do you think you're talking to? The post you
answered is more than two years old. If you
get off of Google Groups and get a real newsreader
you could see current posts, and ask your own
question.