Re: trouble with CDC

"Any program that requires a Sleep to work correctly is inherently wrong to
start with!"

Yes, I agree. I put it in as a test and to make some progress until I could
figure out what is going wrong. I dislike timer delays because unless you
guess perfectly, you are either wasting time or still facing the problem
that the delay is supposed to be hiding. That's why I asked if the pointer
that is return cannot be used immediately, how can I tell when it is safe to
use it?

"I'm sure there an "error", whatever that means! But you have not said what
the error is, so we are left to use psychic vibrations to determine the
cause."

I also don't know what the error is. That's why I'm here looking for the
help of experts with lots of experience. What I know is what I mentioned
about certain pointers or handles being NULL. Running out of GDI resources
might be the cause and I will test for that. But it's seems unlikely to me
that GDI resources would be depleted after fewer calls (not after a shorter
time) with a 1 msec delay than with a 50 msec delay. The help says typically
that a function returns 0 if error and non zero if success. So 0 only tells
me there was an error but not what the error was. It also doesn't tell me to
call GetLastError so I assume it's not updated in this case.

"you must first DeleteObject to kill the bitmap"

Okay, thanks. I'll try this. I'd rather not Detach and recreate all the time
if it's not necessary. But many MFC functions that return a pointer say that
the pointer is temporary and should not be saved for future use. So I try
getting a fresh one before I need to use it because I don't know such when a
pointer will become "stale". Could you please shed some light on that? When
do these temporary pointers become invalid? Is it a matter of memory being
swapped out and into a new address? Or control switching out of my thread
then coming back? Is the underlying bitmap or DC (in this example) stable
but only the MFC object might not have a stable connection to it (meaning I
should use the SDK level instead of MFC)?

"The word "crash" is a nonsense term"

Yes, it was ASSERTs in the MFC code or sometimes also access violations. I
traced backwards to find the cause and found the NULL pointers / handles.

"Well, then it would help if you checked the return values and did not
continue execution if there is a problem."

I agree but then my goal will be to recover from the error. How to recover
when the error is not understood. I'm pretty sure you will disagree with my
way of working, but I tend to go for the functionality first then come back
and fill in the error checking and recovery to a level that depends on who
the user will be. If for myself only, I do less of it and if for others I do
more.

"Note also that "capturing the bitmap" means you will capture the
rectangular area of the screen that defines where the window is"

Yes, I'm aware of that. It caught me by surprise in an earlier project but
thinking about it, it's quite logical. At first I thought there was some
image of each window in memory somewhere and Windows displays it and the
program maintains it. But then I learned that the program paints or draws to
the screen directly when Windows asks it to. On this project I discovered
that when the workstation times out and locks itself, there is also nothing
there to capture.

Thanks.

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:u4q6s5hvlckon72ngk3sc2ul709e2jbcdq@4ax.com...