0

I have a method in my code, it's name is bindingSource_PositionChanged. the definition of it is:

private: System::Void bindingSource_PositionChanged(**System::Object^  sender, System::EventArgs^  e**) 
{
    toolStripStatusLabel->Text = String::Format("Datensatz {0:N0} von {1:N0}", bindingSource->Position + 1, bindingSource->Count);
}

My questions:

  1. I have in my program calling the function in this way:

    bindingSource_PositionChanged(nullptr, System::EventArgs::Empty);

    my Question 1: what makes pass System::EventArgs::Empty to the parameter e of this function? or to any System::EventArgs^. and what makes pass nullptr to the parameter sender here? or to any System::Object^ sender?

  2. I have in my program calling the function in another way: 

    bindingSource_PositionChanged(nullptr, nullptr);

    Question 2: what makes a nullptr to the parameter e of this function? or to any parameter of the type System::EventArgs^?

Thirumalai murugan
  • 5,698
  • 8
  • 32
  • 54
joni klaoud
  • 1
  • 2
  • 1
    Is this C#? I haven't seen the ^ character in its syntax before. EDIT: Or `toolStipStatusLabel->Text` – Chris Sinclair Jul 03 '13 at 11:57
  • 1
    This is C++/CLI. Not C#. – Simon Whitehead Jul 03 '13 at 11:58
  • it is C++/ClI. but i think the question will the same in c#. what the meaning to pass nullptr to variable system.EventArgs? and what the meaning to pass it to variable System.Object.sender? and what is the meaning to pass System.EventArgs.Empty to variable system.EventArgs? thank you – joni klaoud Jul 03 '13 at 12:06

1 Answers1

3

This will matter if and only if the event's subscriber(s) do something with those values and expect them to be non-null. Normally the sender is the object most "responsible" for the event (and indeed often, but not always, the object that the subscriber subscribed to). EventArgs by itself doesn't convey any interesting information, so it is entirely possible that the caller doesn't check it; but for more interesting events it would be common for the subscriber to access some information from the args - so if it was null this would often fail. EventArgs::Empty simply avoids the need to create a new but uninteresting EventArgs instance each time - since there is no information, all your events that use EventArgs might as well use the same instance.

You can send null for either sender or args; but don't be surprised if that stops some handlers from loving you. It would be preferable to send the logical sender and (in the presumed absence of anything more interesting), EventArgs::Empty.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • but in this function i don't find any reason to pass nullptr or pass EventArgs::Empty to it? i see that the sender and the EventArgs are not important to do this function its job? is that right? thanks once again – joni klaoud Jul 03 '13 at 12:28
  • 2
    @joniklaoud the entire point of an event is to separate the invoker and the subscriber; the invoker cannot say things like "are not important" - for all you know, the handler wants to use (for example) a single common "click" handler, and use the `sender` to find out *what* was clicked, and thus what to do - a common practice if the UI is being built dynamically at runtime. And similarly for any other non-UI example. – Marc Gravell Jul 03 '13 at 12:31