Windows Developer Center > Windows Forms Forums > Windows Forms General > help using RaiseMouseEvent and RaiseKeyEvent and RaisePaintEvent and ...
Ask a questionAsk a question
 

Questionhelp using RaiseMouseEvent and RaiseKeyEvent and RaisePaintEvent and ...

  • Monday, January 23, 2006 7:27 PMJeroGrav Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    The docs seem to be thin at best on these functions.

    The definition for the paint one is:

    protected void RaisePaintEvent (
    	Object key,
    	PaintEventArgs e
    )

    Now I can create the PaintEventArgs ok but what it the key? again from the docs:

    key

    The event to raise.

    So it's the event to raise... can anyone give me just a little more info? I can see that key is an Object but that doesn't really narrow it down very much.

    Has anyone actually used this at all?

     

    Regards

    Jero

All Replies

  • Monday, January 23, 2006 7:40 PMBrendan Grant Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Funny... I had not heard of the RaiseXXXEvent functions until today... in either case, for the most part the RaiseXXXEvent functions are identical to the OnXXX functions, an example of this would be the following functions taken from the 2.0 Framework’s Control class:

    protected void RaisePaintEvent(object key, PaintEventArgs e)
    {
          PaintEventHandler handler1 = (PaintEventHandler) base.Events[Control.EventPaint];
          if (handler1 != null)
          {
                handler1(this, e);
          }
    }


    protected virtual void OnPaint(PaintEventArgs e)
    {
          PaintEventHandler handler1 = (PaintEventHandler) base.Events[Control.EventPaint];
          if (handler1 != null)
          {
                handler1(this, e);
          }
    }

    Both are used for raising an event internal to the control where the event to be raised is checked to see if anyone is listening for the event and only make the call if there are listeners.

    Unfortunately I’ve been unable to track down any specifics on what the key property is used for, so I am forced to assume that it is just an optional method of passing more information into the event and it’s subsequent processing given that the 2.0 framework uses RaisePaintEvent identically to OnPaint (and other such RaiseXXXEvent vs OnXXX).

    Does this answer your question?

  • Monday, January 23, 2006 7:59 PMJeroGrav Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Yeah it does - sort of.

    So are you saying that I can just call the On<Event>() function to actually process an event? Thats pretty good.

    The advantage of calling the RaiseKeyEvent() function is that I assume that it puts a message into the message queue and lets it get processed as normal.

    But what I am actually trying to do is to simulate keyboard events on control. Ideally I'd use something like SendKeys.Send() but that works on the *active* application and I only want it to work on my app.

  • Tuesday, January 24, 2006 8:28 PMJeroGrav Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hey again.

    I tried to call the OnKeyDown() function as well as the OnKeyPress() and OnKeyUp() functions in a test app and it doesn't seem to do what I hoped.

    I was hoping that if you created the KeyEventArgs to have Keys.A in it, and called the OnKeyDown() etc events on a textbox then it would add the 'a' to the textbox (ie add it to the Text property).

    But it doesn't. Did I misinterpret what you were trying to say?

  • Wednesday, July 18, 2007 2:37 PMSimon Tamman Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    The key you provide is equivalent to Control.EventPaint or whichever event you need to raise.
    It uses it as the indexer to get the event. The code is basically.

    protected virtual void OnRaiseKeyEvent(object key, KeyEventArgs e)
    {
          KeyEventHandler handler1 = (KeyEventHandler) base.Events[key];
          if (handler1 != null)
          {
                handler1(this, e);
          }
    }


    Slight issue with this, is that these keys are objects; Control's static Ctor goes:

    EventPaint = new object();
    //and so on for the rest of the Event keys

    Main issue is that these are static and PRIVATE.
    Hence, as a standard developer it's not so easy to get access to these, which begs the question why MS decided to open up the RaiseXXX methods in the first place.

    If I find any other useful information i'll post it back here.
    I DONT want to have to end up using SendKeys... *shudders*
  • Wednesday, July 18, 2007 2:44 PMSimon Tamman Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Heh, just use OnKeyUp or whatever event you want to raise with the word On infront.
    Weird.... I coulda sworn that didn't work so well back in 1.0.....

    Still makes one wonder even further why those Raise events exist. The code for OnKeyUp in Control is almost identical to RaiseKeyEvent but you don't need the special event key.

  • Wednesday, July 18, 2007 3:52 PMnobugzMVP, ModeratorUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hmya, this looks like a mistake, probably made back in .NET 1.0.  They should have been declared internal, you can't obtain the value of "key" unless you use Reflection.  They probably couldn't fix the mistake because of compatibility concerns.  It is not a real issue for RaisePaintEvent() because it doesn't use the key argument.  The other one's do though.

    Instead of RaisePaintEvent(), call Refresh() (but updates the background too) or OnPaint().  Or P/Invoke SendMessage() (WM_PAINT = 15).
  • Wednesday, February 13, 2008 5:17 PMa1001001 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    protected override void OnPaint(PaintEventArgs paint)
            {
                //The documentation states that sub classes should
                //call base.OnPaint so that the Paint event will fire.
                //But I have discovered that a call to base.RaisPaintEvent
                //causes the Paint event to fire also. Since base.OnPaint
                //incures the overhead of painting (however small that
                //may be) this is a good replacement for sub classed
                //controls which do not rely on the base class paint method.
                base.RaisePaintEvent(this, paint);
                this.m_Painter.OnPaint(paint, this.ClientRectangle, this);
            }

    I've tested this out by adding a delgate to my form which hosts my subclassed control. I removed the base.OnPaint call and the form stopped recieving the event. I added the base.RaisePaintEvent call and then the form began recieved the events again. I also added a trace statement to my delgate to write out the sender as described by its ToString method.  I discovered that in both cases (OnPaint being called vs. RaisePaintEvent) that the sender is my custom button.

            private void PaintCheck(object sender, PaintEventArgs e)
            {
                System.Diagnostics.Trace.WriteLine("Fader Paint" + sender.ToString( ));
            }

    Output with OnPaint
    Fader PaintFader.FaderButton, Text: faderButton1

    Output with RaisePaintEvent
    Fader PaintFader.FaderButton, Text: faderButton1

  • Wednesday, November 26, 2008 2:37 PMgaume Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hello,

    I respond to this thread because i had the same question and finally found the solution. Little bit late , sorry but hope this will be helpfull for somebody else..

    In Control class The Key object is a the private static field used to store the delegate listenning for the event.

     

    using MouseDown as sample you must have something like

     

    Code Snippet

    class Control

    {

    ..

    private static readonly object EventMouseDown;

    ...

    public event MouseEventHandler MouseDown

    {

    add{ base.Events.AddHandler(EventMouseDown, value); }

    remove{ base.Events.RemoveHandler(EventMouseDown,value); }

    }

     

     

     

    Where "Events" is a EventHandlerList.

    This design is mainly used to avoid memory waste, when multiply delegate object in each instance even when not used.

    The Control class manage almost 70 events, so it's make sens.

     

    So you do not have acccess to the key object used to fired event

     

    As the method is protected your better to use the OnXXX( EventArgs p_args ) which use the following template for MouseDown :

     

    Code Snippet

    protected virtual void OnMouseDown(MouseEventArgs p_e)

    {
        MouseEventHandler l_handler = MouseEventHandler base.Events[EventMouseDown];

        if (handler != null)
        {
            handler(this, p_e);
        }
    }

     

     

    Also if you want to simulate MouseClick event, you can use call to native using the following code

     

    Code Snippet

    ...

    public const uint WM_LBUTTONDOWN = 0x0201;

    public const uint WM_LBUTTONUP = 0x0202;

    [DllImport("coredll.dll")] // for compact framework.. Desktop will be user32.dll

    public static extern int SendMessage(

    IntPtr hWnd, // handle to destination window

    uint   Msg, // message

    Int32  wParam, // first message parameter

    Int32  lParam // second message parameter

    );

    static void SendMouseClick(IntPtr p_iHandle, int p_x, int p_y)

    {

    Int32 l_parm1 = (p_y << 16) | (p_x & 0xffff);

    SendMessage(p_iHandle, WM_LBUTTONDOWN, 0, l_parm);

    SendMessage(p_iHandle, WM_LBUTTONUP, 0, l_parm);

    }

     

    ...

     

     

    All the best.