I'm having one of those rather rare days us programmers cherish - things
going right. So I thought I'd share it with you, since I put out that
message, to let you know it's not urgent now (although I'm still interested
if someone knows the WM_ message(s) involved in comms).
I found a solution to the comms vs. message pump vs. UI triangle in the VB
app that leaves the UI fluid but also manages to accomplish my
don't-initiate-other-actions-until-free need. Rather than delay the mouse
click and key press messages, which results in an unresponsive UI (bloody
irritating, would have done the same by enabling / disabling the UI), I
allow them through but it is the resulting -WM_COMMAND messages- I delay.
Thus, the UI responds perfectly normally to mouse and keyboard (yay!), but
comms are allowed to proceed without the danger of other comms trying to
interrupt (not 100% safe, but near as dammit is to swearing).
If anyone is still busy clicking worry beads over the "not 100% safe", bear
in mind that I think even my home-grown comms DLL would suffer a little if a
second comms request tried to interrupt a current one - would need testing.
I'll take 98% over 50% safety any day.
--
Jason Teagle
[EMAIL PROTECTED]
