调试 Win32 应用程序 C++答案

【问题标题】：Debugging a Win32 application c++调试 Win32 应用程序 C++
【发布时间】：2021-07-28 23:01:12
【问题描述】：

我的应用程序最初是 VS2019 中的 c++ 控制台应用程序。代码作为 SDK 的一部分提供。工作完美。来自制造商 USB 设备的良好响应。后来，我想毕业的是一个GUI应用程序，就像我在VB和c#中所做的一样。瞧，我设法在 Qt 和 Win32 中重建了应用程序，但我遇到了应用程序变得无响应并且我无法知道发生了什么的情况。

在控制台应用程序中，我必须在发送“TakeMeasurement”命令后执行此代码以与设备交互：

        if (SDK_SUCCESSFUL(sdkError)) {
            printf("\nWaiting for measurement to complete...\n");
            while (!isMeasureWait) {
                if (isDisConnect) break;                        
                this_thread::sleep_for(chrono::milliseconds(1000));
            }
        }

这段代码就像一个魅力！经过一两次迭代，设备完成了测量，我可以轻松获取数据。

在 Win32 方面，我使用完全相同的代码。只是，一旦控制进入循环，它就永远不会返回。

知道如何诊断错误吗？我的印象是，从启动测量命令的确切时刻到仪器发出完成信号的确切时刻，以及准备好获取数据之间，“时间”是至关重要的。

我天真的假设是，在两个“平台”上的调试模式下，我一定会得到一些时间差异？遗憾的是，我无法从制造商那里获得更多这方面的信息，但我怀疑我有一小段时间可以对仪器的响应采取行动？我开始怀疑，在 Win32 上，那个“时间”太长了？与控制台端相比？

我在想，也许，“测量”那个时间，以毫秒为单位？首先，在控制台端，看看什么样的延迟“有效”，然后，看看延迟与 Win32 端相比如何。

我可能是在浪费我的时间，我当然不是想浪费你的时间。

我将如何了解 C++ 应用程序中经过的时间？我去看看VS2019，他们有各种在运行时弹出的“性能”东西？

感谢任何帮助。

【问题讨论】：

什么代码修改了布尔值？看起来你正在轮询，可能每轮等待 1s 太长了...
但是每回合中的 1 在控制台端“工作”没有问题？当从设备 DLL 调用 TakeMeasurement 命令时，设备应该执行它的工作并控制跳转到我在应用程序开始时初始化的设备处理程序。
FWIW 我测量了 TakeMeasurement 命令和数据返回之间经过的时间，即 1203 毫秒。
isMeasureWait 是如何声明的？
@RichardCritten isMeasureWait 在全局范围内声明为布尔值。仅在收到设备响应后，它才会在 DeviceHandler 函数中更改。

标签： c++ multithreading console win32-process

【解决方案1】：

我不确定我是否完全理解发生了什么。线程等待循环的执行不是罪魁祸首。我不是 100% 确定，但会发生什么，在我的“将数据导出到 CSV TEXT 文件”中，如果我尝试执行以下调用：

SetWindowText(hEditMeasure, wMeasurements);

应用程序总是挂起。我在代码中调用之前放置了断点，以跟踪执行情况，起初并没有让我印象深刻，但是在 VS 工具栏中，有一个“线程”组合框？显示的值 = DEVICE.DLL？在其右侧，我的导出函数的名称为 Stackframe。在搜索有关 setWindowText 函数的其他信息时，我遇到了使用 VM_SETTEXT 发送到“不同应用程序”的参考？会不会是我在不知不觉中向“另一个线程”，即 DLL 线程发送消息？这就是它挂起的原因？我知道的还不够多。所以我开始移动 setWindowText 行，最终在“Measure”按钮调用的代码中，它起作用了！

我还没有走出困境，但我觉得我正在取得进步。感谢大家的帮助和耐心。

【讨论】：