drawing in a picturebox

  • Thread starter Thread starter Ringo
  • Start date Start date
R

Ringo

I'm drawing in a picturebox. Right now for testing I have a loop that
does

for (int x = 0; x < 10; x++)
{
DrawSonar();
RobotX += 10;
PB.Invalidate();
Thread.Sleep(200);
}

and
private void DrawSonar()
{
Graphics objGraphics = Graphics.FromImage
(m_objDrawingSurface);
.....
for (angle = (Angle - (BeamWidth / 2)); angle < (Angle +
(BeamWidth / 2)); angle += 2)
{
endX = RobotX + (int)(Range * Math.Cos(angle * 6.28 /
360));
endY = RobotY + (int)(Range * Math.Sin(angle * 6.28 /
360));
objGraphics.DrawLine(Pens.Green, RobotX, RobotY, endX,
endY);
}

objGraphics.Dispose();
PB.Invalidate();
}

The problem is that the screen does no update until after the loop is
done.
Eventually the loop will be relpaced with a timer, but for testing the
loop is easy. What do I do to make it update after each loop?
Thanks
Ringo
 
You can draw in the on Paint event handler and Invalidate the region, as
last step. That will create a kind of 'paint-dirty-loop', though, but that
is exactly what you want, isn't it? (Trick borrowed from "Managed DirectX
9.0", by Tom Miller, at Sams.)

You have to be careful to paint in a control inside a thread which has not
created the control. In fact, it is not suggested at all and you would
probably end up with an illegal cross-thread exception if you try it,
anyhow. See "Multithreaded User Interfaces" , in "Windows Forms 2.0
Programming", by Sells and Weinhardt, at Addison Wesley, as example, for
solutions, it you really need to draw from another thread.



Vanderghast, Access MVP
 
You can draw in the on Paint event handler and Invalidate the region,
as last step. That will create a kind of 'paint-dirty-loop', though, but
that is exactly what you want, isn't it? (Trick borrowed from "Managed
DirectX 9.0", by Tom Miller, at Sams.)
Click to expand...

It's not exactly what he wants...there's a 200ms delay in his loop. If he
tries to recreate the loop simply by invalidating the control from within
the paint handler, his main thread will get stuck for 200ms at a time,
which will cause all sorts of problems.
You have to be careful to paint in a control inside a thread which has
not created the control. In fact, it is not suggested at all and you
would probably end up with an illegal cross-thread exception if you try
it, anyhow. See "Multithreaded User Interfaces" , in "Windows Forms 2.0
Programming", by Sells and Weinhardt, at Addison Wesley, as example, for
solutions, it you really need to draw from another thread.
Click to expand...

You can't execute the code to paint from within a different thread, but
the loop controlling the world model state and the actual invalidation of
the control can easily be within a different thread. For best results,
one would use Control.Invoke() to execute the call to Invalidate() (and
any other control-specific code), but in my experience the Invalidate()
method is actually permitted and works fine cross-thread, even though it's
not documented as such.

Pete
 
The dirty-paint-loop generally works fine SINCE painting messages (as well
as timer messages) are low priorities messages, so are quite unlikely to
create problem to other messaging occuring on the SAME message queue. I
totally fail to see what kind of problem it may generates to other message
queues.

I understand that the 200 msec sleep is not a timer based message, though,
and indeed, 'it may be' required, or it 'may be' some unrelated solution
that the OP tried at a moment or at another, without being a strict
requirement.


Vanderghast, Access MVP
 
The dirty-paint-loop generally works fine SINCE painting messages (as
well as timer messages) are low priorities messages, so are quite
unlikely to create problem to other messaging occuring on the SAME
message queue. I totally fail to see what kind of problem it may
generates to other message queues.
Click to expand...

The "priority" (such as it is) of the messages is irrelevant. To cause a
200 ms delay using your suggestion would require including a call to
Thread.Sleep(200) (or an equivalent) in the paint handler before
invalidating the control again.

That means the paint handler would wait 200 ms before returning. That's
200 ms that the message-handling thread doesn't get to process messages
_at all_. Regardless of their "priority".
I understand that the 200 msec sleep is not a timer based message,
though, and indeed, 'it may be' required, or it 'may be' some unrelated
solution that the OP tried at a moment or at another, without being a
strict requirement.
Click to expand...

The original post made it clear that the code posted was simply for
testing purposes, and that eventually it will be implemented using a
timer. No one ever implements anything using a timer unless they have a
specific need to perform an action after some specific interval; that's
the whole reason for using a timer.

Even if that information wasn't present in the OP (and it was),
speculating on what "might" work doesn't really help the OP, especially if
you don't specifically call that out in your reply (i.e. not qualifying
your suggestion with an explantion of what prerequisities must exist in
order for it to be applicable).

Pete
 
That is a newsgroup, not a book, so if the OP got problem the OP may come
back to supply relevant data, so NO, giving all possible and imaginable
warnings, such as a book or an article should, is NOT necessary appropriate,
here, IMHO.

Furthermore, you 'decided' that it was not what the OP wanted, I would
prefer to hear back from the OP.



Vanderghast, Access MVP
 
That is a newsgroup, not a book, so if the OP got problem the OP may
come back to supply relevant data, so NO, giving all possible and
imaginable warnings, such as a book or an article should, is NOT
necessary appropriate, here, IMHO.
Click to expand...

No one, least of all me, is suggesting one give "all possible and
imaginable warnings". Just the one warning that is most obviously
applicable, given the original question and example code.
Furthermore, you 'decided' that it was not what the OP wanted, I would
prefer to hear back from the OP.
Click to expand...

I didn't "decide" what he wants. I looked at his question and learned
what he wants from that.

It's not at all clear to me why you've got such a chip on your shoulder.
Perhaps because you have some objection to being corrected in public? In
any case, it's not productive...your main concern should be, as mine is,
to help the OP. It's no big deal to make a mistake; but to defend it to
one's death is entirely counter-productive.

Pete
 
" Perhaps because you have some objection to being corrected in public? "

Sorry, but I don't see where I have been wrong, at least, in this thread of
discussion...


Vanderghast, Access MVP
 
" Perhaps because you have some objection to being corrected in public? "

Sorry, but I don't see where I have been wrong, at least, in this thread
of discussion...
Click to expand...

I would say that suggesting he write code that causes a 200 ms delay to
occur during the course of processing a window message is an error.
Actually, I did say basically that already, so I guess maybe "would" is
the wrong word to use.

But, whatever...if you think that's fine, or you think that your post
didn't suggest that, I'm not going to waste more time worrying about it.
I think the point has been made.

Pete
 
Back
Top