I need to run a selfmade context menu entry via cmd.
The command is stored in
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\testCommand\command"
and contains
C:\Path\convert.exe %1 test1|test2
The problem is that windows seems to call the program associated with the command differently the first time. I don't know why and I can't get figured out how to avoid this.
So I want to call the program myself the first time before the user can call it.
If I execute the program myself directly via cmd it runs correctly, but if Windows executes it using the context menu entry it behaves different. After the first time it runs as supposed.
It couldn't find anything simmilar using google and stackoverflow ..
Whats the matter here? Also tried to run it using
RunDll32.EXE URL.DLL,FileProtocolHandler "C:\path\convert.exe"
But couldn't add the parameters requiered ..
Please help me ..
Related
Last year I thought I would give Dart a try, so I downloaded the Dart + Editor zip from the dartlang.org website and got it working on my Ubuntu 12.04 environment. When trying to get the Sunflower demo to run (by clicking the Run button), I got the "Unable to run current selection - please select a runnable resource" error. After exploring Google for answers, I found nothing, so I gave up on Dart at the time, not wanting to spend the time on something that is still buggy. Since then I prepared a completely new Ubuntu 14.04 environment on a new computer and thought I would give Dart another try. So I downloaded and installed it again this year and I am experiencing the exact same problem, still with no answers from Google searches. If this were a bug, I figured something like this would have been resolved after a year, or at least some discussion somewhere on Google about it. Am I doing something consistently wrong?
I extracted the dart zip into /opt/dart
I installed openjdk-7-jre
I executed DartEditor and it runs
I select the Sunflower demo
I click the green Run button
I get the following error: "Unable to run current selection - please select a runnable resource"
Any ideas?
Try the context menu on the entry page file (index.html or sunflower.html) in the web sub-directory and choose Run in Dartium
There is no unique or default entry point in a Dart package and no way to configure one.
You always have to run a specific Dart script file or HTML page that contains a ` tag.
I almost never used the run Button in the toolbar.
When you have for example the menu Run/Always run last launch activated and run an entry point like described above the toolbar run button should work to run the same entry point again.
I guess there are other ways to make this run button work but as I said, I almost never use this one myself.
Context menu Run in Dartium, Run as Javascript for web applications and context menu Run for command line scripts worked always for me.
Thanks for reading. :)
Let's give an example of what I say. I press shift+g and I execute one function. In the middle of executing it, I want to stop it by pressing shift+h, then execute another function, and then return the script so as it to stay waiting for another keystroke.
I thought about reloading the program, but I couldn't execute the following commands that way. Or, I could execute another program and reload the first one, but it is getting too complicated.
Any ideas will be greatly appreciated! :)
The easiest way is to put the script in a separate file and run it as an external program. Use #SingleInstance Force to be sure only one copy is running, and if you want to kill it use Process, Close with the PID you can get back from the Run statement.
I do this all the time with long complicated scripts that fail frequently. I mostly do that so if the script fails I just hit the hotkey again to restart. It kills the first instance and restarts. Interrupting a running script is just another special case.
Note that you'll need to run AutoHotkey.exe and pass the name of the script and any parameters. Don't try to run the script itself.
As pointed out the easiest way is to put the script in a separate file and run it as an external program. something like this:
RunWait %A_AhkPath% test1.ahk
Then in test1.apk put ExitApp in a hotkey. like this:
+t::
msgbox killing myself!
Exitapp
very simple!
I am creating a batch file that needs to open a second batch script in a separate cmd window. I can use all my code successfully if I use the "call" command instead of "start" but that doesn't launch the script in its own window. I have gotten this error many times in the past and its always related to the start command. I change how I do the process and all works well. Why is the start command causing this error and how can I fix it? Below is a sample of my code.
start "" /w "k:\Bundle Support files\record serial.cmd"
The second batch file opens and completes all tasks except the last one which is
goto :exit
:exit
I have changed the last command in the file several times and it always makes it through the entire batch but the last command that would finish that batch fails with the "not enough storage is available to process this command" error. This happens on multiple machines (varying hardware) and multiple OS's. I have attempted the IRPStackSize fix with no luck. Any suggestions as to why I am getting this error?
Thanks,
Kevin
I have encountered a similar problem and the solution for me was rather strange. It appears that setting the title of the window to nothing ("") causes the error.
So, instead of
start "" /w "k:\Bundle Support files\record serial.cmd"
try
start "Placeholder Name" /w "k:\Bundle Support files\record serial.cmd"
I can't test whether this will work in your case (and I doubt it matters as you're long gone) but hopefully this will help someone experiencing any similar errors.
Replace goto :exit with goto :EOF. Do not define the EOF label (it is predefined).
That's what the START command does when you launch a cmd. If you ran START cmd you wouldn't expect CMD to exit immediately - it stays there ready for use. So you either CALL a cmd file and it will finish, or you START a cmd, and it will not finish - but you can make it finish by using the EXIT command. The issue of the stack overflow was also answered correctly by SEIPIA - instead of using start "" filename.cmd, put something between the quotes to act as the title - that will prevent the stack overflow error.
I'm very new to IDL (trying to do a POC for someone using it) and I am trying to run an external command. The line of code I have added is this:
spawn, 'C:\Program Files\ITT\IDL\IDL80\products\envi48\save_add\visual.exe'
I thought this was all that was needed to launch an external command. When I run the app, i can use the debugger to step through the code, and when I get to this line and Step over, my executable does not run. I see no messages in the debugger indicating any type of error.
I put the file visual.exe in the directory and can run it by hand with no issues. It just seems to step right over the code without executing it or reporting any error.
You can use the form:
spawn, cmd, result, errResult
to get the any error messages that might be generated from the cmd. In your particular case, I think you need to quote the path to the executable because of the space in the path.
Your usage of the spawn command is correct. Perhaps visual.exe is exiting prematurely
for some reason (for example, maybe the working directory when run via spawn isn't what
your external program is expecting.)
You might try writing a little script that starts visual.exe, then does a pause,
and then spawn the wrapper script instead of visual.exe directly. That might
give you a chance to see any error messages before the DOS window disappears.
This question already has answers here:
Can one executable be both a console and GUI application?
(9 answers)
Closed 6 years ago.
Is it possible to (and if so, how do I) make a single program work both as a console application and a GUI version using Delphi 2007?
What I am after is that if the program is run with the appropriate command-line options, it should function as a console program, printing output to the console using WRITELN, but if no command line arguments are given it should run as a normal Delphi GUI application?
The catch is that when running as a console application, the command line interpreter waits for the application to terminate before allowing you to enter a new command, whereas a GUI application started from the command line immediately returns you to the command line and the GUI application is started in a detached process. I want this behaviour retained.
I don't mind something like this:
IF GUI THEN StartApplicationAsGUI(ParamStr(0))
ie. I don't mind that I'll have to restart the application using some form of EXECUTE call to start it in GUI mode if needed, as long as the command line interface returns to the command line input when the GUI version is started.
I'd prefer a solution/suggestion that is along the lines of:
<Parse Comnand Line>
IF ConsoleMode THEN
RunConsole(Parameters)
ELSE BEGIN
Application.Initialize;
Application.CreateForm(...)
Application.Run;
END
(or vice-versa, ie. doing things a special way if GUI mode)
so that I can still use Delphi's IDE and VCL when making the GUI interface...
On Windows this is a little bit tricky. Actually the distinction between a console application and a GUI one is a single flag in the PE header. You can easily write console applications that create windows but that way you always have the console window around (you could hide it, though, but that wouldn't be nice when people run your program from cmd).
You can, however write a GUI application that creates a console if it needs to, using the AllocConsole function:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
If the calling process creates a child process, the child inherits the new console.
AllocConsole initializes standard input, standard output, and standard error handles for the new console. The standard input handle is a handle to the console's input buffer, and the standard output and standard error handles are handles to the console's screen buffer. To retrieve these handles, use the GetStdHandle function.
This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).
However, when run from cmd this will likely cause another console window to appear instead of re-using the existing one. I don't know whether a good solution exists there.
IMO, the best approach here is to have non-visual classes that actually do the work of the program. Then you can call that from a GUI program, and you can also call it from a separate command line program. Both programs are just wrappers around the functionality of your class(es).
This forces the design to be clean too - your classes necessarily are separated from the GUI layer of your application.
http://blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx
Windows has different values in executable's header for console and UI application (see more details here). So it seems to be impossible to make the same executable to work in both modes.
As an alternative, you can open a console in you UI app, but it will be new console, not the one you've started app from.
AttachConsole() may be used to get a hold of the parents console.
E.g. if the application is started from a cmdline shell, AllocConsole() can be avoided:
if not AttachConsole(ATTACH_PARENT_PROCESS)
then AllocConsole;
More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx