only run code paint event fires?

  • Thread starter Thread starter Schorschi
  • Start date Start date
S

Schorschi

I know there is a way to do this, but I don't know how. Via a custom
event? I have some code that I only want to run during a paint event.
I could build a form instance that has the code and inherit it in all
my other forms, but a simple event link? if that is the right term
would be easier?

Thx.
 
You should be able to overload the render event with your own event. The
base class render event will still fire but will include your extra
functionality

Jody
MCSD.NET
 
Schorschi said:
I know there is a way to do this, but I don't know how. Via a
custom event? I have some code that I only want to run during a
paint event.
I could build a form instance that has the code and inherit it in
all
my other forms, but a simple event link? if that is the right term
would be easier?
Click to expand...

Maybe I'm the only one who doesn't understand your question, but could you
please explain it once more?
 
Hi Schorschi,
I don't know what it does, but it is standard and fires when the form paint
I think

Private Sub Form1_Paint(ByVal sender As Object, ByVal e As
System.Windows.Forms.PaintEventArgs) Handles MyBase.Paint
End Sub

I don't know if it helps you?
Cor
 
Hi Schorschi,

Sounds to me like you need global MessageHandler, and need to capture the
WM_PAINT message.

If you create a class that implements the IMessageHandler interface, then
use the Application object to add a message handler, look for m.Msg = &HF

(or Public Const WM_PAINT As Integer = &HF)

When m.Msg = WM_PAINT, a paint event is occurring on 'some' object, in your
application.

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations
 
Tom,

I think you are right, a global message handler would work fine, but
is not a very .NET way of doing it. If I was using C or C++ I would
go the message routine route, but overloading the the paint handler is
acceptable as well to an extent.

What I was also thinking was a chained sequence of paint routines, for
example, if I add a custom handler that draws a custom panel on a
given form, then a custom icon, then a geometric pattern, etc. but
these draw routines if you will, are a list of drawing elements, or a
collection that I can add or remove from.

Overloading the existing paint handler would allow for the same thing,
I just write an overloaded paint routine on top of another, one key
issue, what if I want to drop out a specific paint element? If it was
a linked list of drawing elements I could do this.

For example, the list might be...

1) Draw square
2) Draw circle
3) Draw Triangle
4) Draw Rectangle

Then I could drop the Draw circle code

1) Draw square
3) Draw Triangle
4) Draw Rectangle

This was the idea. So do I implement handler for each routine and
only call the ones that should be active, i.e. disable others, or
build a collection list and fire all on a paint event? Lots of
options, just need to pick one I guess.
 
I think you are right, a global message handler would work fine, but
is not a very .NET way of doing it.
Click to expand...

Why not.... .NET provides a solid implementation of a global message
handler.

--
HTH,
-- Tom Spink, Über Geek

Please respond to the newsgroup,
so all can benefit

" System.Reflection Master "

==== Converting to 2002 ====
Remove inline declarations
 
Hi Schorschi,

You can override a Control's WndProc quite legitimately in .NET. However
that's a side issue.

It sounds as if you are wanting the flexibility of a dynamic chain of
actions. That makes the word Delegate leap into my mind. Delegates are the
..NET version of C's function pointers, but being objects in their own right,
are much more sophisticated. For instance, they can work synchronously or
async.

You have two choices using Delegates. You can have one Delegate
(multicast) handle a list of drawing elements, or you can have an array
handling one drawing element each.

Another way to go, by the sound of it, would be to define the drawing
elements as independant objects which know how to draw themselves in a given
graphics context. And have a chain of these attached to your actual GUI
elements.

Like you say, including those you already have, lots of options. ;-)

Regards,
Fergus
 
Back
Top