Delphi:从 CMD 执行程序和内部过程/函数调用或使用双击关联的扩展

发布于 2024-08-01 13:03:46 字数 356 浏览 2 评论 0原文

所以 - 最近我遇到了一些问题,确定从哪种方式调用程序,如果两次参数相同 - 例如:/something /something。 我在运行时将图标与程序关联起来,我可以使用 cmd 来调用它,但是,每当我双击关联文件(带有图标)时,程序就会打开,但不会调用所需的 rotine,因为我没有必要的触发器/属性/参数如果执行是双击,而不是运行...> 应用程序名称.exe /某事/某事。

你能给出简单的例子或者理论上写出所有需要的函数等吗?

目前,正如你可以猜到的,我使用 ParamStr / ParamCount / blablabla / FindCMDLineSwitch / 和其他一些函数......但是......仍然......:(

So - recently I run on some problems determining from which way program was called, if in both times parameters is the same - like: /something /something.
I associate icon with program at runetime and i can use cmd to call it, but, whenever i doubleclikc on associated file ( with the icon ), progam simply opens, but does not calls needed rotine because i dont have necessary trigger / attribute / parameter that if execution was made doubleclick, not Run... > appname.exe /something /something.

Can you give simple example or write theoretically all with requiered functions etc.

Currently, as you can guess, I use ParamStr / ParamCount / blablabla / FindCMDLineSwitch / and some other functions ... but ... still ... :(

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撩动你心 2024-08-08 13:03:48

正如 Roddy 所建议的,我认为参数切换是唯一可靠的解决方案。 但请注意,如果用户创建自己的快捷方式,这可能不适合您的需求。

即,如果用户创建一个在命令行中包含某些“文档”的快捷方式,您是否希望将其视为命令行调用或“双击”。 我的猜测是后者。

如果是前者,那么您可以停止阅读此处。 :)

但如果它后者那么你可能需要投入更多的工作来(更)可靠地获得你想要的行为......

这将涉及使用命令行开关来指示命令行启动,而不是双击启动,因为有多种方法可以“有效”双击,但只有一种方法可以从命令行运行某些内容 - 即使用命令行! (顺便说一句,我认为“开始”菜单 ->“运行...”是命令行启动。ymmv)因此

,如果是我,我会为应用程序创建一个特定于命令行的启动器。 命令行启动器实际上是一段非常简单的代码,它接受给定的命令行并在调用实际的应用程序可执行文件之前简单地附加一个附加参数:

例如

myapp param1 param2

它只是调用 ShellExecute有效地:

myappgui param1 param2 /cmd

我自己不会太关心有两个可执行文件,因为用户不太关心实际的通过 GUI 调用它时代表“真实”应用程序的 exe 的名称,因为 GUI 调用当然不需要知道或需要知道该名称。 您的文件类型关联和快捷方式等都直接指向“真实的”myappgui.exe,而不是 myapp.exe

并且您的命令行引用只是将用户引导至使用 myapp.exe 从命令行调用您的应用程序。

在应用程序中,如果它找到命令行开关,那么它就知道它是通过命令行启动器应用程序启动的,否则它一定是双击/GUI 启动。

就大多数用户而言,他们可能永远不需要知道涉及两个 exe。 无论如何,您必须接受这样的事实:如果/当用户发现您的技术时(无论您选择哪种技术),他们都可以通过伪造命令行来欺骗它,以达到他们想要的任何目的。

如果这对您很重要,那么命令行启动器方法可能会降低他们发现该机制的可能性 - 知道有两个可执行文件是不够的 - 他们还需要知道您的命令行的命令行开关启动器添加 - 如果他们只是直接从命令行使用 myappgui.exe,而不使用命令行启动器 myapp.exe,那么它仍然会做出响应,就好像它一样是从 GUI 启动的!

另一方面,使用开关来指示 GUI 启动需要将所需的开关置于“公共视图”。

As Roddy suggests, a parameter switch is I think the only reliable solution. Note however that if a user creates their own shortcut(s) this may not suit your needs.

i.e. if the user creates a shortcut that includes some "document" in the command line, do you want that to be treated as a command line invocation or a "double click". My guess is it's the latter.

If it's the former then you can stop reading here. :)

But if it is the latter then you may need to put a little more work in to (more) reliably get the behaviour you want....

That would involve using a command line switch to indicate command line launch, rather than a double click launch, since there are multiple ways to "effectively" double click, but only one way to run something from the command line - that is, USE the command line! (I consider Start Menu -> Run... to be a command line launch, by the way. ymmv)

So, if it were me I would create a command line specific launcher for the application. The command line launcher would actually be a very simple bit of code that takes the command line it is given and simply appends an additional parameter, before calling the actual application executable:

e.g.

myapp param1 param2

which simply calls ShellExecute with effectively:

myappgui param1 param2 /cmd

I myself would not be too concerned with having two executables since the user is far less concerned with the actual name of the exe representing your "real" app when invoking it thru the GUI because of course the GUI invocations of that don't involve knowing, or needing to know, the name. Your file-type associations and shortcuts etc simply all point directly to the "real" myappgui.exe, rather than myapp.exe

And your command line reference simply directs the user to use myapp.exe to invoke your app from a command line.

In the application, if it finds the command line switch then it knows it was launched via the command line launcher application, otherwise it must have been a double-click/GUI launch.

As far as the majority of your users are concerned, they may never even need to know that there are two exe's involved. In any event, you have to accept that if/when a user discovers your technique - which ever you choose - they can spoof it by fabricating a command line to achieve whatever ends they desire.

If that's important to you, the command line launcher approach perhaps makes it a little less likely that they will discover the mechanism - knowing that there are two executables isn't enough - they would also need to know the command line switch that your command line launcher adds - if they just used myappgui.exe directly from the command line, without using the command line launcher myapp.exe, then it is still going to respond as if it were launched from the GUI!

On the other hand, using a switch to indicate a GUI launch necessitates putting that required switch on "public view".

ゃ懵逼小萝莉 2024-08-08 13:03:46

你能解释一下吗?

认为如果用户双击“mydocument.ext”的文档图标,您希望能够执行操作 #1,如果他键入

appname.exe mydocument.exe

双击将使 shell 运行“打开”, 则执行操作 #2动词,在注册表中有一个关联的“命令字符串”。 最好的办法是将此命令字符串设置为类似...

MyProgram.exe "%1" /doubleclicked

...的内容,然后在运行时检查 /doubleclicked 标志。 明显地,
您无法阻止用户使用“/doubleclicked”选项键入命令,但这就是 shell 的工作方式。

Can you explain a little?

I think you want to be able to do action #1 if user doubleclicks on a document icon for "mydocument.ext", and action #2 if he types

appname.exe mydocument.exe

Doubleclicking will make the shell run the "open" verb, which has an associated "command string" in the registry. Your best bet is to set this command string to something like...

MyProgram.exe "%1" /doubleclicked

... and then check for the /doubleclicked flag at runtime. Obviously,
there's no way that you can prevent the user typing the command with the "/doubleclicked" option, but that's the way the shell works.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文