通过DELPHI小程序在WINDOWS下更好地使用DOS批处理

Posted 2023-05-15

参考技术A

　　我们知道 DOS 下的批处理程序中 可以用 ECHO 显示一段信息（提示信息或出错信息） 对于要接收用户输入的情况 MS DOS 本身提供的外部程序就只有 CHOICE 能让用户输入一个键 所以基本上只能用于菜单选择 对于下述两个需求 那就只有另外编程序了 　　 ．在 DOS 下的批处理程序中通过 WINDOWS 对话框显示一段提示信息或出错信息 　　 ．在 DOS 下的批处理程序中通过 WINDOWS 对话框接收用户输入的一个字符串 并对其进行后续处理

　　对于这两个问题 相信有些人已经有了一些解决方案 在此我提出我的解决方案 是用 DELPHI 写的程序（这些DELPHI程序都是没有 FORM 和 PAS文件的） 我觉得比较简单 作为抛砖引玉

　　 显示提示信息 SHOWMSG DPR program ShowMsg; uses Windows; $R * RES begin   if ParamCount < then begin MessageBox( 用Windows对话框显示信息 # # + 用法: ShowMsg 提示信息 对话框标题 用法说明 MB_ICONINFORMATION); Halt; end; MessageBox( PChar(ParamStr( )) Pchar(ParamStr( )) MB_OK); Halt; end

　　 显示出错信息 EmsgDlg DPR program EmsgDlg; uses Windows; $R * RES begin if ParamCount < then begin MessageBox( 用Windows对话框显示出错信息 # # + 用法: EmsgDlg 出错信息 对话框标题 用法说明 MB_ICONINFORMATION); Halt; end; MessageBox( PChar(ParamStr( )) PChar(ParamStr( )) mb_IconHand); Halt; end

　　 INPUTBOX DPR　　通过 WINDOWS 对话框接收用户输入的一个字符串 并把用户输入作为调用一个批处理程序或其他程序的第 个参数 program INPUTBOX; uses Dialogs Windows; $R * RES var NewString: string; ClickedOK: Boolean; begin if ParamCount < then begin MessageBox( 将用户输入作为 BAT或其他程序的参数调用 # # + 用法: InputBox BAT或其他程序文件名 缺省输入 对话框标题 提示信息 InputBox用法说明 MB_ICONINFORMATION); Halt; end; NewString := ParamStr( ); //default string ClickedOK := InputQuery(ParamStr( ) ParamStr( ) NewString); if ClickedOK then WinExec(PChar(ParamStr( ) + + NewString) SW_SHOWNORMAL); Halt; end

用法举例 PRT BAT文件内容: @ECHO OFF D:\\POS\\INPUTBOX EXE PR BAT 解压POS报表文件并用写字板打开入帐汇总表 请输入日期:

PR BAT文件内容: @ECHO OFF IF % == GOTO END D: CD \\POS\\INBOX IF NOT EXIST POS% ARJ GOTO NOT_FOUND D:\\POS\\ARJ X y POS% ARJ CD D:\\POS\\INBOX\\pos_report IF NOT EXIST Pr B% txt GOTO PR _NOT_FOUND C:\\WINDOWS\\WRITE Pr B% txt D:\\POS\\ShowMsg 成功！ OK!!! GOTO END

:NOT_FOUND D:\\POS\\EmsgDlg 文件D:\\POS\\INBOX\\POS% ARJ找不到! 出错! CD D:\\ GOTO END

:PR _NOT_FOUND D:\\POS\\EmsgDlg 文件D:\\POS\\INBOX\\pos_report\\Pr B% txt找不到! 出错! CD D:\\ GOTO END

:END

lishixinzhi/Article/program/Delphi/201311/25043

windows下使用mingw/gdb无法调试eclipse helios cdt上的小程序，控制台死机

【中文标题】windows下使用mingw/gdb无法调试eclipse helios cdt上的小程序，控制台死机

【英文标题】：can't debug small program on eclipse helios cdt using mingw/gdb under windows, console freezes

【发布时间】：2011-08-25 15:58:39

【问题描述】：

我一直在尝试使用 Eclipse CDT 来做一些 c++ 示例，我可以使用 run 命令很好地运行它们，但是每当我尝试调试时，控制台窗口就会冻结，我可以输入，但是程序无法继续。

当我调试时，我在控制台窗口上得到以下输出（没有断点，但由于默认设置而在 main 上中断）：

Hello, world
put your name: 15^running

当我输入内容并点击 enter 时，继续按钮被禁用并且不执行任何操作。 15 是一个随机数，有时是 16、20 等。

如果我在 eclipse 下运行程序，我会得到输入提示就好了：

Hello, world
put your name: test
Hello test

这是我尝试调试的代码：

#include <iostream>
#include <string>

int main() 
    std::cout << "Hello, world" << std::endl;
    std::string name;
    std::cout << "put your name: ";
    std::cin >> name;
    std::cout << "Hello " + name << std::endl;
    return 0;

我的路径变量：C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\Program Files\Java\jdk1.6.0_14\bin;C:\MinGW\bin

Eclipse 版本：Helios Service Release 2 CDT版本：7.0.2 操作系统：windows xp GDB 版本：GNU gdb (GDB) 7.2

如何在 CDT 下调试这个小例子，没有问题？

【参考方案1】：

以下内容来自 Eclipse 网站的常见问题解答：

http://wiki.eclipse.org/CDT/User/FAQ#Eclipse_console_does_not_show_output_on_Windows

Eclipse 控制台在 Windows 上不显示输出 在 Eclipse CDT 上 Windows，正在运行或调试的程序的标准输出是完全 缓冲，因为它没有连接到 Windwos 控制台，而是连接到 管道。有关详细信息，请参阅错误 173732。在之后添加 fflush 调用 每个 printf 或在 main 开头添加以下行 功能：

setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);

似乎是 Windows 上的预期错误。

【参考方案2】：

15^running 看起来是来自 gdb 的 Machine Interface 的结果记录。通常它不应该出现在 Eclipse 控制台中。

我建议尝试不同的 Create Process Launcher。可以通过以下方式更改：

在主菜单中选择“运行”->“调试配置...”。

在如下所示打开的“调试配置”窗口中，单击“使用 GDB (DSF) 创建进程启动器”对面的“选择其他...”。

在如下所示打开的“选择首选启动器”窗口中选中“使用配置特定设置”，在下面的列表中选择“标准创建进程启动器”，然后单击确定。

现在转到“调试配置”窗口中的调试器选项卡，选择调试器，例如“MinGW gdb”并点击应用。

使用标准创建流程启动器，我能够调试您的程序，尽管“输入您的姓名：”仅在我输入内容并按 Enter 后才会打印，因为输出流未刷新。

【讨论】：

谢谢 - 这也是我在 linux 上遇到的问题，当我尝试使用 gdb + eclipse 调试 mozilla 时。

【参考方案3】：

试着看看这个http://www.cprogramming.com/gdbtutorial.html 看看是否有帮助。像你可以按CTRL-C打破吗？

虽然与苹果有关，但Cannot enter input with gdb. Help! 也可能是一个指针。

【讨论】：

我现在走得更远了，我认为这是 Windows 控制台没有弹出的问题。我现在正在看codelite，似乎在调试方面表现更好。