Configure Autohotkey to edit scripts with Notepad++ - autohotkey

I have my default editor for .ahk files set to Notepad++ Portable on my work laptop, but selecting Edit This Script opens files in the standard Windows Notepad.
A post on the AHK forums suggests editing the registry, but I don't see any entries under HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell\Edit\Command.
How can I configure AutoHotkey to edit scripts with Notepad++?

For whatever reason, the Registry entry doesn't exist by default, but it is recognized by the application once created.
Navigate to HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell in RegEdit.
Right-click the Shell folder, select New > Key and name this Edit.
Right-click the Edit folder, select New > Key and name this Command.
Double click the (Default) string entry in Command.
Paste in "C:\Program Files\Notepad++\Notepad++.exe" "%1" to this window.
Reload AutoHotkey for the changes to take effect.
Note: I don't use Notepad++, but this works for VS Code on my system, and will for N++ as long as the directory information for the executable is correct.
The corresponding .reg file looks like this:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell\Edit\Command]
#="\"C:\\Program Files\\Notepad++\\notepad++.exe\" \"%1\""

The registry entry in item 5 of the previous answer did not work. I don't even know what the extra %* at the end means, so I simplified it to:
"C:\Program Files\Notepad++\Notepad++.exe" "%1"

For AHK version 2, changing the registry didn't work for me (I tried both Computer\HKEY_CLASSES_ROOT\AutoHotkeyScript\Shell\Edit\Command and Computer\HKEY_CLASSES_ROOT\.ahk\Shell\Edit\Command), but this did it for me. It adds two menu items to the AHK tray menu after a divider:
EditWithNotepadPlusPlus(*)
{
Run "C:\Program Files\Notepad++\notepad++.exe " A_ScriptFullPath
}
EditWithVsCode(*)
{
Run "C:\Program Files\Microsoft VS Code\Code.exe " A_ScriptFullPath
}
A_TrayMenu.Add()
A_TrayMenu.Add("Edit with VS Code", EditWithVsCode)
A_TrayMenu.Add("Edit with Notepad++", EditWithNotepadPlusPlus)
return

If you are like me and you are hesitant to modify the registry, there is a way to do this using AutoHotKey code.
This is a method I use to edit the script with a different editor. Although I am using Visual Studio Code, the method is the same no matter which editor you want to use. One caveat though: we can't change the existing "Edit This Script" menu item, since that is considered one of the standard menu items and can't be modified. Instead I am adding a new menu item at the top of the menu that says "Edit With Notepad++".
EditWithNotepadPlusPlus()
{
Run "C:\Program Files (x86)\Notepad++\notepad++.exe" "%A_ScriptFullPath%"
}
; Remove the standard menu items temporarily
Menu, Tray, NoStandard
; Add our custom menu item labeled "Edit With Notepad++"
; and calls the function above
Menu, Tray, Add, Edit With Notepad++, EditWithNotepadPlusPlus
; Add a separator
Menu, Tray, Add
; Put the standard menu items back, under our custom menu item
Menu, Tray, Standard
Note: If you're wondering, the lines Menu, Tray, NoStandard and Menu, Tray, Standard are not required. The reason I use those lines is because by default, Menu, MenuName, Add adds menu items to the bottom of the menu. For aesthetic and practical reasons, I prefer Exit to be the last menu item. So Menu, Tray, NoStandard and Menu, Tray, Standard will cause our menu item to appear at the top.
One added benefit of this method is that if you transfer your scripts to a new computer, it should still work (provided you have Notepad++ installed on the other computer). If you edit the registry, you have to remember to edit the registry again.

Using AHK v1.1.3.02 on Win10 with string
"C:\Program Files\TextPad 8\TextPad.exe" "%1"
worked well.

The registry change mentioned in other answers for me worked, but you may want to further add the following flags:
C:\Program Files (x86)\Notepad++\notepad++.exe %1 -multiInst -nosession
These flags will stop Notepad++ from recognizing this window as part of your overall session, so it won't overwrite your normal session history or anything. I don't remember where I first found these solutions but I'm switching computers atm and found them in my registry and noticed they weren't mentioned anywhere in this thread.

Was not working for me, i fixed it by first using the suggestion by R River
C:\Program Files (x86)\Notepad++\notepad++.exe %1 -multiInst -nosession
But this would create a new session each time, so i tried removing the end parameters and it now works.
C:\Program Files (x86)\Notepad++\notepad++.exe %1

Simplest way I've found is to:
Right click the .ahk file
Select "Open with" -> "Choose another app"
Check "Always use this app to open .ahk files"
Then select NotePad++ from the list
If it's not listed select "More Apps" and scroll down to NotePad++. (Mind you this example is Windows 10 specific, but previous versions are very similar.)
Editing the registry is great, don't get me wrong, but it takes longer. It's kinda like using a truck to swat a fly! Anyways, hope this works for you. I use it all the time to set the file associations I want.

Related

Powershell -command text not appearing

Windows 10, Powershell -v 5.1
I have tried to restore powershell to defaults, both normally and as admin. I have changed/turned off high contrast settings, deleted console files for powershell in Regedit, as well as tried to restore defaults from command line scripts.
Have tried restarting after applying all of this, but much of my output text is invisible, as well as commands with only one "-" dash, but commands with "--" appear.
See in pics below
no - identifiers
Invisible "-i"
Reappearing "--i"
Invisible Surge Data
It sounds like you've persistently modified the console-window colors in a manner that renders certain syntactic elements invisible.
You can either modify your console-window settings interactively - which may be nontrivial - or you can try to restore the original colors by recreating
the shortcut files that start your console windows:
Shortcut files (*.lnk files) contain their own console-window settings, which are independent of the defaults defined for console windows in the [HKEY_CURRENT_USER\Console] registry key and its subkeys named for specific executable names / window titles.
Therefore, even if you remove [HKEY_CURRENT_USER\Console] or specific subkeys, starting a program via a shortcut file will still apply the settings stored inside that shortcut file.
To bypass the shortcut-file settings ad hoc, you can start your program directly, using the Run dialog:
Press WinKey+R and enter powershell (for Windows PowerShell) or pwsh (for PowerShell Core), which applies only the registry defaults, if any.
However, to solve that problem persistently, you must modify or recreate the shortcut
file(s) you use to start your program:
To modify the shortcut:
Invoke your program via the shortcut,
then open the system menu (click on the icon in the top-left corner of the window),
select Properties
and modify the properties, notably the colors via the Colors tab.
To recreate the shortcut (instructions based on Windows 10):
In the Start Menu:
Right-click on the application of interest, then select More > Open file location.
In the taskbar:
Right-click on the application of interest, then right-click the application name and select Properties.
Activate the General tab
Copy the value of the Location: field - the folder in which the *.lnk file is located - to the clipboard.
Open File Explorer and paste the location into its address bar, which should open the folder in which the *.lnk file of interest is located.
Once you've located the *.lnk file of interest:
Make a note of:
its exact filename (typically: Windows PowerShell)
its target command line, by right-clicking the file, selecting Properties, selecting the Shortcut tab and copying the value of the Target: field.
its startup directory, as noted in the Start in: field.
Delete the *.lnk file.
Recreate it with the previously noted target command line:
Right-click in an empty part of the File Explorer window and select New > Shortcut
Paste the command line and click Next.
Specify the previous filename, and click on Finish.
Right-click on the new file, select Properties, and paste the startup directory into field Start in:, then click OK.
Drag the new *.lnk file into the Start Menu and/or taskbar, as needed.

Execute Powershell from File Explorer after installing VS Code

VS Code is trying to position itself as a new way to work with Powershell, and one of the changes it makes upon installation is to replace the File Explorer context menu option "Run with PowerShell" on .ps1 files with a new "Open with Code" option instead.
Is there a way to remove the "Open with Code" option and replace it with the old "Run with PowerShell" option? I assume this would involve the registry somehow but I don't know enough about the registry in general to do it safely.
Try this:
Save the following contents into a file "EnablePowerShellRightClickRun.reg", then right click - merge.
Then it doesn't matter which application you associate .ps1 files with - you still have "Run with Powershell" as a right click option.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1]
[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\shell]
[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\shell\RunPS]
#="Run with Powershell"
[HKEY_CLASSES_ROOT\SystemFileAssociations\.ps1\shell\RunPS\command]
#="\"C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe\" -File \"%1\""
VS Code is not really positioning itself as the new way to work with PowerShell, it will be the only "built-in" way with Windows to work with it because the PowerShell ISE is being depreciated.
Either way, VS Code did not cause that option to disappear. I have VS Code and the PS extension on my machine and still have access to both options:
When you install VS Code you are prompted to add the right-click menu options, so if you opt'ed into those then it is not what removed your "Run with PowerShell" option.
If you want to remove those right-click options then you would have to uninstall VS Code and install it again, making sure those options are not checked.
To restore your menu option to Run with PowerShell verify you have not changed the default program for PowerShell files (e.g. ps1). If you set that to VS Code it will cause the option to be removed from your right-click menu. You can restore it by changing the default program in Windows back to Notepad.

Accidentally deleted the Git Shell shortcut

So where is it? I checked the usual suspects, namely Program Files and Program Files (x86), but I didn't see any mention of GitHub there.
I know someone offered an answer but deleted it for whatever reason before I could accept it, so here goes.
You need to create a shortcut to a command, which is actually rather convoluted.
Right-click on the desktop and do New > Shortcut
Browse to any file, but make sure it's not a .exe file!!
Click next through the rest of the wizard and accept the defaults
Now right-click the shortcut, go to Properties > Shortcut tab
Set the Target to: "C:\Documents and Settings\\AppData\Local\GitHub\GitHub.appref-ms" --open-shell
In step 5 above, the quotes are required.
A better solution is to run
%LOCALAPPDATA%\GitHub\GitHub.appref-ms --reinstall-shortcuts
which will recreate the shortcut on the desktop.

"Open containing folder" hotkey in Visual Studio 2012

In versions of Visual Studio before 2012, I was able to create a hotkey to perform "Open Containing Folder" for the current active text file. I accomplished this by creating a macro that had a keystroke assigned to it.
Visual Studio 2012 does not have macros. How would I accomplish the above in this version?
Unfortunately you'll now need to download the VSSDK and create a VSPackage to do that, now that macros have been dropped from the IDE.
The closest thing to a macro now is a PowerShell script, which you could run from the console but I'm not aware of any way to assign a keyboard shortcut to it.
Running PS outside of the IDE is an option (via an External Tool command with a keyboard shortcut configured), but obtaining the EnvDTE outside of process could be complicated.
EDIT: There is a much simpler solution. I can't believe I didn't realise it to begin with!
Simply go into Tools... Options... Environment... Keyboard locate File.OpenContainingFolder and assign a shortcut. This command will open the active document's containing folder.
I found a keyboard shortcut for Open Containing Folder: Alt + - + O
When you press Alt + - it opens Tab Context Menu Then you see that the shortcut key for Open Containing Folder is O key, then you should press O.

How to make Eclipse behave well in the Windows 7 taskbar?

All other apps that can be pinned to the taskbar behave well.
But Eclipse doesn't show recently open projects when I right click it.
It also doesn't allow to pin some projects inside it.
Note that I have the JS version of Eclipse Helios. Which spawns a new and different taskbar icon after loading.
Specify the latest available Java VM in your eclipse.ini. I.e.:
-vm
jdk1.6.0_10\jre\bin\client\jvm.dll
Make sure they are on separate lines
Anything after the "vmargs" is taken to be vm arguments
(More info)
Or alternatively add the java bin folder to your Windows PATH before the "windows32" folder, because otherwise eclipse uses "javaw.exe" in the win32 folder instead of the JDK one.
Riccardo's solution from the Eclipse bug report worked for me, but I don't get recently opened projects, etc. from the task bar. Is anyone experiencing that these workarounds restore that behavior?
I have the same problem on Windows 7 x64 with Helios x64, but for me
the following workaround works with the option "Always combine, hide
labels" for taskbar buttons.
Check your "eclipse.ini" for the specified VM and make sure the path points to the bin directory of your JDK or JRE (and not to javaw.exe).
For me the argument is "D:/Development/Languages/Java/Development
Kit/bin/" without quotes.
Unpin Eclipse from the taskbar or delete the shortcut
Run "eclipse.exe" from the explorer and choose your workspace
Pin Eclipse to the taskbar after the splash screen was loaded and when the main window is shown
setting eclipse.exe to compatibility mode works
I just want to add this for the Win10 users.
Edit eclipse.ini to add these lines at the end before the line --launcher.appendVmargs:
-vm
C:/Program Files/Java/jdk1.8.0/jre/bin/server/jvm.dll
You need set the compatibility to Windows Vista as well in order for it to work.
I think it's important to mention that at least for me it was important to add the path to the vm in the eclipse.ini with forward slashes, even though I'm working with Windows (7, that is). Eclipse didn't start when I used backslashes.
The solutions offered here on StackOverflow so far, don't have an easy fix for running multiple Eclipses while each having their own Application ID, and making grouping of icons work as expected. The answer here does provide a reference to the underlying System.AppUserModel.ID property.
Here's a quick HOWTO:
Do the -vm setting as plenty of people here have mentioned
Run the eclipse app
Right click on the running taskbar icon, Pin this program to taskbar
Navigate to %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\Taskbar
Copy the newly created shortcut to another location. It will be named eclipse, eclipse (2), or eclipse (3) and so on
Right click on the running taskbar icon, Unpin this program from taskbar
Use the Shortcut Properties dialog to copy all individual fields (target + parameters, workdir, icon, anything else) to the new shortcut
Rename the new shortcut
Drag the new shortcut to the Windows Taskbar
Done
Here's an extended HOWTO, helpful if you want icon grouping separated per individual Eclipse instance (if you have multiple instances running):
Find out what your startup plugin is, for example org.eclipse.epp.package.java_2.0.1.20130919-0803. Open the plugin.xml file of that folder.
Edit the following XML location in that file: /plugin/extension/product/property[#name="appName"], set attribute value to something else. Don't use spaces, keep length below (up until) 40.
Optionally also set the window title: /plugin/extension/product/property[#name], set attribute name to something else.
In your existing Eclipse shortcut, append -clean and run it once. You will notice the //product/property[#name] attribute being used in the Eclipse window title. Afterwards, you can remove -clean again.
Follow the quick HOWTO above
A quick explanation on What's going on here:
Inside the .lnk file, an attribute is stored, which can't be entered by using the windows Shortcut Property dialog. If you copy a .lnk file, the attribute will copy with it.
Windows groups by identical System.AppUserModel.ID property, AppID for short
Eclipse does not have an AppID at startup. First the JVM is started, then the eclipse core/platform is started, and then the startup plugin is loaded. In this last stage, an API call is done to set the AppID to the value inside a plugin.xml file. See above: extended HOWTO item 2
When you drag a manually created shortcut .lnk file to the taskbar, it makes sense that windows can't put this AppID into the new 'pinned' version of the .lnk file. It can only be detected at runtime.
When you start an Eclipse application, right click on the running taskbar icon, Pin this program to taskbar -> then Windows will detect the AppID and store it in the 'pinned' .lnk. But, partly because of the JVM process redirection, Windows does not detect the command-line parameters, environment, working folder (at startup at least), and the icon path + icon index. So you have to:
Do a file copy of the .lnk file and fill in the missing gaps yourself
Or, use a shortcut creation tool that understands System.AppUserModel.ID properties (there are plenty)
Or, use the Windows API directly
Sincerely hope this will reduce the amount of haywire Eclipse taskbars icons on the workstations around me,
Cheers, TW
Recently Timo Kinnunen has pinpointed the problem
Edit eclipse.ini find the line:
--launcher.appendVmargs:
and change it to
--launcher.appendVmargs:-vm <PATH_TO_JAVA>/jdk1.8.0/jre/bin/server/jvm.dll
This causes the JVM to be launched in the same process as eclipse.exe rather than as a child process and avoids the intricacies of Host Processes with AppUserModelIDs.
And it works !!!