|
If it is not break-en, don't switch it?
[[Thank you, I'm here all week; try the veal...]]
Chaos.
|
|
|
|
|
well, switch is shorthand for the if--then--else construct.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
They forgot the default clause!  
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
With "simple" booleans, a switch statement is not necessary. But what about "extended" boolenas (i.e. true, false, don_t_know, FILE_NOT_FOUND)? That's where a switch comes in very handy.
|
|
|
|
|
Ever tried to create a generic class which accepts Enum types only? Can be fun!
I have a non-generic class EnumDescConverter and wanted to add a generic version EnumDescConverter<T>. Easy, isn't it? Just write
public class EnumDescConverter<T> : EnumDescConverter where T : Enum
and the error is
Constraint cannot be special class 'System.Enum'
Well, you have to use a different approach. An Enum is a struct which implements IConvertible. Hence you can do
public class EnumDescConverter<T> : EnumDescConverter where T : struct, IConvertible
and then check in the constructor that T is really an enum: if (!enumType.IsEnum) { throw ...}
And now let's do more bad things. 
The non-generic class has a function
public Enum GetEnumValue(string description)
Let's add a generic version in the generic class so that we do not need to cast the return value to the type of the enum in use:
public T GetEnumValue(string description)
And the warning is:
warning CS0108: 'EnumDescConverter<T>.GetEnumValue(string)' hides inherited member 'EnumDescConverter.GetEnumValue(string)'. Use the new keyword if hiding was intended.
A possible solution, but not nice.
If you make the method in the base class virtual, and override it in the generic class, the error is:
'EnumDescConverter<T>.GetEnumValue(string)': return type must be 'System.Enum' to match overridden member 'EnumDescConverter.GetEnumValue(string)'
Hm. Let me change the name of the function, and in its body just call the base class' method and cast the return value (not a nice solution either):
public T GetEnumValueT(string description)
{
return (T)GetEnumValue(description);
}
And the next error arises:
Cannot convert type 'System.Enum' to 'T'
Of course,
return GetEnumValue(description) as T;
doesn't work either because an Enum is not a class:
The type parameter 'T' cannot be used with the 'as' operator because it does not have a class type constraint nor a 'class' constraint
But the problem can be solved by a double-cast:
return (T)((object)GetEnumValue(description));
That's Weird and Wonderful, isn't it? 
|
|
|
|
|
 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
A joke, I know, but that's just crazy! 
You have just been Sharapova'd.
|
|
|
|
|
Fody can do that[^]
The fact that you need a third party IL manipulation library to do this is still a WTF though.
Edit: damn autoincorrect.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
Fody is very powerful. I don't use it, but I have a few places that it might be of help.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
Apart from combining / testing Flags values, when does it ever make sense to perform mathematical operations on Enum values?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Just wait until you need to.
|
|
|
|
|
If you ever need to then the much higher priority should be to refactor that bit of code so that you use something more appropriate.
The actual value applied to an enumeration should never be relied upon to remain the same between versions of the code and so the result of any maths operation performed on it should be considered unreliable.
|
|
|
|
|
In your last method, beside being awkward, you are boxing & unboxing the value. Which probably increase the time that method takes to run by at least one order of magnitude.
A way to avoid this is to take advantage of something we already know... enums are IConvertible.
void Main()
{
var b = new EnumDescConverter<Nums>();
b.GetEnumValueT("Dummy desc").Dump();
}
enum nums {zero, one, two, three};
enum Nums {Zero, One, Two, Three};
class EnumDescConverter
{
protected IConvertible GetEnumValue(string description) {return nums.one; }
}
class EnumDescConverter<T> : EnumDescConverter
where T : struct, IConvertible
{
public T GetEnumValueT(string description) { return (T) GetEnumValue(description);}
}
P.S. http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2557231-enums-constraint-for-generics[^]
Truth,
James
|
|
|
|
|
With WPF, you can set the NotifyOnValidationError property of some elements to true and add an error handler, e.g. Validation.AddErrorHandler(textID, ItemError);.
Starting from a vaild state, you type some nonsense into the textbox, and you receive the event with e.Action = ValidationErrorEventAction.Added. That's what we should expect.
But what happens if you type more nonsense into the textbox?
Well, you receive another vaildation error with e.Action = ValidationErrorEventAction.Added. Hm, OK, validation failed again, and the error might be different.
But now comes the WTF: immediately afterwards, you receive another such event, but now with e.Action = ValidationErrorEventAction.Removed! Yes, "Removed". Everything OK now? Can't be true, there's garbage in the textbox, not valid value.
I changed my validator to include the text of the textbox. And voila: in the "Added" event, the current text is shown;, in the "Removed" event, the previous text.
By the way, in .Net 3.5 the behavior was the other way round (first remove the previous error, then add the new error), see e.g. validationerror-giving-strange-behavior[^]
|
|
|
|
|
And that wasn't listed as a breaking change. Wow, M$, you seriously f***** that one up.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
You are right. But I want to make the programs fool-proof when they are intended for my own use: I know my tyipng bheavior.
|
|
|
|
|
Tip; turn of your spellchecker.
I've seen more errors in recent "spell checked" documents than in old unchecked versions. I think that the spellcheckers are causing them, instead of preventing.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Or the Autocowreck (AKA Autoincorrect)
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I agree and don't.
Input-validation is a nice thing, if it is generated; especially cool for banknumbers and social security-numbers, things where I tend to make mistakes. Most of the validations CAN be generated, so why aren't they?
It is not something that one should blindly spend money on; in that case it will simply cost money, often without knowing the return-on-investment of the effort - how many errors did it actually prevent, and at what cost?
No, it is more valuable to invest time and think about what errors you want to prevent. One of the things often omitted is the check for duplicate records - many places use identity-fields simply to not have to worry about a primary key-field.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Looking at the comments[^], the change was made to avoid "a transient 'no error' state". 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's a good point. Their reason is totally valid. But their solution is NOT.
When an error has to be replaced by a different error, the system is in an invalid state when only one of the two steps of adding the new error and removing the old error has been completed. Two errors on the field are as wrong as no error on it. It's similar to transferring money from one bank account to another bank account: do not create or loose money by omitting one step. A solution could be a transaction.
But I think the simplest solution here is similar to a PropertyChanged event. Get rid of the Added/Removed enum, and take two error properties: OldError and NewError.
When you leave the valid state, NewError contains the error which is now communicated with Added, and OldError is null.
When an error gets replaced by a different error, NewError contains the freshly incurred error (now with Added), and OldError the previously encountered error (now with Removed).
When you return to a valid state, NewError is null, and OldError the previously encountered error (now with Removed).
That's a better solution, isn't it?
|
|
|
|
|
That would be a better solution. Now you just need to convince Microsoft to adopt it! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
