如何防止对话框伪造死亡? [英] How to prevent the dialog fake dead?

问题描述

我创建一个对话框项目，其中有一个耗时的功能.
当我运行该函数时，该程序将伪造死亡.
我需要帮助！

I create a dialog project,there a time-consuming function in it.
when I runing the function ,the program will fake dead.
I need help!

推荐答案

在这种情况下始终使用线程.抱歉，您没有更多的信息，仅仅是因为您的问题不够详细，而是您最好首先以多线程的方式重新编写代码，全部由您自己完成，并在遇到任何问题时提出问题-我们将竭诚为您提供帮助.

-SA

Always use threading in such cases. Sorry, you got no more information just because your question is not detailed enough, but you better start re-writing your code as multithreaded first, all by yourself and ask a question when you face any problems — we will gladly try to help.

—SA

您可能会发现此讨论很有用， ^ ]，它涉及长时间运行的代码并保持GUI响应.阅读整个主题，讨论该方法的一些起伏.

如果您不熟悉编程窗口，那么最好学习线程以及如何使用线程来处理GUI事件/消息之外的内容.

但是，如果您只是想寻找一种快速方法来修复此程序的任何内容并继续进行下去(例如完成作业)，那么消息泵就可以解决问题.

--------

已更新，包括了我第一次忘记的链接

--------

再次更新.

好吧，我的直觉告诉我不要理会这个问题.关于我的解决方案/建议的评论只是证实了我的直觉是什么.

线程与消息泵是一场宗教战争.没有赢家.有些人发誓，线程是唯一的选择，而使GUI保持响应的所有其他形式都是不当行为，并且应以最严厉的方式予以惩罚.线程奉献者似乎愿意立即让大多数新手程序员学习线程，同步，跨线程通信等知识.对于大多数初学者来说，线程是一个复杂的概念，在学习线程之前，应该将海腿牢牢固定在适当的位置.线程要求某个学科有效地使用并且不会被弄乱，并且该学科会随着时间的流逝而逐渐发展，而不是在Comp Sci 1中.
现在，在我因不喜欢线程而被钉在十字架上之前，我要说的是，在发明线程时就已经存在了，我是包含线程的基于嵌入式芯片内核的一组产品的架构师.我是我公司在Posix Threading委员会上的代表，并负责Posix Threads的参考实现.我知道穿线很好.

线程化非常有用，值得学习，但并不是所有问题的解决方案.消息泵对于执行明显操作的人员很有用，当在其GUI中单击执行"按钮时就开始处理，而他们所要做的就是随着处理的进行使屏幕/日志窗口保持最新状态.如果您只想在处理过程中处理取消"按钮，它甚至可以正常工作.是的，您可能会遇到麻烦，但是我可以证明，如果您使用执行此操作"按钮来触发线程来执行工作，那么这些问题同样会存在.

早在80年代，当我完成所有内核工作时，我们就嘲笑某些人尝试创建尽可能多的线程的说法，古老的说法是如果线程对您有好处，则有4,000个线程一定很棒".所以是的，您可能会滥用线程，而我注意到的一种方法是使用线程来完成工作，然后也触发线程中的多个消息泵. Microsoft/MFC已经在默认的GUI线程中为您提供了一个消息泵，因此，除非您确实需要大量的线程来进行计算，否则就没有理由向该应用程序添加更多内容了.所以，阿尔伯特，我完全不同意你的看法.消息泵，如果要使用它，则不能在其自己的线程中使用，而应在GUI线程中运行时间较长的代码中使用，因为您已经抢占了MFC提供的代码.
好的，我要停止了，正如我所说，在宗教战争中没有胜利者.对此赞不绝口，无论如何，我再也不想再来一次了.

You may find this discussion useful, Re-SetTimer.aspx[^], it concerns long running code and keeping the GUI responsive. Read the entire thread as it discusses several ups and downs to the approach.

If you are new to programming windows, it would be good to learn threads and how to use them to process things outside of the GUI events / messages.

But if you are just looking for a quick way to fix whatever this program is and move on (like if it''s homework), a message pump will do the trick.

--------

Updated to include the link I forgot the first time

--------

Updated again.

OK, my gut told me to not bother with this question at all. The comments on my solution / suggestion just confirm what my gut thought in the first place.

Threads vs Message Pumps are a religious war. There is no winner. There are people who swear that Threads are the only way to go and that all other forms of keeping the GUI responsive are bad practice and punishable in the most harsh way. Thread devotees seem willing to force the most novice programmer into learning about threading, synchronization, cross thread communication, etc right out of the box. Threads are a complex concept for most beginners and they should have their sea legs firmly in place before learning threads. Threads require a discipline to use effectively and not get screwed up and that discipline is picked up over time, not in Comp Sci 1.

Now, before I get crucified for not liking threads, let me say that I was around when threading got invented, I was the architect for a set of products for an embedded chip based kernel that included threading. I was my company''s representative on the Posix Threading Committee and worked on the reference implementation for Posix Threads. I know threading well.

Threading is very useful and worth learning but it is not the solution to every problem. Message Pumps can be useful for folks who do the obvious, start processing when the "do it" button is clicked in their GUI and all they want to do is keep the screen / log window up to date as process proceeds. It even works fine if all you want to do is process a "Cancel" button during processing. Yes, you can get yourself into trouble but I can demonstrate those same problems will exist if you used the "do it" button to fire off a thread to do the work.

Back in the 80''s when I was doing all that kernel work, we used to laugh at some folk''s attempts to create as many threads as they could, the old saying was "if threads are good for you, 4,000 threads must be wonderful". So yes, you can misuse threads and one way I noted was to use threads to do the work and then also fire off multiple Message Pumps in threads too. Microsoft / MFC already gives you a Message Pump in the default GUI thread so unless it is *exactly that thread* that you have made compute intensive, there is no reason to add more to the application. And so, Albert, I completely disagree with you. The Message Pump, if you are going to use one, CANNOT be in it''s own thread but be used inside the long running code in the GUI thread because you have pre-empted the one provided by MFC.

OK, I''m going to stop with this, as I said, there is no winner in a religious war. Upvote this, downvote this, whatever, I''m no going to bother revisiting this ever again.

这篇关于如何防止对话框伪造死亡?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！