473,326 Members | 2,173 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Is the usual Event format the only way to go?

Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

....

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks


Apr 17 '07 #1
14 1162
active,

A convention is only useful if it is followed.

The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.

Of course, nothing is preventing you from using any event signature that
works for you.

Kerry Moorman
"active" wrote:
Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

....

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks


Apr 17 '07 #2
thanks for your comments
"Kerry Moorman" <Ke**********@discussions.microsoft.comwrote in message
news:AF**********************************@microsof t.com...
active,

A convention is only useful if it is followed.

The .Net framework uses this convention religiously. Therefore, any
programmer familiar with .Net events will be familiar with events that you
create.

Of course, nothing is preventing you from using any event signature that
works for you.

Kerry Moorman
"active" wrote:
>Because of a strong recommendation I saw in this NG all my events are of
the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

....

I always wondered about the need for that format and figured I'd look
into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks



Apr 18 '07 #3
active wrote:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
I always wondered about the need for that format and figured I'd look into
it someday.
Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be.
And therein lies the crux of the argument.

How can code that you write /today/ know who or what might be throwing
this event at it at any point in the Future?

Events are most commonly raised by Controls so that other code
(Handlers) can react to it, usually making some change to the sending
Control as well. For example, if you click on a Button, you probably
want the Click handler to disable the button until it's ready to do its
job again. Without a reference to the sender, you can't do that - you
wouldn't know who had sent you the event.

Of course, you may not actually need all this - if the Handler is simple
enough that you don't need to ask the sender anything or do anything to
it, then fine; your second, shorter syntax will do the job nicely ...
until you add that /little/ bit of code into the Handler that /does/
need to go back to the sender ... and you have to start recompiling
everything all over the place to add the sender argument back in... ;-)

HTH,
Phill W.
Apr 18 '07 #4
On Apr 17, 3:00 pm, " active" <activeNOS...@a-znet.comwrote:
Because of a strong recommendation I saw in this NG all my events are of the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks
In addition to the other posts, what I put a number of instances in an
array and one of them raises the event. How will I know which one of
them did it?

Chris

Apr 18 '07 #5
Regarding the possible future need for knowing the sender, it's just as
likely if I 'add a little bit of code' that the class I generate
(HeightChangeEventArgs) may be insufficient and will need to be changed.

Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove

Don't I know the sender

I'm not considering not sending the sender in situations when the sender is
not apparent.

I have a few situations where a usercontol needs to advise the form that the
file path has been changed so the form can update its caption. Creating a
class to do this only complicates a simple procedure.

Would you say almost everyone follows the convention?

Guess that is my basic question.

Thanks


"Phill W." <p-.-a-.-w-a-r-d-@-o-p-e-n-.-a-c-.-u-kwrote in message
news:f0**********@south.jnrs.ja.net...
active wrote:
>Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
>I always wondered about the need for that format and figured I'd look
into it someday.
>Today I saw an advanced vb.Net book that used events like:
Public Event HeightChanged(zz As String)
>Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be.

And therein lies the crux of the argument.

How can code that you write /today/ know who or what might be throwing
this event at it at any point in the Future?

Events are most commonly raised by Controls so that other code (Handlers)
can react to it, usually making some change to the sending Control as
well. For example, if you click on a Button, you probably want the Click
handler to disable the button until it's ready to do its job again.
Without a reference to the sender, you can't do that - you wouldn't know
who had sent you the event.

Of course, you may not actually need all this - if the Handler is simple
enough that you don't need to ask the sender anything or do anything to
it, then fine; your second, shorter syntax will do the job nicely ...
until you add that /little/ bit of code into the Handler that /does/ need
to go back to the sender ... and you have to start recompiling everything
all over the place to add the sender argument back in... ;-)

HTH,
Phill W.

Apr 18 '07 #6
I would include the sender in that case.

thanks
"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@b58g2000hsg.googlegr oups.com...
On Apr 17, 3:00 pm, " active" <activeNOS...@a-znet.comwrote:
>Because of a strong recommendation I saw in this NG all my events are of
the
form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look
into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would
do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks

In addition to the other posts, what I put a number of instances in an
array and one of them raises the event. How will I know which one of
them did it?

Chris

Apr 18 '07 #7
On Apr 18, 11:51 am, " active" <activeNOS...@a-znet.comwrote:
>
Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove

Don't I know the sender
What if you had:

Handles Splitter1.MouseMove, Splitter2.MouseMove

In the MouseMove event you want to know which splitter fired the
event.

Chris

Apr 18 '07 #8
I'd include sender

I work alone and was basically wondering if most programmers follow the
convention in those cases when it is not necessary to do so. Do you think
they do.

thanks
"Chris Dunaway" <du******@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...
On Apr 18, 11:51 am, " active" <activeNOS...@a-znet.comwrote:
>>
Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove

Don't I know the sender

What if you had:

Handles Splitter1.MouseMove, Splitter2.MouseMove

In the MouseMove event you want to know which splitter fired the
event.

Chris

Apr 18 '07 #9
I'd include sender

I think what Chris is saying is what if you have

Handles Splitter1.MouseMove

And you don't add a sender because you have no need. At a later time
you decide to have it handle another another

Handles Splittle1.MouseMove, Splitter2.MouseMove

Now you must rewrite the event to account for the sender, and if you
based all the code in the event handler on Splitter1 you know must
rewrite that code to account for Splitter2. The point is, why not just
include sender in the first place and make the code more flexible from
the beginning? In my experience, no matter how much planning you do,
the original program will morph at some point during development. This
is why I try to use the most flexible coding patterns I can - a little
time now often save a lot of time later.

In summary, do what you want - If your team (which in your case is
just you) all agrees on a design pattern, then you shouldn't be afraid
to use it.

Thanks,

Seth Rowe
On Apr 18, 1:31 pm, " active" <activeNOS...@a-znet.comwrote:
I'd include sender

I work alone and was basically wondering if most programmers follow the
convention in those cases when it is not necessary to do so. Do you think
they do.

thanks

"Chris Dunaway" <dunaw...@gmail.comwrote in message

news:11**********************@l77g2000hsb.googlegr oups.com...
On Apr 18, 11:51 am, " active" <activeNOS...@a-znet.comwrote:
Regarding Sender I'm missing something. Consider:
Handles Splitter1.MouseMove
Don't I know the sender
What if you had:
Handles Splitter1.MouseMove, Splitter2.MouseMove
In the MouseMove event you want to know which splitter fired the
event.
Chris

Apr 18 '07 #10
We're focusing on Sender, and I do see the point, but it is the other
argument that I'm most interested in.

I think I was wondering if everyone else is following the convention (as I
have so far).

I put together a little example of the two ways I might go about it.

I like the second because it is simpler and less error prone, that's all.

I think anything that complicates code should be at least thought about.

Thanks for all the replies
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal e As XChangedEventArgs)

Public NotInheritable Class XChangedEventArgs
Inherits EventArgs
Private mX As Integer

Public Sub New(ByVal value As Integer)
MyBase.New()
mX = value
End Sub

Public ReadOnly Property X() As Integer
Get
X = mX
End Get
End Property
End Class

Private Sub zz()
RaiseEvent XChanged(New XChangedEventArgs(400))
End Sub
End Class
'---
Private Sub UC1_XChanged( ByVal e As UCN.UC.XChangedEventArgs) Handles
UC1.XChanged
'... use.. e.X)
End Sub

----

or

----
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal X As Integer)

Private Sub zz()
RaiseEvent XChanged(400)
End Sub
End Class
'---
Private Sub UC1_XChanged(ByVal x As Integer) Handles UC1.XChanged
'...use.. X
End Sub
Apr 18 '07 #11

" active" <ac**********@a-znet.comwrote in message
news:eu*************@TK2MSFTNGP06.phx.gbl...
We're focusing on Sender, and I do see the point, but it is the other
argument that I'm most interested in.

I think I was wondering if everyone else is following the convention (as I
have so far).

I put together a little example of the two ways I might go about it.

I like the second because it is simpler and less error prone, that's all.

I think anything that complicates code should be at least thought about.

Thanks for all the replies
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal e As XChangedEventArgs)

Public NotInheritable Class XChangedEventArgs
Inherits EventArgs
Private mX As Integer

Public Sub New(ByVal value As Integer)
MyBase.New()
mX = value
End Sub

Public ReadOnly Property X() As Integer
Get
X = mX
End Get
End Property
End Class

Private Sub zz()
RaiseEvent XChanged(New XChangedEventArgs(400))
End Sub
End Class
'---
Private Sub UC1_XChanged( ByVal e As UCN.UC.XChangedEventArgs) Handles
UC1.XChanged
'... use.. e.X)
End Sub

----

or

----
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal X As Integer)

Private Sub zz()
RaiseEvent XChanged(400)
End Sub
End Class
'---
Private Sub UC1_XChanged(ByVal x As Integer) Handles UC1.XChanged
'...use.. X
End Sub

I think your last comment is true (it should be thought about). That is the
point of the Dot.Net framework and the "standards" for using it. The
argument that while it looks simple now but just watch is so very true. As
soon as you have completed your work a requirement will come up (lets say
the UserControl is so handy that it will now be used all over the place) and
then you will be "forced" to go back to the standard method. Remember that
sending the two arguments, first the sender to indicate who's calling (and
that could be vital for debugging), and the an object containing the
information that is sent by the call is a better design since it can be
expanded upon. Look at all the objects which are derived from the standard
EventArgs and I think that is a good enough argument.

Lastly if you follow Dot.Net standards then maintenance will be so much
easier.

Just my thoughts,

Lloyd Sheen

Apr 18 '07 #12
So far it's been 5 to 0

Guess I get the point

Thanks
"Lloyd Sheen" <a@b.cwrote in message
news:1C**********************************@microsof t.com...
>
" active" <ac**********@a-znet.comwrote in message
news:eu*************@TK2MSFTNGP06.phx.gbl...
>We're focusing on Sender, and I do see the point, but it is the other
argument that I'm most interested in.

I think I was wondering if everyone else is following the convention (as
I have so far).

I put together a little example of the two ways I might go about it.

I like the second because it is simpler and less error prone, that's all.

I think anything that complicates code should be at least thought about.

Thanks for all the replies
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal e As XChangedEventArgs)

Public NotInheritable Class XChangedEventArgs
Inherits EventArgs
Private mX As Integer

Public Sub New(ByVal value As Integer)
MyBase.New()
mX = value
End Sub

Public ReadOnly Property X() As Integer
Get
X = mX
End Get
End Property
End Class

Private Sub zz()
RaiseEvent XChanged(New XChangedEventArgs(400))
End Sub
End Class
'---
Private Sub UC1_XChanged( ByVal e As UCN.UC.XChangedEventArgs) Handles
UC1.XChanged
'... use.. e.X)
End Sub

----

or

----
Public Class UC
Inherits System.Windows.Forms.UserControl

Public Event XChanged(ByVal X As Integer)

Private Sub zz()
RaiseEvent XChanged(400)
End Sub
End Class
'---
Private Sub UC1_XChanged(ByVal x As Integer) Handles UC1.XChanged
'...use.. X
End Sub


I think your last comment is true (it should be thought about). That is
the point of the Dot.Net framework and the "standards" for using it. The
argument that while it looks simple now but just watch is so very true.
As soon as you have completed your work a requirement will come up (lets
say the UserControl is so handy that it will now be used all over the
place) and then you will be "forced" to go back to the standard method.
Remember that sending the two arguments, first the sender to indicate
who's calling (and that could be vital for debugging), and the an object
containing the information that is sent by the call is a better design
since it can be expanded upon. Look at all the objects which are derived
from the standard EventArgs and I think that is a good enough argument.

Lastly if you follow Dot.Net standards then maintenance will be so much
easier.

Just my thoughts,

Lloyd Sheen

Apr 18 '07 #13
active,
In addition to the other comments:

I follow the convention religiously; This ensures that my predecessors will
understand my code (as it follows the convention set forth in the framework)
also it allows VB to create smaller assemblies with fewer types. Fewer types
mean the assembly will load quicker & have a smaller memory usage...
(smaller memory usage as there are fewer types loaded).

To gain a smaller assembly I define the events based on an EventHandler:

Rather then:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)
In .Net 1.x I use:

Public Event HeightChanged As HeightChangedEventHandler

Where HeightChangedEventHandler is defined as:

Public Delegate Sub HeightChangedEventHandler(ByVal sender As Object,
ByVal e As
HeightChangeEventArgs)

In .NET 2.0 I use:

Public Event HeightChanged As EventHandler(Of HeightChangeEventArgs)

Using the "As EventHandler..." creates smaller assemblies as your syntax
causes the VB compiler to create a hidden EventHandler type for each event
you define. Using "As EventHandler..." causes VB to use either
System.EventHandler or System.EventHandler(Of T) types.

If you use Object Browser to look at the various *EventArgs types in the
Framework you will notice an accompanying *EventHandler delegate that goes
with it.

As part of Orcas (the next version of VS.NET currently in beta 1) we gain
Relaxed Delegates:

http://blogs.msdn.com/vbteam/archive...-the-wild.aspx

Which among other things allow you to define your handler without any
parameters, while the event itself includes parameters. Relaxed Delegates
also allow

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
" active" <ac**********@a-znet.comwrote in message
news:eG**************@TK2MSFTNGP02.phx.gbl...
Because of a strong recommendation I saw in this NG all my events are of
the form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look into
it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks



Apr 23 '07 #14
I look forward to your tutorial-like comments since they instill an
understanding of the subject.

Thanks

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.netwrote in
message news:OO**************@TK2MSFTNGP05.phx.gbl...
active,
In addition to the other comments:

I follow the convention religiously; This ensures that my predecessors
will understand my code (as it follows the convention set forth in the
framework) also it allows VB to create smaller assemblies with fewer
types. Fewer types mean the assembly will load quicker & have a smaller
memory usage... (smaller memory usage as there are fewer types loaded).

To gain a smaller assembly I define the events based on an EventHandler:

Rather then:
>Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

In .Net 1.x I use:

Public Event HeightChanged As HeightChangedEventHandler

Where HeightChangedEventHandler is defined as:

Public Delegate Sub HeightChangedEventHandler(ByVal sender As Object,
ByVal e As
HeightChangeEventArgs)

In .NET 2.0 I use:

Public Event HeightChanged As EventHandler(Of HeightChangeEventArgs)

Using the "As EventHandler..." creates smaller assemblies as your syntax
causes the VB compiler to create a hidden EventHandler type for each event
you define. Using "As EventHandler..." causes VB to use either
System.EventHandler or System.EventHandler(Of T) types.

If you use Object Browser to look at the various *EventArgs types in the
Framework you will notice an accompanying *EventHandler delegate that goes
with it.

As part of Orcas (the next version of VS.NET currently in beta 1) we gain
Relaxed Delegates:

http://blogs.msdn.com/vbteam/archive...-the-wild.aspx

Which among other things allow you to define your handler without any
parameters, while the event itself includes parameters. Relaxed Delegates
also allow

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
" active" <ac**********@a-znet.comwrote in message
news:eG**************@TK2MSFTNGP02.phx.gbl...
>Because of a strong recommendation I saw in this NG all my events are of
the form:
Public Event HeightChanged(ByVal sender As Object, ByVal e As
HeightChangeEventArgs)

where:

Public NotInheritable Class HeightChangeEventArgs

Inherits EventArgs

...

I always wondered about the need for that format and figured I'd look
into it someday.

Today I saw an advanced vb.Net book that used events like:

Public Event HeightChanged(zz As String)

Is there any reason to prefer the first form over the second? After all I
define other methods with any signature that I like. I can think of no
reason to send Sender if the consumer knows a head of time who the sender
must be. And more importantly, having to maintain a class when String
would do.

I'd appreciate any comments relating to this.

In particular, do you always follow the stated convention?

Thanks




Apr 23 '07 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Eddy Bee | last post by:
Hi there, I'm encountering an inexplicable problem with page formatting in reports. Here's the easiest way to explain it: The Detail section of my report contains two elements: And let's...
3
by: Melissa | last post by:
What specifically causes the Format event of a report's section to fire? Thanks! Melissa
3
by: michael.lang | last post by:
I am using PostBuild events in a C# project to run some tasks, but only when in release configuration mode. The build events run perfectly as expected when run. The problem comes when I save the...
4
by: Liverpool fan | last post by:
I have a windows application written using VB .NET that encompasses a countdown timer modal dialog. The timer is a System.Timers.Timer with an interval of 1 second. AutoReset is not set so accepts...
14
by: teddysnips | last post by:
WINDOWS FORMS I've a form that has a textbox that allows the user to enter a string. On the LostFocus event, the textbox formats the string into a preferred format. However, if the user...
6
by: =?Utf-8?B?UHVjY2E=?= | last post by:
Hi, I'm using vs2005 and .net 2.0. I currently prcoess each Security Log entry one by one to extract those that fit the selection criteria. Is there a function that I can use to query the entries...
2
by: sorobor | last post by:
dear sir .. i am using cakephp freamwork ..By the way i m begener in php and javascript .. My probs r bellow I made a javascript calender ..there is a close button ..when i press close button...
0
by: ppardi | last post by:
I'm developing an addin for Word 2007 and I need to determine whether a user saves a Word 2007 document in an older format (97-2003) after a save as is done. The scenario is that the user starts...
3
by: franc sutherland | last post by:
Hello, I have a report which I filter using the me.filter command in the OnOpen event. Me.Filter = "OrderID=" & Forms!variable_form_name! Me.FilterOn = True I want to be able to open that...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.