Hi,

I have a shell extension that's giving inconsistent results if both a 
shortcut and a file are selected.  In IShellExtInit.Initialize I render 
the IDataObject to a CF_HDROP and use DragQueryFile to get the paths, 
but the results are the same if I render it to a CFSTR_SHELLIDLIST.

If the focus rect is on the file then I get two paths, the file first, 
and then the shortcut.  If the focus rect is instead on the shortcut 
then I only get one path, and it's the resolved target of the link.

Any idea what's going on?  How can I consistently get two paths in this 
case?

Thanks,
Craig Peterson
Scooter Software

>I have a shell extension that's giving inconsistent results if both a 
>shortcut and a file are selected.  In IShellExtInit.Initialize I render 
>the IDataObject to a CF_HDROP and use DragQueryFile to get the paths, 
>but the results are the same if I render it to a CFSTR_SHELLIDLIST.
>
>If the focus rect is on the file then I get two paths, the file first, 
>and then the shortcut.  If the focus rect is instead on the shortcut 
>then I only get one path, and it's the resolved target of the link.
>
>Any idea what's going on?

Hi Craig,

It appears to be what Explorer does! I've noticed the same behaviour
with my own shell extensions and couldn't find a solution (there may
be one, but I couldn't suss it).

Dave

Hello Craig,

From your post, my understanding on this issue is: when both a file and a 
shortcut (lnk) are selected in windows explorer, our shell extension 
IShellExtInit.Initialize only gets the shortcut's name if the focus rect is 
on the shortcut. If I'm off base, please feel free to let me know.

I reproduced the issue when I set the shell call for any file by 
registering as a context menu handler under the HKCR\* key. The resolution 
is to register it under the HKCR\lnkfile key along with the HKCR\* key:

Part of my test rgs file is as follows:

    NoRemove *
    {
        NoRemove ShellEx
        {
            NoRemove ContextMenuHandlers
            {
                ForceRemove SimpleShlExt = s 
'{5E2121EE-0300-11D4-8D3B-444553540000}'
            }
        }
    }
	NoRemove lnkfile
    {
        NoRemove ShellEx
        {
            NoRemove ContextMenuHandlers
            {
                 ForceRemove SimpleShlExt = s 
'{5E2121EE-0300-11D4-8D3B-444553540000}'
            }
        }
    }

The lnkfile is treated as a special case by windows explorer. After 
registering lnkfile for the shell extension, the lnkfile will be treated as 
normal file as others. Craig, and David, please have a try and let me know 
if it works for you.

Regards,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
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: 
msdnmg@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.

Jialiang Ge [MSFT] wrote:

> I reproduced the issue when I set the shell call for any file by 
> registering as a context menu handler under the HKCR\* key. The resolution 
> is to register it under the HKCR\lnkfile key along with the HKCR\* key:

This was also one of my long term problems.  Perfect, it works now!

But: Now I get called twice for .Initialize() one for the
derefenced file, and once for the shortcut itself.

How Do I know which is which? Just parse the filename extension .lnk?
Or is there any other way?

Anyway: Your solution works perfect. Thanks!!

	Ciao Hermann

Thank you for the information, your understanding is correct. 
Unfortunately that doesn't completely solve my issue.

As Hermann pointed out, this does get both files consistently, but it's 
actually creating two copies of my object now, and calling 
Initialize/QueryContextMenu on both of them, resulting in multiple menu 
items.  The first Initialize call is always the resolved path to the 
shortcut, and Initialize's hKeyProgID parameter is the resolved class too.

Is there a way to detect this situation so I know to wait for the second 
Initialize/QueryContextMenu calls before adding my menu items?

Thanks again,
Craig

>I reproduced the issue when I set the shell call for any file by 
>registering as a context menu handler under the HKCR\* key. The resolution 
>is to register it under the HKCR\lnkfile key along with the HKCR\* key:

Adding an entry for my context menu extension under lnkfile as well as
* does make things consistent for me in that the shortcut file itself
(not its resolved target) is what's presented to my extension.

However, I'm not getting 2 occurrences of my extension called as Craig
and Hermann are!

I'm testing under XP - dunno if Vista is any different!

Dave

David Lowndes wrote:
> I'm testing under XP - dunno if Vista is any different!

I have been doing most of my testing on Vista, but I just checked XP SP2 
and I'm seeing the same incorrect behavior.

Craig

>> I'm testing under XP - dunno if Vista is any different!
>
>I have been doing most of my testing on Vista, but I just checked XP SP2 
>and I'm seeing the same incorrect behavior.

So am I now I've tried it again!

At this stage I can only put it down to finger trouble on my part.

Dave

Thank you for the feedback. I also see the side effect that 
IContextMenu::QueryContextMenu is called twice. Based on my further tests 
and researches, this side effect may be fixed by suppressing the context 
menu received via the * registration on lnk files, and add only one menu 
item to the context menu using these 2 instances. In other words, if a 
lnkfile menu has been added to the context menu, then do nothing. If a 
non-link file has been added, and we detect that the first file from 
DragQueryFile is a lnk file, then remove it and add the lnkfile. 

Craig, Please also note that the order in which our context menu extension 
is called is not guaranteed. It may be called for the lnkfile registration 
before the * registration on some systems and after on others. Relying on 
this order will lead to invalid and unpredictable results. Therefore, we 
cannot reply on the order of Initialize to decide which is which and which 
one to suppress.

Regards, 
Jialiang Ge  (jialge@online.microsoft.com, remove 'online.')
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: 
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

Thank you for the additional information.  Our shell extension is now 
working exactly like I want it to. :)

Best Regards,
Craig Peterson
Scooter Software

Craig Peterson wrote:
> Thank you for the additional information.  Our shell extension is now 
> working exactly like I want it to. :)

Aehm, did I miss something? I still have the problem, that I get called
twice
	
		Ciao Hermann

>> Thank you for the additional information.  Our shell extension is now 
>> working exactly like I want it to. :)
>
>Aehm, did I miss something? I still have the problem, that I get called
>twice

I must admit that I didn't get the gist of this:

"Based on my further tests and researches, this side effect may be
fixed by suppressing the context menu received via the * registration
on lnk files, and add only one menu item to the context menu using
these 2 instances. In other words, if a lnkfile menu has been added to
the context menu, then do nothing. If a non-link file has been added,
and we detect that the first file from DragQueryFile is a lnk file,
then remove it and add the lnkfile. 
"

Could Jialiang Ge explain it a bit further please?

Thanks
Dave

Hermann Schinagl wrote:
> Aehm, did I miss something? I still have the problem, that I get called
> twice

The problem still exists, but Jialiang's posts provide enough 
information to work around it.

To summarize:

The context menu has to be registered for both "*" and "lnkfile".  That 
results in two objects being created:  One will be called with a single 
filename (the resolved link target), and one will be called with all of 
the selected files with the original link filename in the first 
position.  There's no guarantee which will be called first.  If the 
shortcut isn't the focused one when only one object will be created.

How I worked around it:

1) In the object constructor I assign the object pointer of the first 
object created to a non-reference-counted global variable and in the 
destructor I clear it.

2) In IContextMenu.QueryContextMenu I store the Menu parameter and the 
IDs of added menu items in fields in the object.

3) In IShellExtInit.Initialize I check to see whether the global 
variable from (1) matches the current self pointer.  If it isn't it's 
the second object.

3a) If the first file in the IDataObject is a shortcut we're currently 
processing the full list, so I call DeleteMenu on all of the menu items 
added from the other object's QueryContextMenu to remove them, and the 
second QueryContextMenu will add the correct menu items.

3b) If the first file isn't a shortcut then we're processing the 
resolved link target, so just exit with an error code.  QueryContextMenu 
won't be called for the second instance.

Hope that helps,
Craig

OK I think I had the solution originally and temporarily discarded it
to test the shortcut...

STDMETHODIMP CShellExtension::QueryContextMenu( HMENU hMenu, UINT
indexMenu, UINT idCmdFirst, UINT idCmdLast, UINT uFlags  )
{
	bool bInsert = true;

	if (uFlags & CMF_VERBSONLY) 
	{
		/* Nothing for shortcuts */
		bInsert = false;
	}
	if ( uFlags & CMF_DEFAULTONLY )
	{
		bInsert = false;
	}

	if ( bInsert )
	{
		// Do the normal menu additions...
	}
	else
	{
		return NOERROR;
	}
}

By skipping the instance where CMF_VERBSONLY is set, and now having
the registry setting against lnkfile as well as *, I'm only seeing a
single menu item added, and the shortcut is presented as a file rather
than a resolved target.

Dave

Yes, exactly. Thank you, Craig, for the summary.

Registering both "*" and "lnkfile" should be on the right track of the 
issue. And an *unavoidable* side effect of this is the two objects being 
created. What we can do next is to find some workarounds to suppress one of 
the two, according to our *specific* design request. Craig's detailed steps 
show a workaround for his design request that all the lnk files should be 
treated as normal files. Hi Dave, I am not sure if I understand your design 
request correctly, if you have followup questions, would you send me an 
email and we can discuss it offline?

Regards, 
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
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: 
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

Jialiang Ge [MSFT] wrote:
> Registering both "*" and "lnkfile" should be on the right track of the
> issue. And an *unavoidable* side effect of this is the two objects
> being created. What we can do next is to find some workarounds to
> suppress one of the two, according to our *specific* design request.
> Craig's detailed steps show a workaround for his design request that
> all the lnk files should be treated as normal files. Hi Dave, I am
> not sure if I understand your design request correctly, if you have
> followup questions, would you send me an email and we can discuss it
> offline? 

Hi Jialiang, I'm interested in this issue and no doubt other people are too. Can we keep it on the newsgroup please? Craig's workaround sounds pretty hairy and I'd like to know whether there might be a cleaner approach.

-- 
Jim Barry, Microsoft MVP

>Hi Jialiang, I'm interested in this issue and no doubt other people are too. Can we keep it on the newsgroup please? Craig's workaround sounds pretty hairy and I'd like to know whether there might be a cleaner approach.

Checking CMF_VERBSONLY and omitting adding the menu seemed to work for
me.

Dave

Unless I'm missing something David's check results in the same behavior 
as the steps I gave, but in a much more succinct way. :)

So, the new answer to the question posted at the beginning of the thread 
appears to be:

1) Register as a handler for both "*" and "lnkfile".
2) In IContextMenu.QueryContextMenu if the uFlags argument has 
CMF_VERBSONLY set return 0 immediately.

You'll still have two objects created and Initialize/QueryContextMenu 
will be called on both of them, but only the one that corresponds to the 
original file list will add menu items.

Craig

Yes, I see. CMF_VERBSONLY is intended to help solve this problem. Sorry for 
my misunderstanding in the last reply, and thank you a lot for sharing it 
with us. :-)

Regards, 
Jialiang Ge  (jialge@online.microsoft.com, remove 'online.')
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: 
msdnmg@microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================