windows核心编程有这样一段话:
“函数P o s t M e s s a g e在登记了消息之后立即返回,调用该函数的线程不知道登记的消息是否被指定
窗口的窗口过程所处理。实际上,有可能这个指定的窗口永远不会收到登记的消息。如果建立这个特定窗口的线程在处理完它的消息队列中的所有消息之前就结束了,就会发生这种事。”我在一个进程里,给另外一个进程发消息,用P o s t M e s s a g e函数,我不想用Sendmessage。如何保证所发消息被处理?请高手指点一下,哪怕给个思路也可以。

解决方案 »

  1.   

    你要什么样的保证 关键是PostMessage里的参数确实是另一个进程的窗口 可以根据窗口标题用FindWindow找到它 你的工作就结束了 PostMessage过程是由OS来完成的 当然目标程序一定要响应这个消息
      

  2.   

    正确的解决方法是保证所有的消息处理完,再让窗口close
      

  3.   

    SendMessage()可以保证消息被接收
      

  4.   

    应该有个确认机制,对方也应该post一个message过来,
    如果超时重新发消息
    psw:跟tcp一样了:)
      

  5.   

    如果真有这个必要的话..你可以探听这个进程中相关线程的消息队列的情况...看看消息队列中是否收到这个消息,,是否从队列取走了这个消息。。利用hook技术就可以近乎完美的实现这目的了。。
      

  6.   

    SendMessageCallback该函数调用指定窗口的 窗口处理过程,并立即返回;当消息被 窗口过程 处理后,系统会调用 指定的回调函数,并返回消息处理的结果和作为回调函数的参数的预先定义的值。
      

  7.   

    直接使用SendMessageCallback只能有机会知道是否消息可以被处理,还不能保证消息一定被处理。大概可以在回调函数是做点文章吧?大概再结合一下同步机制?或不容许接受消息的线程自己结束?
      

  8.   

    是不是不可能达到这个目的啊?我的理解是这样的:既然postmessage是将消息放入消息队列,就应该会被处理的。
    测试结果和我想象的并不一致。
      

  9.   

    to brightboy(笨鱼) 我觉得问题是用什么方法来 接 消息,要是用 WaitMessage,可能消息队列的状态里面虽然有未处理的消息,但因为某些函数改变了 消息队列 的 状态,那么未处理的消息将不会被认为
    是 “ 新 ” 消息,也不会得到处理的机会。 PeekMessage, GetMessage, GetQueueStatus, WaitMessage,MsgWaitForMultipleObjects,  MsgWaitForMultipleObjectsEx这些函数都可以改变“消息队列”的状态。我想这个才是你的问题的真正原因吧,昨天没答在点上。
      

  10.   

    没办法确保对方进程在处理你的消息前死掉,但是可以用SendMessageCallback获知你的消息被处理了。所以应该自定义超时。也可以利用SendMessageTimeout获知消息是否在指定时间内被处理了。
      

  11.   

    我对技术研究的不是很深,不过这样应该确保没有问题:
     
       对每次发送消息后,启动一套检测机制。对发送的消息进行编号,发送后等待消息处理确认消息,不过在一定的时间内没有等到,责认为消息丢了。重发该消息。消息编号不能改变。
       在消息接收端,收到消息处理后发回确认信息。如果收到的消息编号已经处理过了,就直直接返回确认信息。
       
       其实,如果测试一下你会发现,消息被丢掉的可能性几乎为零。用微软的东西,只要遵守他的游戏规则,你不回被“罚款”的。消息机制是windows系统的基础。