对话框-消息里嵌套消息会造成阻塞吗

问题描述

消息里嵌套消息会造成阻塞吗

对话框程序里,重写了OnClose函数,在OnClose里又触发了一个消息,(用的SendMessage),会因此造成消息阻塞吗?
现象是每次执行完CDialog::OnClose后就崩掉了

解决方案

SendMessage发给谁的?SendMessage要等待消息处理完返回。

解决方案二:

可以用异步来做。OnClose里又触发了一个消息,(用的SendMessage)这个用异步来做。这样两都就不相关了

解决方案三:

只要你的消息不是互相阻塞,导致消息死锁,那么就可以用SendMessage

如果只是为了通知,一般用PostMessage来异步发送,这样就不会阻塞当前消息处理函数,可以避免一些问题

时间: 2024-08-30 18:51:46

对话框-消息里嵌套消息会造成阻塞吗的相关文章

十分钟快速玩转 Aliware MQ-阿里云消息队列Demo工程实践

环境准备 本 Demo 主要目的在于帮助初次接触 Aliware MQ 的工程师,一步一步搭建 MQ 测试工程.Demo 程序以 Java 为例,包括普通消息.事务消息.定时消息的测试代码,以及相关 Spring 的配置示例. 安装 IDE 本文以 IDEA 为例.您可以使用 IDEA 或者 Eclipse. 在https://www.jetbrains.com/idea/ 下载 IDEA.请下载 Ultimate 版本. 执行 IDEA 安装包,安装 IDEA. 选择 License serv

深入探讨MFC消息循环和消息泵

首先,应该清楚MFC的消息循环(::GetMessage,::PeekMessage),消息泵(CWinThread::PumpMessage)和MFC的消息在窗口之间的路由是两件不同的事情.在MFC的应用程序中(应用程序类基于CWinThread继承),必须要有一个消息循环,他的作用是从应用程序的消息队列中读取消息,并把它派送出去(::DispatchMessage).而消息路由是指消息派送出去之后,系统(USER32.DLL)把消息投递到哪个窗口,以及以后消息在窗口之间的传递是怎样的.  消

《WCF技术内幕》28:第2部分_第5章_消息:使用消息头(中)

MessageHeaders类型 因为SOAP消息可能包含很多消息头块,所以在一个Message类型里,我们需要 一种表示一组消息头块对象的方法.MessageHeaders就是这个作用,并且它定义 了一个MessageHeaders 类型的只读属性Headers.Headers属性是我们在Message 里增加.修改.查询和移除MessageHeader的主要方式.在某种意义上,本节主 要是讲解MessageHeaders类型,以及可以应用到Message类型的Headers属性上的 所有信息

《WCF技术内幕》27:第2部分_第5章_消息:使用消息头(上)

使用消息头 正如你在第二章里看到的一样,消息头块被SOAP消息基础结构用来表示地址 .路由和安全信息.因为WCF也是一个完全支持SOAP的消息处理基础结构,它包 含一些创建.序列化和分析SOAP消息头块的工具.记住Message类型是一个 SOAP 消息的CLR抽象,它定义的成员允许WCF基础结构使用发送或接受到的消息头块. Message 类型的Headers属性提供了这个功能.和WCF里其它关键的类型一样,使 用Headers属性需要我在WCF API里与其它类型交互,即MessageHea

《WCF技术内幕》翻译8:第1部分_第2章_面向服务:消息剖析、消息传输

消息剖析 小时候,我们学习到邮票应该贴在信封的右上角,地址应该写在中间.如果 我们愿意,可以增加一个回复地址在信封的左上角.所有被处理的信件必须遵守 这个基本的结构.如果格式不对,或者地址不清晰,或者地址不合法,邮政服务 会认为这个邮件无效,并且无法投递.如果我们幸运的话,邮件会被退回(如果 写地址的话).可以想象没写地址有多混乱.如果发送者可以允许乱放邮票或者 地址,邮政服务需要查遍整个信封来确定邮票和地址.很可能,为了完成新加投 递任务,每次可能要增加远多于2美分的邮资.实际上,邮局定义的信

消息总线VS消息队列

前段时间实现了一个基于RabbitMQ的消息总线,实现的过程中自己也在不断得思考.总结以及修正.需要考虑各个维度:效率.性能.网络.吞吐量.甚至需要自己去设想API可能的使用场景.模式.不过能有一件事情,自己愿意去做,在走路.吃饭.坐公交的时候都在思考如何去改进它,然后在实践的过程中,促使去思考并挖掘自己知识面的空白,也是一件让人开心的事情. 借此记录下自己在实现的过程中,以及平时的一些想法. 这是第一篇,先谈谈消息总线跟消息队列的区别,以及对于企业级应用需要将消息队列封装成消息总线的必要性.

EQueue - 详细谈一下消息持久化以及消息堆积的设计

前言 之前写了一篇文章,总体介绍了EQueue.在看这篇文章之前如果还没看过那篇文章,可能会看不懂这篇文章.所以建议没看过的朋友务必先看一下那篇文章中所提到的各种概念,这样才能更好的理解本文所说的内容.说实话我当初写EQueue也是抱着一种玩的态度的,就是想尝试写一个分布式消息队列,用来为ENode提供分布式消息通信的能力.后来写着写着,发现越来越好玩,因为觉得这个队列以后应该会很实用,所以就花了更多的时间去设计它,完善它.希望它最终能被更多的人使用.到目前为止,我觉得目前基本实现了以下特性:轻

Google Protocol Buffer使用经验分享(一) C++动态消息与静态消息的博弈

写在前面 相信正在浏览这篇文章的同学,一定已经对PB(Protocol buffer)有所了解,所以这里不罗嗦何为PB了. 我自己从去年年底开始对PB的使用逐渐有一些了解,直到在搜索排序框架(iRank)的重构中尝试应用PB,希望能在"数据结构灵活增删改"和"高效的数据传输反序列化"之间求得平衡. 在这过程之中,对PB 动态消息和静态消息的C++使用方式进行了一些调研,对 动态消息 和 静态消息 的优缺点有了进一步了解.通过阅读源代码和实际应用,总结出一些经验,将

c语言-C语言实现封包解包,有一个消息由标识位,消息头,消息体和校验码组成,如何用C实现对它的封包和解包?

问题描述 C语言实现封包解包,有一个消息由标识位,消息头,消息体和校验码组成,如何用C实现对它的封包和解包? 有一个消息由标识位,消息头,消息体和校验码组成,如何用C实现对它的封包和解包? 解决方案 直接定义成结构体 解决方案二: 定义结构体,然后里面用不同字段定义标识位,消息头,消息体,校验码等 解决方案三: 是呀,如果都是按字节来分的,定位为结构体是一个好方法.