problem with RaiseEvents

microsoft.public.dotnet.languages.vb

13 May 2009 8:26 AM

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

13 May 2009 10:14 AM

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

Show quoteHide quote

"Co" <vonclausow***@gmail.com> wrote in message
news:e02007be-c448-4f75-9913-9f8c669f6999@z5g2000vba.googlegroups.com...
> 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

13 May 2009 12:01 PM

Cor Ligthert[MVP]

James,

> However, it would be better practice to access it through the event args:
>
> TextBox1.Text = e.Start.ToShortDateString
>
Why?

Cor

13 May 2009 12:45 PM

On 13 mei, 14:01, "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl>
wrote:
> James,
>
> > However, it would be better practice to access it through the event args:
>
> > TextBox1.Text = e.Start.ToShortDateString
>
> 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

13 May 2009 5:04 PM

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.

13 May 2009 5:16 PM

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

13 May 2009 6:32 PM

> 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

13 May 2009 10:01 PM

James Hahn

"Co" <vonclausow***@gmail.com> wrote in message
news:e154e277-d88b-48d3-ac21-6976f717a259@e24g2000vbe.googlegroups.com...
>
>> 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

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

13 May 2009 11:42 PM

Mike

James Hahn wrote:

Show quoteHide quote

> 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.

14 May 2009 1:02 AM

James Hahn

Whether or not the sender is part of the event argument list depends on how
you are handling the event notification and what the handler needs to know.
If the handler doesn't need to know the sender, there's no point in
including it. But if the handler does need to know, then it should be
included, and the object to nominate is the object that the handler should
need to have for whatever action the handler is going to take with that
object. If you are talking a generic event, then you will need to decide
what object has generic usefullness. Similarly for the eventargs - it's
convenient, but not essential, and what you include is a design decision
based on application requirements. If you adopt the typical component form
of the event, then your event definition would become:

Public Event OnPageMessageHandler(ByVal sender as object, e as
PageMessageEventArgs)

Note that this is the event, not the handler, so my preference would be

Public Event OnPageMessageEvent(ByVal obj as object, ByVal e as
PageMessageEventArgs)

The eventargs you provide (eg, PageMessageEventArgs) is subclassed from
System.EventArgs with the properties that the handler needs (TPageMessage,
perhaps). So raising the event becomes:

PM = New PageMessageEventArgs
PM.TPageMessage = <whatever>
RaiseEvent OnPageMessageHandler(myObject, PM)

with the appropriate changes to the event handler code needed to extract the
TPageMessage.

Show quoteHide quote

"Mike" <unkn***@unknown.tv> wrote in message
news:eVDV7RC1JHA.3700@TK2MSFTNGP06.phx.gbl...
> James Hahn wrote:
>
>> 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.
>
> --
>
>
>
>

14 May 2009 2:11 AM

Branco

Mike wrote:

> 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)

<snip>

The recommendation is that event names are modelled after verbs/verb
phrases. Notice also in your event naming that the event itself is not
the handler (use "Handler" in delegate type names, not in the event
name):

   Public Event SendPageMessage(...)

   Public Delegate Sub SendPageMessageHandler(...)

If you are designing a base class that will raise the events, then
define protected methods named On<EventName> for each event that you
want derived classes to be able to raise (otherwise the derived
classes won't be able to raise specific events of the base class):

'in the base class
Protected Overridable Sub OnSendPageMessage(...)
    RaiseEvent SendPageMessage(...)
End Sub

(maybe that's the reason why creating events and event handlers named
"On" something isn't a good idea, that is, *if* you are following
these guidelines, of course)

If the events are general (i.e. not specific to a given class), then
you may declare then inside an interface, and every class that wants
to raise those kind of events would implement that interface:

Interface IPageEventSource
    Event SendPageMessage(...)
End Interface

Class PageSendingClass
Implements IPageEventSource

    Public Event SendPageMessage(...) _
    Implements IPageEventSource.SendPageMessage

    ...
End Class

As for the event parameters, you're not forced to, but it's expected
that your events have a parameter "Sender" As Object and a parameter
"e" as (or derived from) EventArgs. Notice the naming style:

Class PageMessageEventArgs
Inherits EventArgs

    Public Property X ...
    Public Property Y ...
End Class

If you do this, then you may use the EventHandler(Of T) delegate type
to simplify the event declaration:

Public Event SendPageMessage As EventHandler(Of
PageMessageEventArgs)
Public Event SendChatMessage As EventHandler(Of
ChatMessageEventArgs)
Public Event FileDeleted As EventHandler(Of FileActionEventArgs)
... etc, etc...

> 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.

<snip>

As you can see, there's not much preparation to raise/handle the
events (unless I'm missing something of what you want to do). The
language does most of the work for you. No need to register listeners
or call proxies.

From what I understood, it seems that you should declare those events
in one or more interfaces and have specific classes implement them.
This way you may have "clients" declaring the event source however
they want.

Class ClientClass

    'events handled automatically in sub declared
    'with Handle xxxx.SendPageMessage
    Private WithEvents P1 As IPageEventSource
    Private WithEvents P2 As PageSendingClass

    'elements in an array or otherwise
    'may be explicitly plugged into using AddHandler
    'as in the sub AddNewItem bellow
    Private MyList As New List(Of PageSendingClass)

    Sub PageSender_SendPageMessage( _
      Sender As Object, _
      e As PageMessageEventArgs _
    ) Handles P1.SendPageMessage, _
    P2.SendPageMessage

      HandlePageMessage(Sender, e)

    End Sub

    Sub AddNewItem(P As PageSendingClass)
      'wires a local method to the SendPageMessage
      'event of the object
      AddHadler P.SendPageMesssage, _
        AddressOf HandlePageMessage
      MyList.Add(P)

      'remember to call RemoveHandler when you want to
      'dettach the event!
    End Sub

    Sub HandlePageMessage( _
      Sender As Object, _
      e As PageMessageEventArgs _
    )
      Debug.Print("woot! a page message!")
    End Sub

End Class
HTH.

Regards,

Branco

14 May 2009 2:40 AM

Mike

James and Branco, thanks for your inputs. I have to read more deeply
into your post.

Overall, this is the project goals.

Currently, we have a WIN32 SDK for our server. It is raw functions and
structures for all the native languages.

For .NET, the goals are is to provides a rick SDK for our package with
many helper classes.

   (X means done, - partially done)

   [X] Create a pure .NET BASE API of the WIN32 SDK

   [-] Create non UI helper classes

       - CWildcatServer (prepared connect/session creation)
       - CWildcatEvents (prepares callback events)

       about 5-6 others.

   [ ] Create design-time controls for GUI development
       (I guess this means wrapping the above non-ui classes)

       For example, for CWildcatServer, two properties and
       one event:

         LocalConnect as boolean = TRUE
         HostAddress as String (optional)

         Publice Event Sub ConnectionDrop
         ' for when the server (admin) forced them out or
         ' server connection was lost

       I want this to be part of a control with a propery page
       when they drop the non-ui control to the application form.

       For CWildcatEvents control, its more extensive but I see
       properties and events for the built-in channels to be
       part of the design time editor:

         OpenPageChannel:   TRUE|FALSE
         OpenChatChannel:   TRUE|FALSE

         OnPageMessage:     ____________
         OnChatMessage:     ____________

       and when they click on the events the ide auto creates the
       stub function/sub code.

       etc.

Once I can figure out how to do the controls I think it will all fall
in place because that is #1 in adding the feature to the .NET SDK.

Hope that provides a better view of where I'm going with this.

--

Branco wrote:

Show quoteHide quote

> Mike wrote:
>> 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)
> <snip>
>
> The recommendation is that event names are modelled after verbs/verb
> phrases. Notice also in your event naming that the event itself is not
> the handler (use "Handler" in delegate type names, not in the event
> name):
>
>    Public Event SendPageMessage(...)
>
>    Public Delegate Sub SendPageMessageHandler(...)
>
> If you are designing a base class that will raise the events, then
> define protected methods named On<EventName> for each event that you
> want derived classes to be able to raise (otherwise the derived
> classes won't be able to raise specific events of the base class):
>
>   'in the base class
>   Protected Overridable Sub OnSendPageMessage(...)
>     RaiseEvent SendPageMessage(...)
>   End Sub
>
> (maybe that's the reason why creating events and event handlers named
> "On" something isn't a good idea, that is, *if* you are following
> these guidelines, of course)
>
> If the events are general (i.e. not specific to a given class), then
> you may declare then inside an interface, and every class that wants
> to raise those kind of events would implement that interface:
>
>   Interface IPageEventSource
>     Event SendPageMessage(...)
>   End Interface
>
>   Class PageSendingClass
>   Implements IPageEventSource
>
>     Public Event SendPageMessage(...) _
>     Implements IPageEventSource.SendPageMessage
>
>     ...
>   End Class
>
> As for the event parameters, you're not forced to, but it's expected
> that your events have a parameter "Sender" As Object and a parameter
> "e" as (or derived from) EventArgs. Notice the naming style:
>
>   Class PageMessageEventArgs
>   Inherits EventArgs
>
>     Public Property X ...
>     Public Property Y ...
>   End Class
>
> If you do this, then you may use the EventHandler(Of T) delegate type
> to simplify the event declaration:
>
>   Public Event SendPageMessage As EventHandler(Of
> PageMessageEventArgs)
>   Public Event SendChatMessage As EventHandler(Of
> ChatMessageEventArgs)
>   Public Event FileDeleted As EventHandler(Of FileActionEventArgs)
>   ... etc, etc...
>
>> 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.
> <snip>
>
> As you can see, there's not much preparation to raise/handle the
> events (unless I'm missing something of what you want to do). The
> language does most of the work for you. No need to register listeners
> or call proxies.
>
> From what I understood, it seems that you should declare those events
> in one or more interfaces and have specific classes implement them.
> This way you may have "clients" declaring the event source however
> they want.
>
>   Class ClientClass
>
>     'events handled automatically in sub declared
>     'with Handle xxxx.SendPageMessage
>     Private WithEvents P1 As IPageEventSource
>     Private WithEvents P2 As PageSendingClass
>
>     'elements in an array or otherwise
>     'may be explicitly plugged into using AddHandler
>     'as in the sub AddNewItem bellow
>     Private MyList As New List(Of PageSendingClass)
>
>     Sub PageSender_SendPageMessage( _
>       Sender As Object, _
>       e As PageMessageEventArgs _
>     ) Handles P1.SendPageMessage, _
>     P2.SendPageMessage
>
>       HandlePageMessage(Sender, e)
>
>     End Sub
>
>     Sub AddNewItem(P As PageSendingClass)
>       'wires a local method to the SendPageMessage
>       'event of the object
>       AddHadler P.SendPageMesssage, _
>         AddressOf HandlePageMessage
>       MyList.Add(P)
>
>       'remember to call RemoveHandler when you want to
>       'dettach the event!
>     End Sub
>
>     Sub HandlePageMessage( _
>       Sender As Object, _
>       e As PageMessageEventArgs _
>     )
>       Debug.Print("woot! a page message!")
>     End Sub
>
>   End Class
> HTH.
>
> Regards,
>
> Branco

14 May 2009 2:57 AM

Mike

Branco wrote:

Show quoteHide quote

>> 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)
> <snip>
>
> The recommendation is that event names are modelled after verbs/verb
> phrases. Notice also in your event naming that the event itself is not
> the handler (use "Handler" in delegate type names, not in the event
> name):
>
>    Public Event SendPageMessage(...)
>    Public Delegate Sub SendPageMessageHandler(...)

Right, james pointed to out too. Yes, I need to get the nomenclature
correct. I did have OnXXXXEvent() but changed it to OnXXXXXHandler
for some reason. :-) I think because in current non-.NET GUI apps that
is how I have it. But your right, for .NET its better as you and
James suggest.

> If you are designing a base class that will raise the events, then
> define protected methods named On<EventName> for each event that you
> want derived classes to be able to raise (otherwise the derived
> classes won't be able to raise specific events of the base class):
>
>   'in the base class
>   Protected Overridable Sub OnSendPageMessage(...)
>     RaiseEvent SendPageMessage(...)
>   End Sub
>
> (maybe that's the reason why creating events and event handlers named
> "On" something isn't a good idea, that is, *if* you are following
> these guidelines, of course)

Just use to the OLDER guidelines like in MFC, DELPHI and other
languages. :-) Delphi of course was invented by the same person who
did .NET. But again, its better as you suggest since the target
audience are .NET developers.

Show quoteHide quote

> If the events are general (i.e. not specific to a given class), then
> you may declare then inside an interface, and every class that wants
> to raise those kind of events would implement that interface:
>
>   Interface IPageEventSource
>     Event SendPageMessage(...)
>   End Interface
>
>   Class PageSendingClass
>   Implements IPageEventSource
>
>     Public Event SendPageMessage(...) _
>     Implements IPageEventSource.SendPageMessage
>
>     ...
>   End Class

I was going to use Interface once the basic model was completely. I
have a template (Generic function) that handles the type casting of
our built-in channel message events:

     Public Function ChannelEventType(Of T)( _
            ByRef cmsg As TChannelMessage) As T
         Dim x As T
         Dim h As IntPtr = Marshal.AllocHGlobal(Marshal.SizeOf(x))
         Marshal.Copy(cmsg.Data, 0, h, Marshal.SizeOf(x))
         x = CType(Marshal.PtrToStructure(h, GetType(T)), T)
         Marshal.FreeHGlobal(h)
         Return x
     End Function

But you touch on something because developers can create their own
channels and data structure for them. Here I was think the call back
would just raise an event that passes the raw TChannelMessage, and I
think they would be able to do it themselves:

    Public Sub OnCustomChannelEvent(_
          ByVal sender As Object, ByVal e As TChannelMessageEventArgs)

      ' add your code here, map e.Data to your custom structure.
       Dim c as TCustom = Sender.ChannelEventType(Of TCustom)(e)

    end sub
    ...
    Dim evt As New CWildcatEvents
    evt.AddChannel("MyCustom.Channel")
    evt.AddHandler(AddressOf OnCustomChannelEvent)

> From what I understood, it seems that you should declare those events
> in one or more interfaces and have specific classes implement them.
> This way you may have "clients" declaring the event source however
> they want.

I have to review the rest of your message for a generic page class.
But overall right now, its only like you said with the idea that any
developer who is creating their own channels, they can do the above.

14 May 2009 8:59 AM

Mike

Branco wrote:

>
> As you can see, there's not much preparation to raise/handle the
> events (unless I'm missing something of what you want to do). The
> language does most of the work for you. No need to register listeners
> or call proxies.

Yes, now that I finally got a non-UI component working with the ease
of adding properties and events, I am beginning to see your point. (I
have a question about designer class below).

As a systems designer, I am more incline to develop the low level
tools and generally need to know how things fundamentally work to
reduce quality/support issues down the road. .NET no doubt is doing of
much of the work, including replacing part of the current framework
and methods already in place, which is what I am seeking. Using helper
or framework library is great once you understand them.

Overall, at the end of the day, the end result I seek are .NET SDK API
and classes that will work for console and GUI applications for a
functional programming developer base and oops oriented developer base
either by directly imported/reference and/or installed as toolbox
components, and ideally, the more single source, the better. :-)

What I need to do now is take a step back and swallow everything I
learned so far (studying the ideas you provided as well) and basically
understand the .NET class hierarchy and framework.

wrt to the designer class, I see that there is a partial class for the
component class:

     WildcatComponent.vb
         WildcatCommonent.Designer.vb

Is this class editable or it is meant to be maintained by the IDE? I
see one note in the class about not editing, but is that only for the
InitializeComponent() method?

I ask because I don't know at this moment where to inherit my "base"
classes yet. What I had so far is:

     public class CWildcatAPI

       Has all the marshared structures and DLLImports from
       the RPC client DLL.

     public class CWildcatAbstract : Implements IDisposable

       Make sure there is graceful disconnect

     public class CWildcatEvents : inherits CWildcatAbstract

       Handles callbacks from the RPC wire hander

     public class CWildcatFiles : inherits CWildcatAbstract

       groups the FILES database related CWildcatAPI functional group

     public class CWildcatUsers : inherits CWildcatAbstract

       groups the USER database related CWildcatAPI functional group

and other similar classes. All of these are in a

     wildcat.net.server.dll

But the main point this DLL should work for console and GUI.

So if I have this new Wildcat.Net.Server.UI.DLL component dll class

     public class CWildcatComponent
        ' properties
        ' events
     end class

and this partial designer class

     Partial Class WildcatComponent
         Inherits System.ComponentModel.Component
       ' constructor/destructors
       ' InitializeComponents()
     end classes

I am wonder where I begin to add the base classes.

I stopped when I tried this:

     public class CWildcatComponent
           inherits wildcat.net.server
     end class

and the IDE said it doesn't base class of Wildcat.net.server does not
match the base class of System.ComponentModel.Component.

I guess I could make it dynamic, but when I tried to add a new() to
the CWildcatComponent, the IDE placed me in the designer class, hence
the question if I can edit the designer class.

Anyway, still have lots to learn. :-)

Thanks for your great assistance.

13 May 2009 9:38 PM

Branco

Cor Ligthert[MVP] wrote:
Show quoteHide quote

> > 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.

13 May 2009 10:01 PM

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.

Show quoteHide quote

"Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote in message
news:eRnuhK80JHA.4272@TK2MSFTNGP06.phx.gbl...
> James,
>
>> However, it would be better practice to access it through the event args:
>>
>> TextBox1.Text = e.Start.ToShortDateString
>>
> Why?
>
> Cor