problem with RaiseEvents

[Co]

Hi All,

I'm trying to create an Event to get a string but I don't know how to
do it.
I tried several examples on the net but they don't work for me.

I have a form with a textbox containing a date.
When I doubleclick the textbox a form with a monthcalendar opens.
Now I want to the textbox to change whenever I change the date on this
MonthCalendar.

Private Sub MonthCalendar1_DateChanged(ByVal sender As Object, ByVal e
As System.Windows.Forms.DateRangeEventArgs) Handles
MonthCalendar1.DateChanged

newDate = MonthCalendar1.SelectionStart.ToShortDateString
End Sub

How do I create the event and where should it write it?

Marco

 

[James Hahn]

Why are you concerned with creating an event? The event you are trying to
process is already a part of the MonthCalendar class and will occur as per
the definition fot that class (when the date selected in the MonthCalendar
changes). The code example you have provided will copy the date into a
variable. You only need to change that to copy it into the textbox -
something like

TextBox1.Text = MonthCalendar1.SelectionStart.ToShortDateString

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

 

[James Hahn]

Why are you concerned with creating an event? The event you are trying to
process is already a part of the MonthCalendar class and will occur as per
the definition fot that class (when the date selected in the MonthCalendar
changes). The code example you have provided will copy the date into a
variable. You only need to change that to copy it into the textbox -
something like

TextBox1.Text = MonthCalendar1.SelectionStart.ToShortDateString

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

 

[Cor Ligthert[MVP]]

James,

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

Why?

Cor

 

[Cor Ligthert[MVP]]

James,

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

Why?

Cor

 

[Co]

James,



Why?

Cor

The textbox and the MonthCalendar are on different forms.
I'm always told you have to be careful with calling from one form to
another like:

frmCalendar.MonthCalendar1.....

Marco

 

[Co]

James,



Why?

Cor

The textbox and the MonthCalendar are on different forms.
I'm always told you have to be careful with calling from one form to
another like:

frmCalendar.MonthCalendar1.....

Marco

 

[Branco]

Cor Ligthert[MVP] was questioning James Hahn:
[James:]

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

[Cor:]
Why?

A very good reason to me is because event handlers can handle diverse
senders.

Regards,

Branco.

 

[Branco]

Cor Ligthert[MVP] was questioning James Hahn:
[James:]

However, it would be better practice to access it through the event args:

TextBox1.Text = e.Start.ToShortDateString

[Cor:]
Why?

A very good reason to me is because event handlers can handle diverse
senders.

Regards,

Branco.

 

[Cor Ligthert[MVP]]

Cor Ligthert[MVP] was questioning James Hahn:

[James:]

However, it would be better practice to access it through the event
args:

TextBox1.Text = e.Start.ToShortDateString

[Cor:]
Why?

A very good reason to me is because event handlers can handle diverse
senders.

You mean that you change that textbox, while you don't know which calendar
is changed.

Are you making programs for Las Vegas?

The only reason I can think about is as an object is out of scope, but when
controls are placed public it is in my idea not real known as better
practise.
(Or in Silverlight when something is assynchonosly done, but I had not the
idea the OP was talking about that.)

Cor

 

[Cor Ligthert[MVP]]

Cor Ligthert[MVP] was questioning James Hahn:

[James:]

However, it would be better practice to access it through the event
args:

TextBox1.Text = e.Start.ToShortDateString

[Cor:]
Why?

A very good reason to me is because event handlers can handle diverse
senders.

You mean that you change that textbox, while you don't know which calendar
is changed.

Are you making programs for Las Vegas?

The only reason I can think about is as an object is out of scope, but when
controls are placed public it is in my idea not real known as better
practise.
(Or in Silverlight when something is assynchonosly done, but I had not the
idea the OP was talking about that.)

Cor

 

[Co]

Are you making programs for Las Vegas?

I wish I were...

I solved it by creating an datepicker cell on my datagridview so I
don't need that extra form anymore.

Thanks for the help.

MArco

 

[Co]

Are you making programs for Las Vegas?

I wish I were...

I solved it by creating an datepicker cell on my datagridview so I
don't need that extra form anymore.

Thanks for the help.

MArco

 

[Branco]

Cor Ligthert[MVP] was questioning James Hahn:
[James:]

However, it would be better practice to access it through the event
args:
TextBox1.Text = e.Start.ToShortDateString [Cor:]

Why?

A very good reason to me is because event handlers can handle diverse
senders.

You mean that you change that textbox, while you don't know which calendar
is changed.
Yeps.

Are you making programs for Las Vegas?

Nopes, unfortunatelly, but "in my idea" (sic) your reply is rude and
shortsighted.

The only reason I can think about is as an object is out of scope, but when
controls are placed public it is in my idea not real known as better
practise.

Possible translation: "The only reason I can think *of* is *when* an
object is out of scope, but when controls are [public members of a
container] [I don't think that this needs to be considered a better]
*practice*".

Well, that would be *another* reason why accessing the event
parameters is a better practice than accessing the (possibly dead)
hardwired object directly. My point is that the object that triggered
the event may or may not be the object whose name is in the handles
clause. One might call the event handler with a hand-made
DateRangeEventArgs, just for the sake of the side effects (getting the
text box updated with a given date range). Or, on an extreme case, one
might add objects dynamically and attach this same handler to their
events, why not? (perhaps because *that* wouldn't be a very good
practice =))

From a very limited (IMHO) stand point, you could argue that the event
handler in question just needs to access the current content of that
given calendar object. I'd argue that the duty of that particular
event handler is to acces whatever information came in the parameter
list (even if it comes from no calendar at all). Therefore, I do
aggree (with James) that it would be a better practice to read from
the parameters, not from the calendar itself, because (in my opinion)
the event handler may be reused to handle another calendar or even be
passed a synthesized parameter list.

(Or in Silverlight when something is assynchonosly done, but I had not the
idea the OP was talking about that.)

You, obviously, had no idea of what the OP was talking about. What are
you, a psychic? =))

Regards,

Branco.

 

[Branco]

Cor Ligthert[MVP] was questioning James Hahn:
[James:]

However, it would be better practice to access it through the event
args:
TextBox1.Text = e.Start.ToShortDateString [Cor:]

Why?

A very good reason to me is because event handlers can handle diverse
senders.

You mean that you change that textbox, while you don't know which calendar
is changed.
Yeps.

Are you making programs for Las Vegas?

Nopes, unfortunatelly, but "in my idea" (sic) your reply is rude and
shortsighted.

The only reason I can think about is as an object is out of scope, but when
controls are placed public it is in my idea not real known as better
practise.

Possible translation: "The only reason I can think *of* is *when* an
object is out of scope, but when controls are [public members of a
container] [I don't think that this needs to be considered a better]
*practice*".

Well, that would be *another* reason why accessing the event
parameters is a better practice than accessing the (possibly dead)
hardwired object directly. My point is that the object that triggered
the event may or may not be the object whose name is in the handles
clause. One might call the event handler with a hand-made
DateRangeEventArgs, just for the sake of the side effects (getting the
text box updated with a given date range). Or, on an extreme case, one
might add objects dynamically and attach this same handler to their
events, why not? (perhaps because *that* wouldn't be a very good
practice =))

From a very limited (IMHO) stand point, you could argue that the event
handler in question just needs to access the current content of that
given calendar object. I'd argue that the duty of that particular
event handler is to acces whatever information came in the parameter
list (even if it comes from no calendar at all). Therefore, I do
aggree (with James) that it would be a better practice to read from
the parameters, not from the calendar itself, because (in my opinion)
the event handler may be reused to handle another calendar or even be
passed a synthesized parameter list.

(Or in Silverlight when something is assynchonosly done, but I had not the
idea the OP was talking about that.)

You, obviously, had no idea of what the OP was talking about. What are
you, a psychic? =))

Regards,

Branco.

 

[James Hahn]

I wish I were...

I solved it by creating an datepicker cell on my datagridview so I
don't need that extra form anymore.

Thanks for the help.

MArco

A lot of discussion of this task makes it more confusing than it needs to
be.

To broadcast an event to another form (or forms) you need to create the
event in the form from which it is to be broadcast (FormA):
Public Event MonthChanged(ByVal Month As Integer)

and then raise the event whenever you need to:
Private Sub MonthCalendar1_DateChanged(ByVal sender As Object, _
ByVal e As System.Windows.Forms.DateRangeEventArgs)
_
Handles MonthCalendar1.DateChanged
RaiseEvent MonthChanged(e.start)
End Sub

On any form that needs to listen for that event, you create the event
handler:
Private Sub MonthChangeHandler(ByVal NewMonth as integer)
Textbox1=NewMonth.ToShortDateString
End Sub

and tie the event handler to the event (eg, in the form load event):
AddHandler FormA.MonthChanged, AddressOf MonthChangeHandler

 

[James Hahn]

If the routine is made general it is re-usable in a variety of
circumstances. For instance, it appears that OP may have had a reason to
create the event after all, and in that case the code in the event handler
would have continued to work for the new event without needing any changes.

 

[James Hahn]

I wish I were...

I solved it by creating an datepicker cell on my datagridview so I
don't need that extra form anymore.

Thanks for the help.

MArco

A lot of discussion of this task makes it more confusing than it needs to
be.

To broadcast an event to another form (or forms) you need to create the
event in the form from which it is to be broadcast (FormA):
Public Event MonthChanged(ByVal Month As Integer)

and then raise the event whenever you need to:
Private Sub MonthCalendar1_DateChanged(ByVal sender As Object, _
ByVal e As System.Windows.Forms.DateRangeEventArgs)
_
Handles MonthCalendar1.DateChanged
RaiseEvent MonthChanged(e.start)
End Sub

On any form that needs to listen for that event, you create the event
handler:
Private Sub MonthChangeHandler(ByVal NewMonth as integer)
Textbox1=NewMonth.ToShortDateString
End Sub

and tie the event handler to the event (eg, in the form load event):
AddHandler FormA.MonthChanged, AddressOf MonthChangeHandler

 

[James Hahn]

If the routine is made general it is re-usable in a variety of
circumstances. For instance, it appears that OP may have had a reason to
create the event after all, and in that case the code in the event handler
would have continued to work for the new event without needing any changes.

 

[Mike]

A lot of discussion of this task makes it more confusing than it needs
to be.

To broadcast an event to another form (or forms) you need to create the
event in the form from which it is to be broadcast (FormA):
Public Event MonthChanged(ByVal Month As Integer)

and then raise the event whenever you need to:
Private Sub MonthCalendar1_DateChanged(ByVal sender As Object, _
ByVal e As
System.Windows.Forms.DateRangeEventArgs) _
Handles MonthCalendar1.DateChanged
RaiseEvent MonthChanged(e.start)
End Sub

On any form that needs to listen for that event, you create the event
handler:
Private Sub MonthChangeHandler(ByVal NewMonth as integer)
Textbox1=NewMonth.ToShortDateString
End Sub

and tie the event handler to the event (eg, in the form load event):
AddHandler FormA.MonthChanged, AddressOf MonthChangeHandler

James, I am currently working on class events and controls.

So far for events, the class is modeled like you described above but
the events are triggered by callbacks:

public classs CWildcatEvents

' class events

Public Event OnPageMessageHandler(ByVal msg As TPageMessage)
Public Event OnChatMessageHandler(ByVal msg As TChatMessage)
Public Event OnFileEventHandler(ByVal page As TSystemEventFileInfo)
Public Event OnMailEventHandler(ByVal page As TSystemEventMailInfo)

' Call back handler
Delegate Function cbWildcatDelegate( _
ByVal userdata As UInt32, _
ByRef msg As TChannelMessage) As UInt32

end class

If a developer may prepare it like so in his main code:

' event custom event handler
Sub OnChatMessage(ByVal page As TChatMessage)
End Sub

...
Dim evt As New CWildcatEvents
evt.RegisterChatChannel()
evt.AddChatMessageHandler(AddressOf OnChatMessage)

When the evt object is instantiated, it will prepare the delegate
callback.

The callback delegate has logic like for this event:

Dim page As TChatMessage = ChannelEventType(Of TChatMessage)(cmsg)
RaiseEvent OnChatMessageHandler(page)


My Question, I think I want to make this a standard event prototype,
with sender and EventArgs parameters, for example:

Public Event OnChatMessageHandler( _
ByVal sender As Object, ByVal e As System.EventArgs)

How do I prepare the call back to set this up? Who would be the
"sender" in this case, the class? IOW, I do I prepare the RaiseEvents?

RaiseEvent OnChatMessageHandler(Me?, page?)

Also, this may be related as I am currently trying to make this a
CONTROL (or COMPONENT?) so it can be added the the IDE toolbar and the
control be dropped on a from.

Once I figure that out, will the proper setup for this mean that I
will need to use a event handler with Sender and EventArgs?

Thanks for any insight you (or anyone else) can provide.

--