> > Yes, that makes sense - but trying to use it would not crash in
> > itself, it's just not a very sensible thing to do, correct?
>
> No, since handles are just "handles" it won't result in a crash, but many
> bugs are better replaced by a crash. Suppose a program writing
> to your MBR,
> and you don't have a Linux rescue disc handy. Would you prefer
> it to crash
> or corrupt the MBR? :-)
I assume the "bug" you're implying is the bug of corrupting a file by writes
from multiple threads, yes? Otherwise I'm confused - is it OK to share
handles, or not (regardless of whether it would be stupid to try it)?
> Of course, I'm assuming you don't want to do something other than
> sending a
> message to it, or maybe reading a property. I bet you agree that
> painting a
> window in that manner from your ActiveX control is a silly idea!
Goodness yes. I was actually thinking the other way round - the app using,
say, CreateFile() to open a file, and passing the handle to delegate the
actual writing to the OCX for some contrived reason. I just want to
understand the mechanics of it, even if the semantics say it is foolish to
use it in that manner for the situation.
> BTW, OCX is just an extension (an abomination that VB created!) like any
> other: DLL, EXE, JPG, etc.
Yes, but I am using "OCX" to refer to a unit of code that is known as
ActiveX one day and OLE Control another day, etc. {;v) - it's clearly not
quite the same as a DLL, but also not a proper automation server (as an
EXE). Specifically, I'm talking about controls created mostly with VB in
mind (love it or hate it) although of course VC can use them.
--
Jason Teagle
[EMAIL PROTECTED]
_______________________________________________
msvc mailing list
[email protected]
See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for
subscription changes, and list archive.
