IShellFolder::ParseDisplayName called with strange arguments

IShellFolder::ParseDisplayName called with strange arguments

Post by Le Chaud Lap » Thu, 20 Mar 2003 15:38:35



Has anyone had any experience with ParseDisplayName being called "out
of the blue" with weird arguments?

When I expand a 2nd-level folder (just under my root), mine is being
called with the following (weird) arguments:

this          0x02201e40 (seems to be right for my 2nd-level folder)
hwndOwner     0x00c2f1f8 (bogus handle, I checked)
pbcReserved   0x000CC640
lpDisplayName 0x00000000
pdwEaten      0x00000000
pPidlNew      0x00000000
pdwAttributes 0x02201e40 (NOTE - always same value as 'this' pointer)

While trying to find the source of a crash that occured after
CreateViewObject was called, I noticed that, whether I provided an
IShellView or not, ParseDisplay name would be consistently called for
no reason.

I understand the workings of WantsForParsing and other reasons why
ParseDisplayName would be called, but in this case, there is no reason
at all.

At no time do I ever return a display name from GetDisplayNameOf.  And
though I do have WantsForParsing set in the registry, my
GetDisplayName always returns E_NOTIMPL on the first line of the
function.

Furthermore, just to be sure, I went to another namespace extension (I
am writing 2), and this behaviour does not occur in the 2nd one.  A no
time is GetDisplayNameOf called during the expansion of my NSE tree.

I look at the value denoted as the 'this' pointer for
ParseDisplayName, and it looks correct - the data that it contains
seems to be right.  However, the arguments to the function are
obviously wrong, and in any case, this method should not be called.

The only thing I can think of is that the virtual function table of my
2nd level folder is being corrupted somehow, but I am not doing
anything out of the ordinary to cause this.

-John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Maksym Schipk » Fri, 21 Mar 2003 01:27:19


Though I've never had such a behaviour, it seems to me like your stack is
broken... Have a look at Call Stack window with debug symbols for Windows
installed - it would show some garbage if I'm right.

OR the vtbl for the object is broken and though the system thinks it calls a
different function, the vtbl points to this one.

--
Best regards,
  Mr Maksym Schipka
  Senior Software Developer
  Invisimail IOM Ltd


Quote:> Has anyone had any experience with ParseDisplayName being called "out
> of the blue" with weird arguments?

> When I expand a 2nd-level folder (just under my root), mine is being
> called with the following (weird) arguments:

> this          0x02201e40 (seems to be right for my 2nd-level folder)
> hwndOwner     0x00c2f1f8 (bogus handle, I checked)
> pbcReserved   0x000CC640
> lpDisplayName 0x00000000
> pdwEaten      0x00000000
> pPidlNew      0x00000000
> pdwAttributes 0x02201e40 (NOTE - always same value as 'this' pointer)

> While trying to find the source of a crash that occured after
> CreateViewObject was called, I noticed that, whether I provided an
> IShellView or not, ParseDisplay name would be consistently called for
> no reason.

> I understand the workings of WantsForParsing and other reasons why
> ParseDisplayName would be called, but in this case, there is no reason
> at all.

> At no time do I ever return a display name from GetDisplayNameOf.  And
> though I do have WantsForParsing set in the registry, my
> GetDisplayName always returns E_NOTIMPL on the first line of the
> function.

> Furthermore, just to be sure, I went to another namespace extension (I
> am writing 2), and this behaviour does not occur in the 2nd one.  A no
> time is GetDisplayNameOf called during the expansion of my NSE tree.

> I look at the value denoted as the 'this' pointer for
> ParseDisplayName, and it looks correct - the data that it contains
> seems to be right.  However, the arguments to the function are
> obviously wrong, and in any case, this method should not be called.

> The only thing I can think of is that the virtual function table of my
> 2nd level folder is being corrupted somehow, but I am not doing
> anything out of the ordinary to cause this.

> -John-


 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Henk Devo » Fri, 21 Mar 2003 06:45:33


Or maybe you return the wrong interface in a QueryInterface call?


> Though I've never had such a behaviour, it seems to me like your stack is
> broken... Have a look at Call Stack window with debug symbols for Windows
> installed - it would show some garbage if I'm right.

> OR the vtbl for the object is broken and though the system thinks it calls
a
> different function, the vtbl points to this one.

> --
> Best regards,
>   Mr Maksym Schipka
>   Senior Software Developer
>   Invisimail IOM Ltd


> > Has anyone had any experience with ParseDisplayName being called "out
> > of the blue" with weird arguments?

> > When I expand a 2nd-level folder (just under my root), mine is being
> > called with the following (weird) arguments:

> > this          0x02201e40 (seems to be right for my 2nd-level folder)
> > hwndOwner     0x00c2f1f8 (bogus handle, I checked)
> > pbcReserved   0x000CC640
> > lpDisplayName 0x00000000
> > pdwEaten      0x00000000
> > pPidlNew      0x00000000
> > pdwAttributes 0x02201e40 (NOTE - always same value as 'this' pointer)

> > While trying to find the source of a crash that occured after
> > CreateViewObject was called, I noticed that, whether I provided an
> > IShellView or not, ParseDisplay name would be consistently called for
> > no reason.

> > I understand the workings of WantsForParsing and other reasons why
> > ParseDisplayName would be called, but in this case, there is no reason
> > at all.

> > At no time do I ever return a display name from GetDisplayNameOf.  And
> > though I do have WantsForParsing set in the registry, my
> > GetDisplayName always returns E_NOTIMPL on the first line of the
> > function.

> > Furthermore, just to be sure, I went to another namespace extension (I
> > am writing 2), and this behaviour does not occur in the 2nd one.  A no
> > time is GetDisplayNameOf called during the expansion of my NSE tree.

> > I look at the value denoted as the 'this' pointer for
> > ParseDisplayName, and it looks correct - the data that it contains
> > seems to be right.  However, the arguments to the function are
> > obviously wrong, and in any case, this method should not be called.

> > The only thing I can think of is that the virtual function table of my
> > 2nd level folder is being corrupted somehow, but I am not doing
> > anything out of the ordinary to cause this.

> > -John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Le Chaud Lap » Fri, 21 Mar 2003 11:38:31



> Or maybe you return the wrong interface in a QueryInterface call?

Hi Henk,

I was thinking that, so I went through each of my QueryInterface's and
checked, but they all looked good.  At least I know now that this
particular problem (ParseDisplayName) has nothing to do with
CreateViewObject (dummied that out).

Regards,

-John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Le Chaud Lap » Fri, 21 Mar 2003 14:13:50


Henk, Jim, & Maksym,

You were right.  It was the virtual function table.

I vaguely remeber a while back making the (false) assumption that
IShellFolder inherited IPersistFolder, so when I wrote my
IShellFolder.hpp, I did this...

    class StorageShellFolder : public IShellFolder

when I should have done this...

    class StorageShellFolder : public IShellFolder, public
IPersistFolder

Then, in my QueryInterface, I wrote this....

    else if(IsEqualIID(riid, IID_IPersistFolder))
            *ppReturn = (IPersistFolder *) this;

So of course, shell32.dll was invoking whatever entry there was in the
vtbl, which turned out to be my ParseDisplayName.  Strangely, looking
at my logic, it was written in such a way that the code actually
worked without visibile error with Windows 2000 SP1, but not with
Windows 2000 SP3.  dynamic_cast would have caught this, but that
implies C++, etc..

I am going to go through both my namespace extensions and change all
the type casting to static_cast<>() like I was wanted to do but didn't
when I first started them.

Thanks a lot guys,

-John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Chris Guzak [MS » Fri, 21 Mar 2003 18:49:48


you can avoid bugs like this by using one of the safer cast operators and
letting the compiler catch this at compile time.  write

*ppv = static_cast<IPersistFolder*>(this);

Chris Guzak (MS)
standard disclaimer



Quote:> Henk, Jim, & Maksym,

> You were right.  It was the virtual function table.

> I vaguely remeber a while back making the (false) assumption that
> IShellFolder inherited IPersistFolder, so when I wrote my
> IShellFolder.hpp, I did this...

>     class StorageShellFolder : public IShellFolder

> when I should have done this...

>     class StorageShellFolder : public IShellFolder, public
> IPersistFolder

> Then, in my QueryInterface, I wrote this....

>     else if(IsEqualIID(riid, IID_IPersistFolder))
>             *ppReturn = (IPersistFolder *) this;

> So of course, shell32.dll was invoking whatever entry there was in the
> vtbl, which turned out to be my ParseDisplayName.  Strangely, looking
> at my logic, it was written in such a way that the code actually
> worked without visibile error with Windows 2000 SP1, but not with
> Windows 2000 SP3.  dynamic_cast would have caught this, but that
> implies C++, etc..

> I am going to go through both my namespace extensions and change all
> the type casting to static_cast<>() like I was wanted to do but didn't
> when I first started them.

> Thanks a lot guys,

> -John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Maksym Schipk » Fri, 21 Mar 2003 22:43:52


Glad it helped.

Btw, this is another advantage of using dynamic_cast, static_cast and
const_cast over old C-style typecasting. I will use it as another argument
when somebody here tries to mention to me again that I write an exessive
code by doing dynamic_cast<IShellFolder *> instead of (IShellFolder *).

--
Best regards,
  Mr Maksym Schipka
  Senior Software Developer
  Invisimail IOM Ltd


Quote:> Henk, Jim, & Maksym,

> You were right.  It was the virtual function table.

> I vaguely remeber a while back making the (false) assumption that
> IShellFolder inherited IPersistFolder, so when I wrote my
> IShellFolder.hpp, I did this...

>     class StorageShellFolder : public IShellFolder

> when I should have done this...

>     class StorageShellFolder : public IShellFolder, public
> IPersistFolder

> Then, in my QueryInterface, I wrote this....

>     else if(IsEqualIID(riid, IID_IPersistFolder))
>             *ppReturn = (IPersistFolder *) this;

> So of course, shell32.dll was invoking whatever entry there was in the
> vtbl, which turned out to be my ParseDisplayName.  Strangely, looking
> at my logic, it was written in such a way that the code actually
> worked without visibile error with Windows 2000 SP1, but not with
> Windows 2000 SP3.  dynamic_cast would have caught this, but that
> implies C++, etc..

> I am going to go through both my namespace extensions and change all
> the type casting to static_cast<>() like I was wanted to do but didn't
> when I first started them.

> Thanks a lot guys,

> -John-

 
 
 

IShellFolder::ParseDisplayName called with strange arguments

Post by Le Chaud Lap » Sat, 22 Mar 2003 00:52:00


Hey, I have a novel idea:

How about I use static_cast<> to avoid the bug I had?

;)

-John-


> you can avoid bugs like this by using one of the safer cast operators and
> letting the compiler catch this at compile time.  write

> *ppv = static_cast<IPersistFolder*>(this);

> Chris Guzak (MS)
> standard disclaimer



> > Henk, Jim, & Maksym,

> > You were right.  It was the virtual function table.

> > I vaguely remeber a while back making the (false) assumption that
> > IShellFolder inherited IPersistFolder, so when I wrote my
> > IShellFolder.hpp, I did this...

> >     class StorageShellFolder : public IShellFolder

> > when I should have done this...

> >     class StorageShellFolder : public IShellFolder, public
> > IPersistFolder

> > Then, in my QueryInterface, I wrote this....

> >     else if(IsEqualIID(riid, IID_IPersistFolder))
> >             *ppReturn = (IPersistFolder *) this;

> > So of course, shell32.dll was invoking whatever entry there was in the
> > vtbl, which turned out to be my ParseDisplayName.  Strangely, looking
> > at my logic, it was written in such a way that the code actually
> > worked without visibile error with Windows 2000 SP1, but not with
> > Windows 2000 SP3.  dynamic_cast would have caught this, but that
> > implies C++, etc..

> > I am going to go through both my namespace extensions and change all
> > the type casting to static_cast<>() like I was wanted to do but didn't
> > when I first started them.

> > Thanks a lot guys,

> > -John-

 
 
 

1. PRB: IShellFolder::ParseDisplayName and '..'

Hello,

I've discovered an inconsistency in this method, regarding the parsing
of paths containing the '..' parent folder specifier. If you try an
absolut path like "C:\winnt\.." then it fails (parsing from desktop). I
know that this path don't makes much sense <g> but why should it fail?
Here's some sample code:

/* path exists on disk */
LPWSTR absPath = L"C:\\winnt\\..";

/* assume pIDeskFolder is valid IShellFolder*
 * obtained earlier, pointing at the namespace root.
 */

LPITEMIDLIST pidl;
DWORD chEaten;
HRESULT hr;

/* this fails, returned pidl==NULL */
hr = pIDeskFolder->ParseDisplayName(NULL, NULL, absPath,
   &chEaten, &pidl, NULL);

ASSERT(hr == 0x80004005); /* "unspecified error" */

Trying a ::SetCurrentDirectory() on this path works ok (but
FIndFirstFile fails, too). Why should there be such a discrepancy? If
this is by design, what's the proper route to parse paths containing
'..'?

Thanks,
Nikos

--
TSEK-IT: http://personal-pages.ps.ic.ac.uk/~umeca74/
2xExplorer R7 just made windows Explorer obsolete

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Assistance with PDH.DLL

3. IShellFolder::ParseDisplayName unknown

4. Start menu button

5. Caching IShellFolders for IShellFolder::BindToObject

6. Loosing LFN when restoring ArcServe 5.01g on a 3.12 server

7. repeated IShellFolder Calls on Win XP

8. FS: Sharp to MAC Comm. Cable $40

9. strange message: CTRYTHOUSANDSEPARATOR requires an argument

10. Call VBA Sub with arguments from Excel sheet

11. Calling a user specified function with array arguments in VBA

12. Dynamic Funtion Calls and Arguments

13. DBI-1.29: Wrong number of arguments in call of macro 'fp_dup'