We have an application designed for google chrome where we need to add a link to the network file share. Unfortunately, Chrome denies the file:// protocol for security purposes. We want to set up a custom protocol to allow this functionality.
I thought a good way to do this would be to call explorer. Here are the registry keys we added:
[HKEY_CLASSES_ROOT\MyApp\DefaultIcon]
#="\"C:\\Windows\\explorer.exe\""
[HKEY_CLASSES_ROOT\MyApp\shell]
[HKEY_CLASSES_ROOT\MyApp\shell\open]
[HKEY_CLASSES_ROOT\MyApp\shell\open\command]
#="\" C:\\Windows\\explorer.exe\" \"%1\""
Currently, we get an error that states the protocol isn't valid. Could anyone assist in correcting this?
Thank you all very much in advance.
# Wolfram Schmied,
I just wrote a workaround on yours, using CMD:
REGEDIT4
[HKEY_CLASSES_ROOT\IntranetFileLauncher]
#="URL:IntranetFileLauncher Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\IntranetFileLauncher\DefaultIcon]
#="\"C:\\Windows\\explorer.exe\""
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell]
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell\open]
[HKEY_CLASSES_ROOT\IntranetFileLauncher\shell\open\command]
#="cmd /c set url=\"%1\" & call set url=%%url:intranetfilelauncher:=%% & call start explorer file:%%url%%"
The code above basically does the same as yours, except on the last line it uses cmd.exe to open a file/folder a command.
In pseudo code: open commandpromt, pass given filepath as variable 'url', alter variable 'url' by stripping the protocol identifier and finally open explorer with the stripped filepath
I hope this helpes.
I got the following to work on Windows 8 / Firefox.
The correct way to register a custom protocol is described in this MSDN article.
Sadly, you cannot apply this directly to the Windows Explorer. If you do, you'll find that the Explorer starts spawning copies until either your memory or your patience runs out, and you'll have to log off to stop it. The reason is that the application handling the protocol is passed the entire link including the protocol specification. I. e., if you have a link
localdir:D:\somefolder,
the resulting call will not be
explorer D:\somefolder,
but
explorer localdir:D:\somefolder.
This is apparently done so that the same application can handle several protocols. But Explorer doesn't recognize that it is meant to handle the request, and instead starts the resolution process anew, which sets the vicious circle in motion.
To deal with this, you call a simple helper app that removes the protocol specification from the argument, and then calls Explorer with the cleaned string.
As an example, I created a bare bones Java class Stripper.
import java.io.IOException;
public class Stripper {
public static void main(String[] args) {
String stripped = args[0].substring("localdir:".length());
try {
Runtime.getRuntime().exec("C:\\Windows\\explorer.exe "+stripped);
}
catch (IOException e) { /* error handling */ }
}
}
The following is a .reg file adding the required keys to the registry. This assumes that Stripper is located in the folde D:\Stripper.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\localdir]
#="URL: localdir Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\localdir\shell]
[HKEY_CLASSES_ROOT\localdir\shell\open]
[HKEY_CLASSES_ROOT\localdir\shell\open\command]
#="cmd /c \"cd /d d:\\Stripper & java Stripper %1\""
The command invokes the command line interpreter, telling it to first change to the directory containing our helper, and then to call the JRE to execute it. It's a bit awkward, but it works.
With a native .exe file, the command key could look like this:
[HKEY_CLASSES_ROOT\localdir\shell\open\command]
#="<somepath>Stripper.exe %1"
This is a quick'n'dirty solution, you'll want to obviously want to add checks and balances and probably more mechanics, but the general approach looks workable.
Same task here, same solution first as #mdbxz and after with VBScript to not showing cmd black box:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\explorer]
#="URL:VIR Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\explorer\shell]
[HKEY_CLASSES_ROOT\explorer\shell\open]
[HKEY_CLASSES_ROOT\explorer\shell\open\command]
#="mshta vbscript:Close(Execute(\"CreateObject(\"\"WScript.Shell\"\").Run Join(Array(\"\"iexplore.exe\"\",Replace(\"\"%1\"\",\"\"explorer\"\",\"\"https\"\"))), 1, True\"))"
The problem with these that if we click on same link in Explorer it handles the same, so it opens a new window, not just jump to the link. Also the question that if we want open the given app with the protocol.
Can we register the new protocol to Explorer, so it translate to https? Then we wont needed to replace protocol.
Related
no Error just nothing happen and file target still there in my path
public void keyboard(){
ProcessStartInfo touchkey = new ProcessStartInfo(#"C:\Program
Files\Common Files\microsoft shared\ink\TabTip.exe");
touchkey.WorkingDirectory = #"C:\";
touchkey.WindowStyle = ProcessWindowStyle.Hidden;
Process.Start(touchkey);
}
Update
The suggested solution threw a `UnauthorizedAccessException`:
var path = #"ms-appx://C:/Program Files/Common Files/microsoft
shared/ink/TabTip.exe";
var file = await
Windows.ApplicationModel.Package.Current.InstalledLocation.GetFileAsync(path);
await Windows.System.Launcher.LaunchFileAsync(file);
Update2
I try to use FullTrustProcessLauncher it's work fine but like code before Keyboard tabtip.exe not show I dont know what should I do
await Dispatcher.RunAsync(CoreDispatcherPriority.High, () =>
{
FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
});
UWP applications are sandboxed and cannot launch other processes directly due to security restrictions.
The only way to launch other applications is if those applications have a URI registered, or an application is a default handler for a particular file type.
In those instances, you can use methods such as LaunchUriAsync or LaunchFileAsync
Without TabTip.exe
I recognize you are trying to show the on-screen keyboard judging by the path of the exe. I suggest a better approach would be to trigger the new touch-enabled keyboard which is easily possible without additional hassle from UWP with InputPane API:
var pane = InputPane.GetForCurrentView();
pane.TryShow();
With TabTip.exe
If you prefer the older on-screen keyboard for some reason, you have two problems with your existing code.
Firstly, ms-appx: scheme is used to refer to files at the application installation path. The path you require is an absolute path, so you can't use it there.
Secondly, as this is an arbitrary path on the hard drive, you don't have access to it directly (as UWP apps run in a sandbox and can't access the filesystem directly for security reasons). To access the file, you will need to declare the broadFileSystemAccess capability, which will then allow you to initialize the StorageFile instance. You can check for example this SO question to learn how to do just that.
Note: I don't have my VS PC around so I can't say for sure if this will allow you to launch the executable or not, as that seems like an additional permission which may not be granted. In case this fails, I strongly recommend the first solution.
Make sure you edited the manifest file and add the extension for full trust process in the application.
I am looking for a good plugin showing Windows Explorer context menu directly from editor window in Eclipse. Does anybody know such plugin?
I'm a little late to the game with this answer, however since I found this article when trying to find a solution to this i'll post it here. There's an answer over at http://www.eclipsezone.com/eclipse/forums/t77655.html that solves this simply.
under Window -> External Tools -> External Tools Configuration
(1) Create a new Program (select Program in the tree)
(2) name it shell (or whatever you want)
(3) set the location to ${env_var:SystemRoot}\explorer.exe
(4) set the arguments to /select,${resource_loc}
(5) run it
for me it appears up in the tool bar at the top in it the little external tool run (run with a toolbox)
simple, effective and doesn't require any installation especially when all i really needed was to have a file focused, and rapidly get to the windows folder that contains it.
For people who don't want to install Aptana (It's kinda huge), here are a few plugins for a windows context menu in eclipse(and more):
contextmenu
Basic
Eclipse Navigator Extension
Basic + copy path
StartExplorer
Only opens explorer, but also does it on selected text (if it's a path) and has custom commands.
Some more info on Eclipse explorer menu's after trying them:
Failed to install (Some error with osgi)
Has 2 Eclipse context menu's:
Copy path (full, file, parent)
Show Context Menu (it's the basic version though, some of the context menu items that I can see in real Explorer don't show up here)
Has 1 Eclipse context menu (StartExplorer) with submenu's:
Show in File manager
Start Shell here
Open file with default application
Copy resource path to clipboard
Custom commands, which you can set in preferences and default ones:
Edit in notepad
echo to temp file
So, although (3) StartExplorer doesn't really have a context menu and everything sits in a submenu, the custom commands dominates in my opinion. It should allow a contextmenu through it (command to be found) or achieve what you want by cloning the behavior you want from your context menu.
It also seems like the code has been updated more recently than the others (and it supports multiple platforms)
For my custom paste I am not using the Paste from eclipse , I have created a new context menu Paste Objects by adding a new command .
I have added the handler : PasteObjectsHandler for the command which extends AbstractHandler .
Command
<command
categoryId="org.eclipse.ui.category.edit"
description="%pasteobjectscommand.description_xmsg"
id="com.test.pasteobjectscommand"
name="%pasteobjectscommand.name_xtit">
</command>
Handler
<handler
class="com.test.PasteObjectsHandler"
commandId=" com.test.pasteobjectscommand ">
</handler>
public class PasteObjectsHandler extends AbstractHandler {
#Override
public Object execute(ExecutionEvent event) {
Clipboard clipBoard = new Clipboard(Display.getDefault());
LocalTransfer instance = LocalTransfer.getInstance();
IResource clipboardData = (IResource) clipBoard.getContents(instance);
}
}
And in the handler I try to access the clipboard in the execute method . And I get null here .
I have written a plug-in that can open the Windows Explorer context menu:
ContextMenuPlugin
I wrote it a long time ago, but I still maintain it.
I will add EasyShell plugin for Eclipse, it has that functionality and more.
Have a look at that:
https://anb0s.github.io/EasyShell/
Aptana, it will give you context menu.
I am writing an Explorer extension for Vista and Windows 7. I read that if you are making a namespace extension you can provide your own commands using IExplorerCommandProvider. This is done in response to IShellFolder::CreateViewObject.
I am not writing a namespace extension, but a toolbar that lets you perform operations in Explorer. So I need to get IExplorerCommandProvider from an existing IShellFolder.
I get IShellView from the IShellBrowser, then I convert it to IFolderView, then I get IShellFolder. So far so good. I get a valid folder pointer.
This however doesn't work:
pShellFolder->CreateViewObject(NULL,IID_IExplorerCommandProvider,&p); // returns E_NOINTERFACE
I tried passing different values for the hwnd parameter of CreateViewObject, starting with the file pane and going all the way up to the top level Explorer window, and none of them worked.
So my questions are:
1) Do regular file system folders even support IExplorerCommandProvider?
2) If they do, how do I get my hands on that interface?
Thanks
Ivo
I use SHBrowseForFolder in my code. It works well in XP. But I find it dose not run well in Windows 7 with the same code. When I click a network, it does nothing. But it can expand in XP. By the way, I have the permission to access the network of another computer and I try accessing the resource with explorer, it's OK!
Can anyone tell me how to fix this problem?
Not sure it is the help you wanted, but I found this on the function's MSDN page:
For Windows Vista or later, it is
recommended that you use IFileDialog
with the FOS_PICKFOLDERS option rather
than the SHBrowseForFolder function.
This uses the Open Files dialog in
pick folders mode and is the preferred
implementation.
It should be:
BROWSEINFO bi;
// ..... omit oters
bi.ulFlags = /*BIF_DONTGOBELOWDOMAIN |*/ BIF_RETURNONLYFSDIRS | BIF_NEWDIALOGSTYLE;
I add one more flag BIF_BROWSEFORCOMPUTER to the ulFlags
There is a mixup here of the FileDialog APIs of COMMDLG and the IFileDlg interface, the latter existing in Vista and Win2008 Server only.
I have created a Windows Shell Extension using ATL (Visual Studio 2008). It has the following modules and each module is a separate ATL Simple Object with its own .rgs file for registration:-
IShellFolder/IShellView -> For a virtual drive in windows explorer
IContextMenu/IShellExtInit -> For a popup menu files and folders
IShellIconOverlayIdentifier - To display overlay icons on files and folders
IShellPropSheetExt/IShellExtInit -> For a custom property page in File & Folder's properties
The above work fine in WinXP and I am able to debug this shell extension in WinXP. But a soon as I switch to Vista, I only get method calls for (2) and (4). The drive gets created in Windows Explorer but the underlying methods are not called when I click it.
Although when I right click I get called for (2) and when I select "Properties" for a file or folder I get into the code for (4).
Is there some interface that I am missing for (1) and (3) on Vista. I could not find full and detailed documentation on writing Shell Extensions for Vista on MSDN. I had already gone through the CodeProject articles on shell extensions.
The problem was because of a Xml SMART Pointer usage. It was has problems when Release() was called on it.
Check this link
Internet Explorer crashes when MSXML2::IXMLDOMDocumentPtr -> Release() is called
Make sure that your extensions are handling the initialization properly, otherwise the verclsid.exe won't let your extension getting loaded.
verclsid.exe first loads the shell extensions and does a quick check on them before it sends an 'ok' to the shell indicating that it's safe to load the extension.
See here for some details about verclsid.exe.