Delphi 关于如何定义命令行参数的建议_Delphi_Paramstr

Delphi 关于如何定义命令行参数的建议

delphi

Delphi 关于如何定义命令行参数的建议,delphi,paramstr,Delphi,Paramstr,在我的Delphi应用程序中，我想添加命令行参数，以便在登录屏幕中自动设置一些参数目前，我有一个登录屏幕，用户在其中设置一些信息（如服务器、数据库、用户、密码、AuthenticationType、AUtoLogin等）我使用MRU填充字段。无论如何，在大型组织中，有必要不让用户选择任何信息。为此，在我的场景中，我能做的最简单的事情就是使用命令行参数我的问题是，您建议如何选择命令行参数？我的意思是，我应该选择“位置”方法还是“标记”方法，例如： MyProject.exe -s:MYSER

在我的Delphi应用程序中，我想添加命令行参数，以便在登录屏幕中自动设置一些参数

目前，我有一个登录屏幕，用户在其中设置一些信息（如服务器、数据库、用户、密码、AuthenticationType、AUtoLogin等）

我使用MRU填充字段。无论如何，在大型组织中，有必要不让用户选择任何信息。为此，在我的场景中，我能做的最简单的事情就是使用命令行参数

我的问题是，您建议如何选择命令行参数？我的意思是，我应该选择“位置”方法还是“标记”方法，例如：

MyProject.exe -s:MYSERVER -d:DATABASE

或

在第一种情况下，我需要使用

ParamStr

遍历所有参数并“解码”它们是什么。如果它们以“-s：”开头，我知道下面是服务器名。第二种方法更快、更脏，但可能更有效

如何管理包含“空格”的参数？是否可以使用ParamStr自动拦截它们，或者我是否应该手动处理所有这些？（我的意思是有没有一种方法可以自动告诉ParamStr一个参数包含一个空格（比如使用花括号之类的）

最佳做法是什么

我应该选择“定位”方法还是“标记”方法

毫无疑问，您应该标记命令行参数。位置方法不允许有足够的灵活性来省略参数。标记使用户更容易理解参数，特别是在返回到以前编写的代码时。标记应该是自文档化的

当您有一个文件名或一个文件名列表时，一种常见的情况是您会有未标记的参数

如何管理包含“空格”的参数

Windows惯例是通过在参数周围加双引号来转义空格。

ParamStr

解析将识别这些参数并相应地解析参数。

ParamStr（i）

中看到的是带引号的参数

RTL附带了一个有用的帮助函数来帮助您分析命令行参数：。

您的第一个问题只是一个品味问题。但是，我可以回答第二个问题。您可以使用双引号将包含空格的参数括起来。例如，如果

program Project1;

{$APPTYPE CONSOLE}

uses
  SysUtils;

var
  i: integer;

begin
  for i := 0 to ParamCount do
    WriteLn(ParamStr(i));
  Readln;
end.

并使用参数启动应用程序

1“2带空格”3“4带空格”

，然后获得输出

C:\Users\Andreas Rejbrand\Documents\RAD Studio\Projects\Project1.exe
one
two with spaces
three
four with spaces

我将参数（基于顺序）和选项（基于开关）分开

例如，请参阅“c:>帮助复制”。

Delphi包含一个非常好的名为CommandParser的单元，其中包含一个为您执行命令行解析的类。
既然如此，下面是一些需要开始的事情

我对我们的工作有兴趣

基本上你：

设置一个
```
t组件
```
，其中包含要作为命令行参数公开的属性（即
一个命令行解析器控制器。在我们的例子中（回想起来不是一个好名字）中的
```
thiddenexecutarguments
```
，它包含一个
```
InitCommandLine
```
方法，该方法设置一个TCommandParser实例，并将您的
```
TComponent
```
然后，它执行两个调用，用缩写和完整的命令行开关设置参数（如
```
h
```
和
```
help
```
）
然后可以在
```
TCommandParser
```
实例上调用
```
ProcessCommandLine
```
方法来处理命令行并填充
```
TComponent
```
的属性（在我的示例中，这是在
```
ProcessCommandLine
```
方法中完成的）

现在有趣的是：

```
TCommandParser
```
有一个
```
HelpText
```
方法，该方法根据您使用
```
AddSwitch
```
方法输入的内容，完全自动组合HelpText
```
TCommandParser
```
还有一个
```
SaveOptions
```
方法，允许您将TComponent的当前设置保存到设置文件中

您需要的Delphi单元是可以从Embarcadero演示库中获得的：

CommandParser in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\Utils\CommandParser.pas',
PropertyHelpers in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\DbxDataPump\PropertyHelpers.pas',
ParseIds in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\DbxDataPump\ParseIds.pas',

编辑：编写了一个包含空格的nice。

您使用双引号括起了一个包含空格的参数。我不知道为什么我尝试了所有组合，但没有使用双引号。谢谢。我注意到一件有趣的事情。如果我写：“-s:Server name”和-s:“Server name”ParamStr认为它们是相同的。这很好，因为编写“-s:Server Name”不像-s:“Server Name”那样方便用户。第一种方法对您和最终用户来说更方便。要“解码”params，您可以使用

TStringList

（在每行开头加上

符号）使用它的

Values

属性，将

NameValueSeparator

设置为

：

我认为如果参数是必需的，那么它应该是“位置的”。如果它是可选的，那么它应该是“标记的”.@Nat位置参数的缺点是，人类读者很难解析它们。当然，计算机很清楚这一点，但想想可怜的人类！位置参数也会使命令行的重构更具挑战性。谢谢。另请参阅我上面的评论。哇，感谢FindCmdLineSwitch。我总是手动编写所有这些代码。@user193655年，依我看，

FindCmdLineSwitch

是你的假朋友。它用简单的开关带来方便，但让成熟的CLI成为一个真正令人头痛的问题。考虑一下：

prog-x-r src dest

。还有你关于“更好”的问题语法没有什么意义。请询问您的高级用户，他们认为哪种CLI更方便。我同意这一点。为了能够处理此类参数，这是我在回答中描述的“常见场景”，您确实希望参数解析器使用开关/选项，并将剩下的参数留给您。

CommandParser in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\Utils\CommandParser.pas',
PropertyHelpers in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\DbxDataPump\PropertyHelpers.pas',
ParseIds in '...\radstudiodemos.sourceforge.net\branches\RadStudio_XE2\Delphi\Database\dbExpress\DbxDataPump\ParseIds.pas',