How can I get my app to run from the Start menu? - c#

If you type "regedit" in the Start menu's edit box and mash the Enter key, Registry Editor will be invoked. The same is true for "cmd" and the Command Line, and doubtless several other apps.
How can I get my app to respond the same way, so that if the user enters "Platypus" in the Start menu edit box, Platypus.exe will be invoked?
Does it require manipulation of the Registry / adding an entry somewhere there, and if so, just what key and value needs to be added?
I would be satisfied with the user needing to run the app manually once (2-clicking its icon; it's a Winforms app), at which time startup code (no pun intended) would do whatever was necessary to make the app henceforth Startsmartable (Windows key, "Platypus", to start the app).
I know that it's just as easy/easier for the user to simply 2-click a desktop icon when they want to run the app, but this particular functionality is not my idea, so complaints about the oddity of this question would be to no avail.
UPDATE
I added the code recommended by Chandan (with my executable's name):
public static void AddToStartup()
{
using (RegistryKey startup = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true))
{
startup.SetValue("RoboReporter", "\"" + System.Windows.Forms.Application.ExecutablePath + "\"");
}
}
...called it from the main form's load event:
private void FormRoboReporter_Load(object sender, EventArgs e)
{
RoboReporterConstsAndUtils.AddToStartup();
}
...shut down the app, went to the Start menu and entered the program's name ("RoboReporter"), and all it did was bring up search results of related file names.
UPDATE 2
What it does do is cause my app to run whenever the computer is restarted. That's not what I want. The code above adds an entry to HKEY_CURRENT_USER.Software.Microsoft.Windows.CurrentVersion.Run as can be seen here (along with a couple of other entries that predated it):
I don't want the app to start up every time the computer restarts, so I removed the entry. The question remains: how can I make the app runnable from the Start menu?

You can add your application's parent directory's path to the environment variable called PATH.
string pathvar = Environment.GetEnvironmentVariable("PATH", EnvironmentVariableTarget.Machine);
Environment.SetEnvironmentVariable("PATH", pathvar + ";" + Application.StartupPath + "\\", EnvironmentVariableTarget.Machine);
(Note that the paths added to this variable should end with a backslash \, and each path is separated by a semicolon ;)
Adding the parent directory's path to the environment variable will make all it's contents quickly accessible from the Start Menu's search field, from Run and from CMD.
You can also change EnvironmentVariableTarget.Machine to EnvironmentVariableTarget.User to modify the variable for the current user only.
EDIT:
A note: Setting a variable for the entire machine (by using EnvironmentVariableTarget.Machine) seems to require elevated privileges when done from one's application.

you might want to run this
public static void AddToStartup()
{
using (RegistryKey startup = Registry.CurrentUser.OpenSubKey("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run", true))
{
startup.SetValue("Name_of_your_Program", "\"" + Application.ExecutablePath + "\"");
}
}

Related

C# Winform Registry set and get functions appear to work, but don't actually change the registry

I'm trying to use this registry hack I found online:
;Disables F1 key - Help and Support - in Windows 10
;Ramesh Srinivasan, Winhelponline.com
[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32]
#=""
[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64]
#=""
When I run it as a .reg command via Windows Explorer and watch the registry with regedit, it works as intended. Removing it is another registry file that simply removes the \0 subkey (and win32 and 64 with it). I'm trying to emulate this function with C# in a Winform using .net CORE:
private void CheckF1()
{
// Registry data from ;Ramesh Srinivasan, Winhelponline.com
RegistryKey F1key = Registry.CurrentUser.OpenSubKey(#"SOFTWARE\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
// EGADS! It's active!
if (F1key == null)
{
fckF1RestoreBtn.Enabled = false;
fckF1KillBtn.Enabled = true;
fckF1Status.Text = "That creepy bugger is waiting and watching.";
}
else
{
fckF1RestoreBtn.Enabled = true;
fckF1KillBtn.Enabled = false;
fckF1Status.Text = "The F1-Help function had been put in it's place.";
}
}
private void fckF1KillBtn_Click(object sender, EventArgs e)
{
Registry.CurrentUser.CreateSubKey(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32");
Registry.CurrentUser.CreateSubKey(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64");
CheckF1();
}
private void fckF1RestoreBtn_Click(object sender, EventArgs e)
{
Registry.CurrentUser.DeleteSubKeyTree(#"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
CheckF1();
}
Weirdly the code "sees" a setting and responds like it should. Even to the point that whichever toggle position it was in on close it remembers when I load the file again. It's almost like it's playing along to screw with me. Regardless, when I watch the registry, none of my code has any actual effect though by all appearances it seems to work otherwise (it doesn't actually of course because the registry change isn't happening).
NOTE: I have already updated my manifest file for the project to include elevated permissions:
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
Here's the breakpoint on the test statement to see if the subkeys are there that shows they are:
Meanwhile the registry location for the exact path shown in the debug doesn't have the 1.0\0 path at all:
I don't know how the code is reading phantom values. Someone closed my previous question pointing to another answer that didn't have any effect (Registry key deleted but still getting value from registry c#):
"Prefer 32 bit" was never checked for my project in the first place
Modifying my code as recommended had no effect
var key = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64)
.OpenSubKey(#"SOFTWARE\WOW6432Node\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
Adding "Wow64Node" to the path makes no difference in execution.
EXPECTED BEHAVIOR
Checking to see if the HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0 path is present should return null if the \0 path is not present
Adding and removing the subkeys should show in the registry
So apparently HKEY_CURRENT_USERS is an alias. When the above code runs, it updates in HKEY_USERS under the specific logged in user. There's a question that talks about this behavior here: write registry to hkey_current_user instead of hkey_users
That said, the code appears to work, it's just that the registry doesn't update HKCU like when you run .reg commands. To verify it was working, I'd run the toggle that kills the keys then click them in Regedit and it would say they didn't exist. When I toggled back, I could click on them. So basically, it works (not sure if it required the "using" blocks as others suggested, but I see no reason to take them out).
Now my problem is that it points to the admin user and NOT the regular user because I'm running it and regedit as admin. It took forever to determine this based on running regedit as user in one case and admin in another. Bottom line, this won't work and I'll probably end up running .reg files in the command line instead.

Directory right click

I'm designing a C# WinForms program that when the user right clicks on a directory and selects the item which I added to shell context menu (which opens the .exe for my application), it runs in the background based on where the user right clicks.
I've already figured out how to install it and add it to the correct context menu, but I can't seem to figure out the most crucial part of the program. I've already looked here, but that doesn't answer my question and the answer it gives just leads to another question.
I also realize that command line arguments exist, and that is how this question is answered. When I go onto Microsoft's website about using command line arguments, it is only about using an actual command line, which I am not using.
So my question is:
How exactly do I get the directory path when a user right clicks a folder and choose the shell context menu which I added?
If I have to use a command line in the background, that is fine I just need to be able to get and send the directory path to my program.
Here is relevant code for how I use the entered directory. In essence source is the directory path that I want when the user right clicks.
private void recursiveCheck(string source)
{
string[] directories = Directory.GetDirectories(source);
foreach(string directory in directories)
{
string test = new DirectoryInfo(directory).Name;
if (test.Length >= 3 && (test.Substring(test.Length - 3).Equals("val", StringComparison.InvariantCultureIgnoreCase) || (test.Substring(test.Length - 3).Equals("ash", StringComparison.InvariantCultureIgnoreCase)))
{
if (Directory.Exists(directory + "\\STARTUP"))
testing_dir(directory);
else
{
MessageBox.Show("Error! Startup folder does not exist in: " + test);
Application.Exit();
}
}
else
recursiveCheck(directory);
}
}
I assume you have added your application to the context menu of folders in registry:
HKEY_CLASSES_ROOT
Directory
shell
OpenWithMyApp → (Default): Open With My App
command → (Default): "c:\myapp.exe" "%V"
The key point is in %V. It will be the folder name which you right clicked on it and it will be passed to your application as command line argument.
Then in your application, it's enough to have something like this:
[STAThread]
static void Main()
{
string folderName = null ;
if (Environment.GetCommandLineArgs().Length > 1)
folderName = Environment.GetCommandLineArgs()[1];
MessageBox.Show(folderName);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(true);
Application.Run(new Form1());
}

application won't start on startup after adding a notifyicon

my app was working ok and it would execute on startup before.
I added a notify icon and in my code,there are some places that this icon changes.I added all required icons in the root folder of my app,and everything is working fine with the icons,except the startup boot of my app.
I can see my app's address in the "run" part of the registry(I mean everything is the same as when my app booted at startup properly).but my app won't run at startup anymore.
any advice on my matter?
PS:I thought I should explain my work a little bit and I wrote a little piece of app that has the exact same problem
public Icon[] icons = new Icon[2] { new Icon("icon1.ico"), new Icon("icon2.ico") };
public int counter = 0;
private void button1_Click(object sender, EventArgs e)
{
notifyIcon1.Visible = true;
timer1.Start();
}
private void timer1_Tick(object sender, EventArgs e)
{
counter %= 2;
notifyIcon1.Icon = icons[counter];
counter++;
As you can see,the app changes the icon of the notifyicon in every tick.with this code,the app won't run at startup.but if I remove the iconchanging feature of the app,it will actually run at startup
This requires psychic debugging, I'll guess that you are loading these icons using their relative path name. Something like new Icon("foo.ico").
This can only work correctly if the default working directory of your program is set where you hope it will be. It usually is, certainly when you start your program from Visual Studio or start it from a desktop shortcut. But not when you added it to the Run registry key. Environment.CurrentDirectory will be set elsewhere, typically the Windows directory.
You must always use the full path name of files. An easy way to get that path is:
var home = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location);
var path = System.IO.Path.Combine(home, "foo.ico");
var icon = new Icon(path);
But there's certainly a better way than storing icons as files, you can embed them in your program. Project + Properties, Resources tab. Click the arrow on the Add Resource button, Add Existing File and navigate to your .ico file. Now the icon is embedded in your program, you'll never lose track of it and can't forget to copy it when you deploy your program on another machine. And the code is simpler as well:
var icon = Properties.Resources.foo;

How to get the (.lnk) shortcut filepath in a program which started by the shortcut?

I have a c# program which open *.postfix file.
If a user runs a (.lnk)shortcut which points to my type of file, my program will open the target.
So, how could my program know it is started by a (.lnk)shortcut (and get it's file path)?
In some circumstances,i need to replace the .lnk file.
Thanks!
Edited
First, thanks to guys who answered my question.
By following #Anders answer, i find out my problem lays here.
I made some changes to windows registry, so browser knows to throw customized protocol string to certain program.
some thing like this..
[InternetShortcut]
URL=myProtocol://abcdefg.....
That's maybe why i lost lpTitle. :(
I'm going to try this way:
Whenever my program invoked, of course fed with %1, program checks current opened explorer(Window), and try to get it's current path with IWebBrowserApp. With that path and desktop of course, scan and analyze *.lnk to determine which one to replace.
I think this will probably work, but not be sure. I will try.
continued
In native code you can call GetStartupInfo, if the STARTF_TITLEISLINKNAME bit is set in STARTUPINFO.dwFlags then the path to the .lnk is in STARTUPINFO.lpTitle. I don't know if there is a .NET way to get this info, you probably have to P/Invoke...
You don't. There's no way to do it. End of story.
So this has been brought to my attention due to a recent downvote. There's an accepted answer showing an idea that gets the path to the launching shortcut most of the time. However my answer is to the whole. OP wants the link to the shortcut so he can change it. That is what can't be done most of the time.
Most likely case is the shortcut file exists in the start menu but is unwritable. However other cases involve the shortcut coming from another launching application that didn't even read it from a disk but from a database (I've seen a lot of corporate level restricted application launch tools). I also have a program that launches programs from shortcuts not via IShellLink but by parsing the .lnk file (because it must not start COM for reasons) and launching the program contained. It doesn't pass STARTF_TITLEISLINKNAME because it's passing an actual title.
If you're using Visual Studio Setup Project to build an installer and do the file type association, you should follow these instructions http://www.dreamincode.net/forums/topic/58005-file-associations-in-visual-studio/
Open up your solution in Visual studio.
Add a Setup Project to your solution by file , add project,New project, Setup & Deployment projects,Setup project
Right-click on your setup project in the "Solution Explorer" window,Select view,then select file types.
you'll see the "file types" window displayed in Visual studio.At the top of the window will be "File types on target machine"
Right-click on "File types on target machine".the menu will pop up with Add "file type" Click on this.
you'll see "New document Type#1" added,and "&open"underneath it.
The "new document type#1" can be anything you want - change it to something descriptive.although the user never sees this,never use something common- be as unique as possible,Because you can overlay current file associations without even realizing it.For example,you might think"pngfile" might be a useful name- but using that will now send all"*.png" files to your application,instead of to an image viewer.A good practice maybe "YourCompantName.Filetype",where your company name is your name of your company's name, and "Filetype" is a descriptive text of your file.
In the "properties" window for your new type,you will need to change a few properties.:
Command:Change to the application that you want to run.If you click on the "..." and you will proberly want to locate and use the "primary Output..." File
Description: This is the description of the file type(if it doesn't describe it's self"
Extensions:This your list of extensions for you chosen Program.Separate each one with a ","
Icon:This will associate the icon with your file type,This shows up in the window explorer.
Now we move to that "&open ".This is an action that is available if your right-click on the file.The default action("&Open" is currently set as the default) is what happens when you double click on the file.Right click on your "New document type#1" to add actions,but for the moment,lets define our "&open" action
Click on "&Open".You will see in the properties window "Name","Arguments","Verbs". Verb is hidden from the user,but is the key that is stored in the registry.Leave it same as the name,But without the "&".The default for"Arguments" is "%1",Which means to pass the full path and filename to your application.You can add other stuff here as well,if you need to pass flags to your application to do special stuff.All this infomaton is getting passed to your application on the command line,so you'll need to be familiar with the "Environment.CommandLine" object.
If you need to set a different action as your default,just right click on the action and "set as default"
Basically, you'll pass the file path as an argument to your program. Then if it's a console application or Windows Forms , you should check the arguments in Program.Main
static void Main(string[] args)
{
//if file association done with Arguments %1 as per forum post above
//you file path should be in args[0]
string filePath = null;
if(args != null && args.Length > 0)
filePath = args[0];
}
For a WPF application you'll need to handle that in the StartUp event for your Application
void App_Startup(object sender, StartupEventArgs e)
{
string filePath = null;
if ((e.Args != null) && (e.Args.Length > 0))
{
filePath = e.Args[0];
}
}

changing the assembly title

I changed the assembly title of WPF-application from "Name1" to "Name2".
Files with extension ".sct" associate with this application.
I use RegistryKey. I associate file extension with application each time the application runs:
private void Window_Loaded(object sender, RoutedEventArgs e)
{
...
RegistryKey key = Registry.CurrentUser.OpenSubKey("Software\\Classes", true);
key.CreateSubKey("." + extension).SetValue(string.Empty, extension + "_auto_file");
key = key.CreateSubKey(extension + "_auto_file");
key.CreateSubKey("DefaultIcon").SetValue(string.Empty, icon);
key = key.CreateSubKey("Shell");
key.SetValue(string.Empty, "Open");
key = key.CreateSubKey("Open");
key.CreateSubKey("Command").SetValue("", "" + applicationExecutablePath + " %1");
...
}
Now when I install application in default directory and open .sct file properties I see old application name "Name1" instead of "Name2".
But if I install the application in another directory then application name in file properties changes to "Name2".
Why does it happen?
I changed the assembly title of WPF-application from "Name1" to "Name2".
That is an assembly TITLE? Name?
I use RegistryKey. I associate file extension with application each time the application runs:
Here we go, beginner mistakes and worst practices. Your prgoram may not have the rights for that. This should be done ONLY by an installer level, not by a user executing pgogram.
Now when I install application in default directory and open .sct file properties I see old
application name "Name1" instead of "Name2".
Also after a restart? See, the registry is likely cached and you dont run it from an installer. Ergo you see outdated values. Try restarting the compuer.

Categories

Resources