如何像启动调试模式一样在不调试的情况下启动项目？
我正在使用 C++ Managed 2010 在 form.h 文件中设计 GUI。 GUI 充当主卡，查询来自从卡的数据流。
按下按钮，调用一个函数（在 ApplicationIO.cpp 文件中），其中使用 API win32 (CREATETHREAD(...)) 创建 2 个线程：前者用于处理数据流，后者用于数据解析和处理GUI 上实时 grpah 的数据监控。
该项目有两种不同的行为：如果它在调试模式下启动，它能够在数据流期间将 GUI 控件更新为文本框（使用调用）和图形，相反，当它在没有调试的情况下启动时，文本框中不会出现数据，并且数据显示得非常好。慢慢地在图表上。
有没有人解决过类似的问题？请问有什么建议吗？
i'm using C++ managed 2010 for designing a GUI in a form.h file. The GUI acts as a master querying data streaming from slave card.
Pressing a button a function (in the ApplicationIO.cpp file) is called in which 2 threads are created by using API win32 (CREATETHREAD(...)): the former is for handling data streaming, and the latter is for data parsing and data monitoring on real time grpah on the GUI.
The project has two different behaviour: if it starts in debugging mode it is able to update GUI controls as textbox (using invoke) and graph during data straming, contrariwise when it starts without debugging no data appears in the textbox, and data are shown very slowly on the chart.
has anyone ever addressed a similar problem? Any suggestion, please?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个非常经典的错误是过于频繁地使用 Control::Begin/Invoke()。您将用委托调用请求淹没 UI 线程。 UI 更新往往很昂贵，您很容易陷入消息循环无法完成其低优先级职责的状态。就像绘画一样。这种情况很容易发生，每秒调用超过一千次是危险区域，具体取决于委托目标花费的时间。
您可以通过以实际速率发送更新来解决此问题，该速率利用了人眼区分更新的能力。每秒 25 次，更新变得模糊，更新得更快只是浪费 CPU 周期。这为 UI 线程留下了大量的时间来完成它需要做的事情。
当更新成本高昂时，这可能仍然不够慢。此时您需要跳过更新或限制工作线程。请注意，Invoke() 会自动限制，而 BeginInvoke() 则不会。
A pretty classic mistake is to use Control::Begin/Invoke() too often. You'll flood the UI thread with delegate invoke requests. UI updates tend to be expensive, you can easily get into a state where the message loop doesn't get around to doing its low-priority duties. Like painting. This happens easily, invoking more than a thousand times per second is the danger zone, depending on how much time is spent by the delegate targets.
You solve this by sending updates at a realistic rate, one that takes advantage of the ability of the human eye to distinguish them. At 25 times per second, the updates turn into a blur, updating it any faster is just a waste of cpu cycles. Which leaves lots of time for the UI thread to do what it needs to do.
This might still not be sufficiently slow when the updates are expensive. At which point you'll need to skip updates or throttle the worker thread. Note that Invoke() automatically throttles, BeginInvoke() doesn't.