Hello all,

I've got a small program in which I would like to be able to invoke the
"send to" dialog. ComDlg32.dll doesn't seem to offer it, and a quick-ish
websearch returns all kinds of results, but not in the direction I need. :-\

Remark: I know that I can populate a listbox with the contents of the "send
to" folder (doing everything myself), but I really would like to be lazy and
just call the one thats already there. :-)

Regards,
Rudy Wieser

On Thu, 27 Jul 2023 09:19:51 +0200, R.Wieser wrote:
> Hello all,
>
> I've got a small program in which I would like to be able to invoke the
> "send to" dialog. ComDlg32.dll doesn't seem to offer it, and a quick-ish
> websearch returns all kinds of results, but not in the direction I need. :-\
>
> Remark: I know that I can populate a listbox with the contents of the "send
> to" folder (doing everything myself), but I really would like to be lazy and
> just call the one thats already there. :-)
>
> Regards,
> Rudy Wieser

What "Send to" dialog? IIRC, there's no "Send to" dialog.

Since you're expecting it as a common dialog, you can use
`SHBrowseForFolder()` to only display the content of the "Send to" folder
(as the root folder display; so that users can't go to the parent folder),
and to only display files. Though, you still need to manually execute the
chosen file.

JJ,

> What "Send to" dialog? IIRC, there's no "Send to" dialog.

Yeah, I stated that a bit off I'm afraid. Its the right-click -> "send to"
submenu I was talking about.

> Since you're expecting it as a common dialog, you can use
> `SHBrowseForFolder()` to only display the content of the "Send to"
> folder

In my case that would also show a number if items I've suppressed (appended
an exclamation mark to the extension of some, and as such don't show up in
the "send to" context menu), which isn't quite what I have in mind.

Also, it would not show something like the "DVD-RW drive" entry (which must
have been put into the context menu by other means).

Thanks for the reply though. It looks like the lazy option doesn't exist.
:-( :-)

Regards,
Rudy Wieser

R.Wieser wrote:

> JJ,
>
>> What "Send to" dialog? IIRC, there's no "Send to" dialog.
>
> Yeah, I stated that a bit off I'm afraid. Its the right-click -> "send
> to" submenu I was talking about.

That's just a folder in the user's home directory, %USERPROFILE%\SendTo. (On
modern systems, that redirects to %APPDATA%\Microsoft\Windows\SendTo.) Grab
all files in that directory (except desktop.ini, of course) and use that to
build a menu, filtering out the ones you don't want to display. The clickable
text is the name of the file (sans extension) and for the action just invoke
the file directly.

--
I overclocked my mouse pad.

On Thu, 27 Jul 2023 16:43:25 +0200, R.Wieser wrote:
> JJ,
>
>> What "Send to" dialog? IIRC, there's no "Send to" dialog.
>
> Yeah, I stated that a bit off I'm afraid. Its the right-click -> "send to"
> submenu I was talking about.
>
>> Since you're expecting it as a common dialog, you can use
>> `SHBrowseForFolder()` to only display the content of the "Send to"
>> folder
>
> In my case that would also show a number if items I've suppressed (appended
> an exclamation mark to the extension of some, and as such don't show up in
> the "send to" context menu), which isn't quite what I have in mind.
>
> Also, it would not show something like the "DVD-RW drive" entry (which must
> have been put into the context menu by other means).
>
> Thanks for the reply though. It looks like the lazy option doesn't exist.
> :-( :-)

The "Send to" context menu is handled by a built in shell extension. To
programmatically use it, your program will have to act like a shell explorer
which support shell extensions.

i.e. load the shell extension. Enumerate its menus. Then invoke the needed
menu.

Note: the shell extension must be initialized with the file/folder for the
shell extension to work with. Otherwise the shell extension may create the
incorrect set of menu items.

Auric,

> That's just a folder in the user's home directory, %USERPROFILE%\SendTo.

As mentioned in my prevous post here, not quite. The context dialog list
both has items that are not in that folder and vise-verse.

> Grab all files in that directory (except desktop.ini, of course) and use
> that to build a menu, filtering out the ones you don't want to display.

As remarked in my initial post I know that I can do that.

But I currently have little wish to re-create something if I can just use
something thats already there. Besides the issue of duplicating the
context-menu's filtering rules.

As for the "filtering", do you have any idea where an entry like "DVD-RW
(D:)" comes from ? Or how you would ultimatily invoke such an entry on the
provided file(s)/folder(s) ?

IOW, there is a good reason why I want to use the build-in method instead of
trying to build my own one.

Regards,
Rudy Wieser

JJ,

> Note: the shell extension must be initialized with the file/folder for
> the shell extension to work with. Otherwise the shell extension may
> create the incorrect set of menu items.

That would be a problem. I do not have /a/ folder, my items could come
from all over the place (multiple drives even).

Regards,
Rudy Wieser

R.Wieser wrote:

> Auric,
>
>> That's just a folder in the user's home directory, %USERPROFILE%\SendTo.
>
> As mentioned in my prevous post here, not quite. The context dialog list
> both has items that are not in that folder and vise-verse.
>
>> Grab all files in that directory (except desktop.ini, of course) and use
>> that to build a menu, filtering out the ones you don't want to display.
>
> As remarked in my initial post I know that I can do that.
>
> But I currently have little wish to re-create something if I can just use
> something thats already there. Besides the issue of duplicating the
> context-menu's filtering rules.
>
> As for the "filtering", do you have any idea where an entry like "DVD-RW
> (D:)" comes from ? Or how you would ultimatily invoke such an entry on the
> provided file(s)/folder(s) ?
>
> IOW, there is a good reason why I want to use the build-in method instead
> of trying to build my own one.

Sorry, I missed basically all of the above, else I wouldn't have posted. My
apologies.

--
That last statement alone pushes the story from "sad" to
"heartbreakingly tragic."

On Fri, 28 Jul 2023 08:48:55 +0200, R.Wieser wrote:
> JJ,
>
>> Note: the shell extension must be initialized with the file/folder for
>> the shell extension to work with. Otherwise the shell extension may
>> create the incorrect set of menu items.
>
> That would be a problem. I do not have /a/ folder, my items could come
> from all over the place (multiple drives even).

The "Send to" context menu is applicable on multiple selections - even on
different drives or computer. i.e. multiple sources, one destination.

Thus, the source file(s)/folder(s) can came from multiple and different
folders/drives/computers. Like how the "Send to" menu is still applicable on
multiple selected items which are from Explorer find files (which returns
files from different folders/drives/computers).

From programmer's perspective, for a custom/predefined list of sources, we
can't use or rely on the "Explorer find" feature. The list will have to be
built manually.

Basically, you program will need to be a host process for a shell extension.
A process which specifically chooses which shell extension to use. Rather
than relying the shell component to do everything - which ends up not
providing any fine control to a host process.