Prev: CMFCRibbonButton pressed state, how to do that ?
Next: converting vc++2005 project to VC++2008
From: Joseph M. Newcomer on 22 Feb 2008 14:05
Yes, that's exactly what he means.

But I wouldn't know how to disable them, either. Note that if it is only one app that has
this problem, the problem may be the app environment as I indicated earlier.

Shell extensions are somewhat of a nightmare in this regard.
joe
On Fri, 22 Feb 2008 08:55:05 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote:

>
>
>"Norbert Unterberg" wrote:
>
>>
>> Opening the file open dialog causes possibly all explorer shell
>> extensions and plug-ins to be loaded into your application's context.
>> The file open dialog contains a full featured explorer window.
>>
>> So it can actually happen that some shell extension does not work
>> correctly within your application.
>>
>> You should try to remove some of the shell extension. Does anybody know
>> a tool to display (and disable) all extensions that are registered and
>> hooked into explorer?
>>
>> Norbert
>>
>
>I am afraid that I do not have the necessary background to understand how to
>make use of this information. By 'shell extension', are you speaking of
>third-party things that integrate themselves into the Explorer interface?
>(e.g. WinZip, Tortoise-SVN, etc.)
>
>I am certainly more than happy to disable such extensions - as a debugging
>mechanism if nothing else. However, I do not know how to determine what
>extensions I may have running, nor how to actually disable them once
>identified.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 22 Feb 2008 14:07
At this point, I'd start doing a lot more detailed single-stepping. It sounds like you
have some serious stack damage. An example would be stack damage that causes a return to
a place where there is a set of instructions that go into an infinite loop.

This is just a guess. Confronted with this problem, I'd do a LOT of single step
debugging.

Also, if you have access to a machine that is fairly simply configured (no shell
extensions) try running it on that machine. If it comes up successfully, it *might* be
the shell extensions problem suggested earlier.
joe

On Fri, 22 Feb 2008 09:06:02 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote:

>
>
>"Alexander Grigoriev" wrote:
>
>> Make sure you don't call CoInitializeEx(COINIT_MULTITHREADED) before that.
>
>I certainly do not call it explicitly. However, if operations upon some
>other MFC object may have invoked this 'under the hood', I wouldn't know.
>
>> When you get the call to hang, break inside the debugger and check the call
>> stack.
>
>I tried that before my orignal post (guess I should have indicated such -
>sorry). Upon Hitting the Break All button, I get the following dialog:
>
>Microsoft Visual Studio [?][X]
><!> No symbols can be loaded for any call stack frame. The source code
>cannot be displayed.
>[_] Show disassembly automatically
> [ OK ] [Show Disassembly]
>
>I have tried to decipher what the assembly code is trying to do. However,
>the lack of symbols makes this rather inscrutable as well.
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 22 Feb 2008 14:14
See below...
On Thu, 21 Feb 2008 22:22:01 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote:

>
>
>"Joseph M. Newcomer" wrote:
>
>> There was a disaster in the VS6-XP versions because of a change in the size of the file
>> dialog.
>
>So am I to assume that I should not have any such issues, as I am using a
>subsequent release of VS?
****
Yes. Newer versions of VS would not show this problem
****
>
>> Note that phenomena such as having too many windows, running out of GDI space, etc. can
>> result in some of the problems you are seeing. So key here is to replicate the
>> environment. I (and others) can do
>> CFileDialog dlg(TRUE);
>> dlg.DoModal();
>>
>> without problem, so if it is failing for you, there is something else wrong. But since it
>> is impossible to intuit what your entire environment must be like, it is hard to do more
>> than guess.
>
>This gives me my first insight. I had been thinking in terms of something
>wrong with my application directly, rather than an environmental issue. I
>took a detour to run another app that I built last week, which uses the same
>code. While it used to operate just fine, it now exhibits the same inability
>to DoModal().
****
OK, going back to some of the other suggestions that have been made:

if it is a problem with shell extensions, you should see it in all apps

if it is a problem with resource exhaustion, you should see it if you run the failing
program, and while the failing program is running, the other program fails. The suggested
reboot-and-retry would indicate if it is the result of some progressive debilitation of
the system (perhaps some other random program is consuming all the resources, for example,
and your program, and now the other program, are victims of a drive-by resource hogging)

A weird idea, but just for jollies, try to launch a color dialog, which uses a lot of
resources. If it is ONLY CFileDialog, then it could be the explorer, or some of the other
ideas I suggested. If CColorDialog doesn't come up, it is likely to be a resource
problem. Whether it is your app consuming the resources, or some other app (watch out for
background programs that come up when you log in!), you would see the same kind of
failure. I'd give it a shot just to see if the problem appears when any complex dialog
comes up, or if it is restricted to CFileDialog.
****
>
>> I'd look at resource exhaustion as a likely candidate. Can you write a trivial example
>> that just does the CFileDialog dlg(TRUE) as above, in a little test app, and see it work?
>> If so, then the problem is the environment your app is presenting to it. Programs like
>> the process viewer (from www.sysinternals.com) could give some figures about things like
>> GDI handle usage; if the numbers are far out of line, this could be the problem.
>
>I'll see if I can find said process viewer. I have used other sysinternals
>tools before (I recall something that monitored accesses to COM and LPT
>ports). I'll report back with any findings. In the meantime, if you have any
>links to a 'process viewer 101 training doc', it would be most appreciated.
****
It comes with documentation. What you're looking for is handle consumption and GDI
resource consumption.
joe
****
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 22 Feb 2008 14:26
In desperation in certain situations, I single step into assembly code instructions.
Getting lost is not the problem. Seeing where it finally hangs can be interesting.

Your problem is probably completely unrelated to MFC; it is probably much deeper. For
example, stack damage is not MFC-related.

I looked in my VS2005 source listings, and there is no such line in my copy of
afxcomctl32.h. The fact that it goes through it several times, though, is definitely
suspect.
joe

On Thu, 21 Feb 2008 22:11:00 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote:

>
>
>"Joseph M. Newcomer" wrote:
>
>> So that means you haven't stepped deeply enough; you should have tried to Step Into.
>
>As reported in the OP, I did step into the DoModal() call. Indeed, I stepped
>deep enough that I was soon lost in a forest of dense inscrutable macros.
>This may speak more to my limid mental capacity more than to anything else.
>However, it would seem to me that, if MFC works as advertised, I should not
>need to dig that deep.
>
>All ranting aside, I abandoned the hunt when I seemed to enter into a
>(seemingly) recursive loop, bringing me repeatedly through this
>indecipherable line in afxcomctl32.h:
>AFX_ISOLATIONAWARE_FUNC(BOOL,GetOpenFileNameW,(LPOPENFILENAMEW
>unnamed1),(unnamed1),FALSE)
>Why the code would tread through that invocation over a handful of times is
>beyond me. Any guesses?
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 22 Feb 2008 14:27
Sorry, I misremembered the name. Yes, process explorer.
joe

On Thu, 21 Feb 2008 22:27:01 -0800, jbreher <jbreher(a)discussions.microsoft.com> wrote:

>
>
>"Joseph M. Newcomer" wrote:
>
>
>> If so, then the problem is the environment your app is presenting to it. Programs like
>> the process viewer (from www.sysinternals.com) could give some figures about
>
>Quick follow-up question - I don't seem to be able to locate any "process
>viewer" from sysinternals. Might you be referring to their "Process Explorer"?
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: CMFCRibbonButton pressed state, how to do that ?
Next: converting vc++2005 project to VC++2008