According to the CLS specification, the accessibility of the methods for
adding, removing, and raising an event must be identical. There appear to be
a few problems with this:
1) According to the Managed C++ specifications, if one declares a public
event without any attempt to provide one's own event access methods, clearly
the most common case, the compiler generates public add_ and remove_ methods
for the event and a protected raise_ method for the event. This appears to
contradict CLS guideleines for the event and make events declared in MC++
non-compliant with the CLS specification.
2) If I provide my own event member methods signature for the event, I might
want to allow any code to add or remove event handlers for the event, the
common case, while restricting the ability to raise the event to classes in
my own assembly. I can do this by specifying that the accessibility for the
event add_ and remove_ remove methods be made public while the accessibility
for the raise_ method is made public private. If I do this, once again I am
not complying to the CLS specification.
Clearly not complying to the CLS specification will not allow my class to be
used by other .NET languages, which is something which I don't want. However
being able to control which classes are allowed to raise a particular
class's event seems to be a common idiom in computer programming. I know
that .NET makes a big deal about only the class which contains the event
being able to raise the event, but it is clear that designs may call for
other classes being able to raise the event also. This may not have been a
big deal for C++ programmers if the 'friend' functionality were allowed in
the MC++ specification, but it is not. Luckily the concept of assembly
classes having access priveleges which classes outside the assembly do not
have, was added to MC++ specification. However, the CLS guidelines for event
methods having equal accessibility makes it impossible to vary the
accessibility of event methods. Hopefully someone understands this issue and
knows of a way out of this conundrum.
3  1956 
Further down in the CIL standard, raise_XXX pattern is defined as:
Pattern: void family raise_<EventNam e> (Event e)
family is what protected in C++ & C# is, just the cil name. I *think*,
although I can't find a definitive source, that the raise_ method is not an
accessor per se, whereas add and remove are. It isn't very clearly written.
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eO******** ********@TK2MSF TNGP11.phx.gbl. .. According to the CLS specification, the accessibility of the methods for
adding, removing, and raising an event must be identical. There appear to
be a few problems with this:
1) According to the Managed C++ specifications, if one declares a public
event without any attempt to provide one's own event access methods,
clearly the most common case, the compiler generates public add_ and remove_
methods for the event and a protected raise_ method for the event. This appears to
contradict CLS guideleines for the event and make events declared in MC++
non-compliant with the CLS specification.
2) If I provide my own event member methods signature for the event, I
might want to allow any code to add or remove event handlers for the event, the
common case, while restricting the ability to raise the event to classes
in my own assembly. I can do this by specifying that the accessibility for
the event add_ and remove_ remove methods be made public while the
accessibility for the raise_ method is made public private. If I do this, once again I
am not complying to the CLS specification.
Clearly not complying to the CLS specification will not allow my class to
be used by other .NET languages, which is something which I don't want.
However being able to control which classes are allowed to raise a particular
class's event seems to be a common idiom in computer programming. I know
that .NET makes a big deal about only the class which contains the event
being able to raise the event, but it is clear that designs may call for
other classes being able to raise the event also. This may not have been a
big deal for C++ programmers if the 'friend' functionality were allowed in
the MC++ specification, but it is not. Luckily the concept of assembly
classes having access priveleges which classes outside the assembly do not
have, was added to MC++ specification. However, the CLS guidelines for
event methods having equal accessibility makes it impossible to vary the
accessibility of event methods. Hopefully someone understands this issue
and knows of a way out of this conundrum.
Daniel O'Connell wrote: Further down in the CIL standard, raise_XXX pattern is defined as:
Pattern: void family raise_<EventNam e> (Event e)
family is what protected in C++ & C# is, just the cil name. I *think*,
although I can't find a definitive source, that the raise_ method is
not an accessor per se, whereas add and remove are. It isn't very
clearly written.
No, it isn't. Especially when it does clearly state in the CLS specification
topic on MSDN that the accessor accessibility for "adding, removing, and
raising an event must be identical." Could this be wrong, and it is only the
"adding and removing" which must have identical accessibility ? Because if
it is correct, every MC++ program which uses the normal "__event
SomeDelegate * eventName;" or "__event returnType
eventName(event Parameters);" is CLS non-compliant, since it generates the
add and remove methods as public and the raise method as protected.
Perhaps MS has clarified this somewhere, but I could not find anything
further on it on their web site. It is scary to think that, according to the
MSDN doc, all MC++ modules which use events are non-compliant with the CLS
and therefore can not be used interchangeably with other .NET languages. I
am sure this can not be the case but the CLS compliant documentation is
clearly saying that it is.
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eO******** ********@TK2MSF TNGP11.phx.gbl. .. According to the CLS specification, the accessibility of the methods
for adding, removing, and raising an event must be identical. There
appear to be a few problems with this:
1) According to the Managed C++ specifications, if one declares a
public event without any attempt to provide one's own event access
methods, clearly the most common case, the compiler generates public
add_ and remove_ methods for the event and a protected raise_ method
for the event. This appears to contradict CLS guideleines for the
event and make events declared in MC++ non-compliant with the CLS
specification.
2) If I provide my own event member methods signature for the event,
I might want to allow any code to add or remove event handlers for
the event, the common case, while restricting the ability to raise
the event to classes in my own assembly. I can do this by specifying
that the accessibility for the event add_ and remove_ remove methods
be made public while the accessibility for the raise_ method is made
public private. If I do this, once again I am not complying to the
CLS specification.
Clearly not complying to the CLS specification will not allow my
class to be used by other .NET languages, which is something which I
don't want. However being able to control which classes are allowed
to raise a particular class's event seems to be a common idiom in
computer programming. I know that .NET makes a big deal about only
the class which contains the event being able to raise the event,
but it is clear that designs may call for other classes being able
to raise the event also. This may not have been a big deal for C++
programmers if the 'friend' functionality were allowed in the MC++
specification, but it is not. Luckily the concept of assembly
classes having access priveleges which classes outside the assembly
do not have, was added to MC++ specification. However, the CLS
guidelines for event methods having equal accessibility makes it
impossible to vary the accessibility of event methods. Hopefully
someone understands this issue and knows of a way out of this
conundrum.
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Daniel O'Connell wrote: Further down in the CIL standard, raise_XXX pattern is defined as:
Pattern: void family raise_<EventNam e> (Event e)
family is what protected in C++ & C# is, just the cil name. I *think*,
although I can't find a definitive source, that the raise_ method is
not an accessor per se, whereas add and remove are. It isn't very
clearly written.
No, it isn't. Especially when it does clearly state in the CLS
specification topic on MSDN that the accessor accessibility for "adding, removing, and
raising an event must be identical." Could this be wrong, and it is only
the "adding and removing" which must have identical accessibility ? Because if
it is correct, every MC++ program which uses the normal "__event
SomeDelegate * eventName;" or "__event returnType
eventName(event Parameters);" is CLS non-compliant, since it generates the
add and remove methods as public and the raise method as protected.
I couldn't find this information, I used the ECMA spec, do you have a
reference? In languages like C#, the raise_ method doesn't appear to be
there most of the time(at all?), that and the ECMA spec showing a family
modifer suggests to me that there is a problem with the MSDN documentation. Perhaps MS has clarified this somewhere, but I could not find anything
further on it on their web site. It is scary to think that, according to
the MSDN doc, all MC++ modules which use events are non-compliant with the CLS
and therefore can not be used interchangeably with other .NET languages. I
am sure this can not be the case but the CLS compliant documentation is
clearly saying that it is.
I wouldn't worry about it much. I prefer to use protected raiser
methods(like OnMyEvent) instead of allowing inheriters to directly access
the event. So I find this to probably not be of much issue if you follow a
similar pattern. In the framework, most events are fired by the base OnXXX
method, which is why you should almost always call the base implementation.
"Edward Diener" <ed******@tropi csoft.com> wrote in message
news:eO******** ********@TK2MSF TNGP11.phx.gbl. .. According to the CLS specification, the accessibility of the methods
for adding, removing, and raising an event must be identical. There
appear to be a few problems with this:
1) According to the Managed C++ specifications, if one declares a
public event without any attempt to provide one's own event access
methods, clearly the most common case, the compiler generates public
add_ and remove_ methods for the event and a protected raise_ method
for the event. This appears to contradict CLS guideleines for the
event and make events declared in MC++ non-compliant with the CLS
specification.
2) If I provide my own event member methods signature for the event,
I might want to allow any code to add or remove event handlers for
the event, the common case, while restricting the ability to raise
the event to classes in my own assembly. I can do this by specifying
that the accessibility for the event add_ and remove_ remove methods
be made public while the accessibility for the raise_ method is made
public private. If I do this, once again I am not complying to the
CLS specification.
Clearly not complying to the CLS specification will not allow my
class to be used by other .NET languages, which is something which I
don't want. However being able to control which classes are allowed
to raise a particular class's event seems to be a common idiom in
computer programming. I know that .NET makes a big deal about only
the class which contains the event being able to raise the event,
but it is clear that designs may call for other classes being able
to raise the event also. This may not have been a big deal for C++
programmers if the 'friend' functionality were allowed in the MC++
specification, but it is not. Luckily the concept of assembly
classes having access priveleges which classes outside the assembly
do not have, was added to MC++ specification. However, the CLS
guidelines for event methods having equal accessibility makes it
impossible to vary the accessibility of event methods. Hopefully
someone understands this issue and knows of a way out of this
conundrum.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: news.btinternnet.com |
last post by:
I can do this in IE
myLink.click(); //Invoking the handler as if the user had clicked on the
link themselves.
I need to be able to do the same in Netscape Navigator,
can anyone help ?
|
by: Marinos Christoforou |
last post by:
Sorry if this has been asked before but as an inexperienced wanna-be C#
programmer I wondering how to code classes to help build a standard Windows
UI.
For example to build a common toolbar. I would call a method from the class
in the load event of my varioius windows forms, to create the toolbar, add
buttons to it and set various properties as required. This is fine but I am
at a loss as to how to expose the toolbar's various events...
|
by: z_learning_tester |
last post by:
Hello,
I am new to C# and have a quick question.
Any replies much appreciated ;-)
It is regarding static methods...
Are they public by default?
I mean it seems like for them to be usable, they have to be public right?
EG. Below you can't call the method by saying Point.ObjectCount() unless
ObjectCount is public right? So this call would fail ?
|
by: paccala |
last post by:
Ciao
Being google-ing since hours and still I'm not able to
solve my problem...
I have following hierarchy:
class A
{
public void myMethod();
}
|
by: waltborders |
last post by:
Hi,
Because the blind are unable to use a mouse, keyboard navigation is
key. A major difficulty is that not all windows forms controls are
keyboard 'tab-able' or 'arrow-able' or have "tab order".
The application is built and the next step is to create the custom JAWS
(Freedom Scientific)screen reader script to read the application. The
application uses the accessibility properties for controls provided by
C#. JAWS reads properties...
| | |
by: BC |
last post by:
Hi all,
Just wondering what are the difference between:
public event EventHandler MessageNotify;
public EventHandler MessageNotify;
A friend told me it's related to the accessibility levels.
|
by: shland |
last post by:
This is related to my previous post on "fire click event from serverside
code?"
Alternately, is there a way to intercept a click event on a control from a
referenced .dll, and do some pre-processing prior to allowing the click
event processing to occur in the .dll?
Background - I'm using a button control from a .dll for which I do not have
source code, and before the .dll processes the button click, I want to save
information entered...
|
by: I am Sam |
last post by:
Please help. I'm dying here and pulling out the last few remaining elements
of my hair over this.
I have built a form that will identify and authenticate users. I keep
getting the following error with the Form:
Compiler Error Message: CS0122:
'Sonar3.Controls.LoginControl.Button_Click(object, System.EventArgs)' is
inaccessible due to its protection level
|
by: =?Utf-8?B?TkVXMi5ORVQ=?= |
last post by:
I have a static event declared in a C++ ref class, that can then be handled
in a VB app. I'm trying to expose the static event through the interface
that the C++ ref class implements so the VB app can use the interface as
preferred. How do you expose a static event through an interface?
In the example below as coded, in a VB app I can access and use the general
method (MyMethod) if I declare my handle variable as an IMyInterface type....
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
