problem with RaiseEvents

  • Thread starter Thread starter Co
  • Start date Start date
James said:
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
Click to expand...

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.

--
 
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.
 
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.
 
Mike said:
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)
Click to expand...
<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.
Click to expand...
<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
 
Mike said:
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)
Click to expand...
<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.
Click to expand...
<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
 
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.

--
 
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 said:
<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(...)
Click to expand...

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)
Click to expand...

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.
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
Click to expand...

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.
Click to expand...

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.

--
 
Branco said:
<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(...)
Click to expand...

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)
Click to expand...

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.
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
Click to expand...

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.
Click to expand...

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.

--
 
Branco said:
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.
Click to expand...

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.

--
 
Branco said:
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.
Click to expand...

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.

--
 
Back
Top