除了这个窗口看不见之外,它和程序中创建的另外的子窗口有什么区别?好象没有吧? 实际上根本就不要创建这个窗口,直接将这段代码放到g_hWndMain窗口的窗口过程中然后给g_hWndMain发消息不也可以起到同样的效果吗?
解决方案 »
- tchart绘制动态曲线
- StgCreateStorageEx的第7个参数REFIID riid只能是IID_Storage吗?
- 改变按钮颜色
- 请问在pc端实现与手机红外通信的基本过程
- 求救!!!为什么只能输出一行数据??
- 如何用VC++6.0程序实现修改网关和IE代理
- 简单问题:怎样修改exe文件上方的字???
- 请问哪位大G有关于InstallShield的使用教程???或下载地址???
- VC6中汇编用的是哪个版本?是纯正的8086吗?函数是用__asm还是用_asm?
- 关于message的一些问题?
- 是否一般都会自动把AFXWIN.H文件连接入我们自己编的程序内?谢谢!!!
- 哪里有WINDOWS 高级编程指南配套源程序下载
vcbear(一只平凡无知的熊)说的可能是指CSocket/CAsyncSocket的实现吧,实际上通常的Winsock 消息通知倒不一定要求窗口是不可见的。
如果窗口g_hwnd[0]的一个消息处理函数做一个长时间的操作,那么在这个操作完成之前,procedure2是得不到运行机会的。反过来也一样,在procedure2完成之前,窗口g_hwnd[0]也是得不到运行消息处理机制机会的。2 如果用SendMessage
就是在当前线程做,SendMessage将等待Procedure2完成。
to platoprocedure是g_hwnd的窗口过程,由于这个窗口的目的的单一性,它会是专门用来发wm_com消息的,一般不会收到别的消息,除了wm_create和wm_close外.相对于主线程他的确是相当于又开了一个线程
这种实现方法和将其放在g_hWndMain中的效果完全一样。因为Windows的调度是以线程为单位的。如果MyThread()是一个很耗时的程序段,那么在执行MyThread()函数的时候,你的这个软件的其它部分也不会执行。除非在MyThread中有将控制权释放的函数如Yield等,如果这样的话,这段函数与放在g_hWndMain的窗口函数中还是没有任何区别。这样实现的唯一一个好处是可能使程序结构清楚一些, 在模拟多线程的功能上没有什么创意。
PostMessage( g_hWnd,WM_COM,0,0 ).主程序返回,但程序在MyThread()里执行.实现多线程功能.
所以在任何只要能得到g_hWnd句柄的地方,都可以调用到MyThread()函数.但不阻塞本线程的工作,因为你把消息寄出去后就不用管了.
我看到的这段程序调用是在用户自定义的控件里,通过像g_hWnd送消息,来达到执行MyThread()程序段的效果.(而且很频繁)
还有,你说的如果另外一个窗口,和m_hwnd[0]同属于一个线程,该窗口的一个消息处理函数做一个长时间的操作,那么在这个操作完成之前,procedure2是得不到运行机会的。反过来也一样,在procedure2完成之前,其它窗口也是得不到运行消息处理机制机会的。那是不是意味着DispatchMessage()要等消息执行完了之后才有返回?
DispatchMessage() 仅仅把消息放到相应的消息队列里,它并不等待消息执行完成。
一个线程里的消息肯定是处理了一条,函数返回了再处理另一条的。说来说去,顶上那段代码只是通过消息循环来实现的,不是多线程。
如果你坚持认为是多线程,比较大的可能是上面的代码原先就是运行在另一个线程里的。看不出这种做法有多少可取之处。
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
哈哈,都被admireO(初学者)耍了,这根本不是多线程!
實在看不出來是多線程,若你的看不見窗口和主窗口在一個線程中,那當你在主窗口的過程中發出WM_COM(假定用PostMessage),然后主窗口過程返回,又進入消息循環,再取出WM_COM,調用看不見窗口的窗口過程,到目前為止,始終都是在一個線程打轉,若MyThread是個死循環,難道該線程不會被挂住嗎? 才怪。2 xxxbird(*说你行,你就行,不行也行*):
>>>DispatchMessage() 仅仅把消息放到相应的消息队列里,它并不等待消息执行完成。<<<
如果DispatchMessage只是把消息放到相應消息隊列中,那到底由誰來調用窗口過程呢?
操作系统会调用窗口过程(Window procedure)来处理这些消息。
我覺得你的說法不對,若照你這樣說,DispatchMessage在將消息放入消息隊列后就返回,那麼則消息循環在任何情況下都不會受阻,那又何來因窗口過程占用時間太長而導致窗口無法及時響應鍵盤、mouse事件之說呢?
你沒搞懂我的意思,我說的就是在一個線程的情況下。為簡單化,我們假設該線程只有一個窗口,那麼當收到一個消息后,GetMessage()->DispatchMessage()->窗口過程(中間的其它處理我們暫且略過),若窗口過程處理此消息耗時很久,那麼緊接輸入的key,mouse消息都將得不到處理(注意,是指發生在當前窗口上的各消息)。這個情況我想你也認同。
但如果照xxxbird所說,DispatchMessage只是將消息放入消息隊列后就返回,那麼它將馬上又運行GetMessage()來取得下一消息,那麼你說在這樣的情況下,key,mouse消息會因為上一耗時消息的處理而受阻嗎?
同時還有一點,DispathMessage是有返回值的,而其返回值正是窗口過程的返回值,如果DispatchMessage()只將消息放入消息隊列就走人,那麼請問,該返回值從哪里來?
最后,我從來就沒有認為此帖子所說的是多線程,"最上面的那个人给出的那个代码根本就不是多线程的" 這句話我不知為何要對我說。
我觉得你还没有理解多线程和消息处理的机理
while(::GetMessage( &message,NULL,0,0) )
{
.......
}
和主线程是不在同一线程里.所以不会造成MATE()所说的问题.
今天我又找了些资料,这个应该是线程池的特例吧,和vcbear说的PostThreadMessage()差不多
的确是没什么新意,不过大家的热烈讨论的确长了不少见识,再次谢过了
The GetMessage function retrieves a message from the calling thread's message queue
The return value(of DispatchMessage Function) specifies the value returned by the window procedure. Although its meaning depends on the message being dispatched, the return value generally is ignored.
上面那句话的意思应该是DispatchMessage函数的返回值指定了窗口过程的返回值.所以,mate所说的,DispathMessage是有返回值的,而其返回值正是窗口過程的返回值.关系是否搞反了?但是Dispatch应该是消息处理完后才返回吧,这点同意mate所说的
按照,GetMessage函数的说明,GetMessage是从消息队列中取出消息,所以,消息从GetMessage函数开始就已经被取出来了.
实际上,DispatchMessage函数调用了窗口过程函数。
有几个特殊情况,在WM_TIMER消息中,它调用的是TimerProc而不是窗口过程, 而且不是每次WM_PAINT消息时都调用窗口过程。
不好意思,我沒說清楚,我的意思就是DispatchMessage返回的就是窗口過程的返回值。
原来你上面的代码本来就是运行在另一个线程中的。被我猜中了吧。
你这样建一个窗口,只是把该线程从工作者线程变成了界面线程。
再次谢过,xxxbird,mate,threads,plato,vcbear以及所有讨论的老兄们.