> > Your link does say to use SendMessage, though it doesn't talk about > > not using PostMessage. It looks like my reference > > (http://tinyurl.com/4rjgx) refers to Windows CE but I've read the same > > thing (not to use PostMessage for WM_COPYDATA) in other places > > (http://tinyurl.com/56tn3, http://tinyurl.com/6zj3k), plus I can't see > > how using PostMessage would be safe in sharing data between > > applications. > > Hmmm, I really don't know; I have not tested it. It would be trivial for > the OS to copy the data into its own buffers if you had called > PostMessage( > ), but who knows what goes on inside Windows? :-)
My copy of MSDN, the original one that came with VC6 Enterprise (and appears not to have been changed by installing SP5), clearly says not to use PostMessage. It also says that the data you pass must not contain pointers or references to other data, and that other threads must not alter that data being passed. I have a theory: what if, in order to share that data, the system made that lump of memory (in the sending ends's address space) /directly shareable/ until the call to SendMessage() returned? A minor violation of its own shared memory rules? If that were true, it would explain why you can't use PostMessage: it would return before the receiving end processed it, and the memory would no longer be accessible. It would explain why pointers and references couldn't be used: they wouldn't be accessible since they were not in the block of memory you passed, and thus weren't made shareable. I'm not sure why other threads can't change it though; perhaps doing so would somehow invalidate the shared memory area and render it useless (kind of like the way removing an element of a collection via an iterator might render the iterator itself invalid, since the collection has now changed). -- Jason Teagle [EMAIL PROTECTED] _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
