|
Good to know that I am not out of my mind 
|
|
|
|
|
|
That is a really good article.
Thanks.
I really just wanted to make sure that I was not just following some standard that most other people thought was a waste of time.
|
|
|
|
|
You are welcome
|
|
|
|
|
This is the right way to pass information to an event handler. There are a lot of benefits to this approach, but the biggest ones are that if you need to add/change the data passed to the event you can do so without changing the event interface (which would break existing code). The only time this doesn't work well is when you change from using System.EventArgs to a custom event args class, but even that is a minor change.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Yeah, I know 
It's just a lot of repetitive work creating simple inherited eventargs classes just to send a simple text message back
Don't get me wrong, I always do it that way and see the value in it. I just recently have had to go through and create a bunch of classes that used really simple event arguments and was having a little 'crisis of faith' over seeing a ton of really simple EventAargs classes, one for each event.
I initially thought about just creating a simple BasicMessageTypeEventArgs class and using that on multiple events but tossed that out the window as a bad idea just in case I ever needed to extend one event over the others...
Thanks.
|
|
|
|
|
You could always create a generic event args class EventArgs<T> where T is the single data element you want. This does tend to break down a bit when you want multiple data elements, but it's good for a single one without needing to create a bunch of classes that are duplicates of each other except for the property name.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
As the others said, that's the "correct" way.
Along with the benefits already mentioned, is that the custom class can/should implement its own ToString which can add more detail than the string it contains.
I'd give an example, but I won't degrade myself by writing VB. 
|
|
|
|
|
Hi Folks,
While i use Keywords in any code written manually, and Type names in any code generators i use, i have a junior who insists on using the underlying Type name regardless of whether there is a keyword for it or not.
I'd like to stop him doing this, but i don't have the benefits straight in my head. The only reason i can think of is that int would be different on different platforms, but what effect does it have with strings?
Cheers
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: I'd like to stop him doing this
Wanna see how fast he can stop? Fire him for not following company coding standard. 
These aren't neccessarily keywords, but aliases. int (C#) or Integer (VB.NET) is just an alias for System.Int32. I can't remember if they change to 64-bit integers on 64-bit machines or not.
But, with strings, there is no difference at all. string or String is just an alias for System.String. There's no difference at all between using it on 32-bit or 64-bit machines.
|
|
|
|
|
You really have a problem if you are so obsessed with stopping people from doing things their way that you go searching online for excuses.
As you point out yourself, there's no difference, so how about you just let this poor guy (who has to have a boss who spends his time trying to PREVENT him from working the way that works best for him) get on with his work and get the hell out of his way!?
|
|
|
|
|
What ever gave you the impression i was obsessed? I just asked what the mechanical differences were between types and keywords so i could set up a standard on it. I take it you haven't worked anywhere with no code policy and jumbled standards?
I suppose i could be being a bit pedantic asking for proper disposal and that they not use variable names like textBox1, etc.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: not use variable names like textBox1
Well, in my class I teach, I take away points for using variable names like that. Trying to teach people to adopt some kind of decent coding standard.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Dave Kreskowiak wrote: I can't remember if they change to 64-bit integers on 64-bit machines or not.
Nope. Integers are always 32-bits in C#, which I found strange. The C# Language Specification is pretty explicit about it. "The int type represents signed 32-bit integers with values between –2147483648 and 2147483647." Period.
In C/C++, an int was intended to be the "natural" word size of the processor. In Intel x86 processors using DOS, an int was 16 bit. In Win32 and Linux, an int is 32 bits. There were even 24-bit systems where int was defined as 24 bits.
Enjoy,
Robert C. Cartaino
|
|
|
|
|
I remember the C++ types automatically sizing to the proc's width, but I couldn't remember if C#'s int and VB.NET's Integer remapped themselves to System.Int64. I didn't think it did, but I also don't have a 64-bit machine to test with either. 
|
|
|
|
|
Robert.C.Cartaino wrote: In C/C++, an int was intended to be the "natural" word size of the processor.
And I've seen so many cases where developers have written code making assumptions about the size of the data type only to find that their code breaks when they move to 64 bit servers. Standardising on types was part of the remit of the CLR team, so .NET code written for 32 bit would work on 64 bit as well.
|
|
|
|
|
I don't really like the aliases, in my opinion their primary use is to save keystrokes*, but I use them.
One of the odd things about them is that they're required for enumerations:
enum ThisEnum : int ...
enum ThatEnum : System.Int32 ...
And I seem to recall that there are situations where you can't use them, but I could be wrong about that.
* More importantly, they can ease the conversion of C/C++ code to C#, but how many people do that?
|
|
|
|
|
Trying to communicate with a java webservice that utilizes SwA instead of MTOM which is standard in Web Enhancments. Could anyone please tell me how I can do a SwA message in .NET?
|
|
|
|
|
Hi
(This is my first web service project so please point out if I've made any fundamental mistakes here.)
I have a problem using WCF .NET 3.5 VS2008 trying to create a c# client app that interacts with a 3rd party web service that uses SWA.
I have found that WCF .NET 3.5 does not support SWA. SWA was available as part of Web Services Enhancements (WSE) 3.0 for Microsoft® .NET VS2005 but WSE has not been updated for .NET 3.5 VS2008
The 3rd party web service wsdl is incompatible with wsdl.exe from .NET 3.0 so I cannot use VS2005 / .NET 3.0
I can create a service reference in VS2008 but it ignores the SWA (I think by design).
I think I have 2 choices - read up on wsdl so that I can modify the wsdl to be compatible with the VS2005 environment, or find a way to support SWA in VS2008.
Is this same as your problem?
Does anyone know of a solution for SWA with VS2008 .NET 3.5?
Thanks
A
|
|
|
|
|
Or will it freeze the application a little when doing garbage collection?
system
|
|
|
|
|
The GC will still freeze your application's main thread (and any child threads). Due to the way the GC works, this behavior will never change. It freezes the threads so it can "walk" the heap looking for reachable objects. If your application were still running, the GC would always be chasing it's tail and never be able to make any decisions.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
So can I disable auto garbage collection?
system
|
|
|
|
|
No. It's part of the .NET runtime itself and there is no way to turn it on or off.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Why would you want to? Seriously, why? This is the mechanism by which memory is reclaimed for your application. Do you really want your application to start leaking memory? To me, GC was one of the great features of .NET, and was an absolute godsend for me - coming from a C++ background, where you had to be so careful of how memory was allocated and freed, it's a relief to let the framework take care of this for me.
|
|
|
|
|
I agree with you. Gabage collection is really good.
When I used shared_ptr the first time, I can see how much it can clarify the code.
I know it can work well in .Net, but I just don't like the way it works (searching, freezing).
Does it have something better than garbage collection in real life?
Is the garbage in the bin useable in .Net? If not, why not clear it as soon as possible?
system
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
