|
harold aptroot wrote: No, see here: http://msdn.microsoft.com/en-us/library/b873y76a%28VS.80%29.aspx[^]
Well, I can't say, the f***in page is stuck on C++
PS: IIRC C++ does not support .NET params .
Update:
IE to the rescue. I see it was there (in 2.0), maybe I am thinking of something else...
|
|
|
|
|
I don't know what else you could be thinking of - you were talking about the params overload for .NET 2.0 right?
|
|
|
|
|
This is what I have seen years ago.
a.ToString().ToString();
Yeah... he was just tired... couldn't prevent a prank by Intellisence.
|
|
|
|
|
The one I loathe is
string s = "Hello";
string x = s.ToString();
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
or even ".".ToString();
Two heads are better than one.
|
|
|
|
|
What happened to your post titled "BitVector32 vs BitArray ???" in this forums? Did you delete it?
|
|
|
|
|
Sorry.
I deleted it because it could be a mere slander.
|
|
|
|
|
Who cares, we don't know the author anyway
|
|
|
|
|
problem:
why "i don't rember exactly the hard coded string".ToString.ToUpper(); ?
answer: I just hate writting using caps.
Concluzion: I'm sure he/she had his reasons.
I bug
|
|
|
|
|
Private Sub textBox1_KeyPress(ByVal eventSender As System.Object, ByVal eventArgs As System.Windows.Forms.KeyPressEventArgs) Handles textBox1.KeyPress
Dim KeyAscii As Short = Asc(eventArgs.KeyChar)
Dim Index As Short = textBox1.GetIndex(eventSender)
If InStr("ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" & Chr(8), Chr(KeyAscii)) > 0 Or KeyAscii < 32 Then
Else
KeyAscii = 0
Beep()
End If
eventArgs.KeyChar = Chr(KeyAscii)
If KeyAscii = 0 Then
eventArgs.Handled = True
End If
End Sub
Getting sick of these kind of codeblocks ...
oh yeah, remember Char(8) is a backspace
If anyone knows why he might have written this line :
Dim Index As Short = textBox1.GetIndex(eventSender)
I have no clue ...
|
|
|
|
|
ddecoy wrote: I have no clue ...
Welcome to my world...
-NP
Never underestimate the creativity of the end-user.
|
|
|
|
|
The best line in this function is Beep()!
|
|
|
|
|
We aren't in the Lounge now - no need to censor your language...
Did you know:
That by counting the rings on a tree trunk, you can tell how many other trees it has slept with.
|
|
|
|
|
The code isn't testing for alphanumeric--just alphabetic. That having been said, I don't see anything overly hideous. I would expect VB to recognize the string with the letters and backspace as a constant, so the code simply searches for an input character in a constant string. Not gorgeous (using a named constant called AllowableKeys or something would help), but the list of allowable characters can be easily adjusted by changing the string. If upper and lower case are going to be handled identically elsewhere, it might have been nice to convert to uppercase and just check against uppercase letters.
As for my own style, if I were just checking against one contiguous range of characters, I'd use the >= and <= to check the range. With two ranges, or one range plus one or two other characters, I'd still probably use those. With more than that, I'd likely just search in a string with all valid characters.
|
|
|
|
|
supercat9 wrote: The code isn't testing for alphanumeric--just alphabetic
Yes, Alfabetic I meant, and don't forget the backspace
|
|
|
|
|
This looks like it was converted from an old dialect of Basic. The only thing I see as "odd" is the & Chr(8) , since the check for < 32 would catch all the common Ctl chars, including Bksp , anyway. But my guess is that it was converted and modified a couple of time to end up with that.
The Dim Index As Short = textBox1.GetIndex(eventSender) line looks like something left over from a previous mod or from some debugging effort. It doesn't look like Index is used at all.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
I have no idea what he locks in this C# code.
lock (path)
{
if (File.Exists(path))
{
File.Delete(path);
}
}
|
|
|
|
|
Just in case, you know.
|
|
|
|
|
Maybe he was afraid that someone/something (like Windows, CLR or even God) would change his path containing local string before he got to delete the file.
Does that count as paranoia?
I have no smart signature yet...
|
|
|
|
|
Don't laugh with the guy! Maybe he is just a visionary protecting his code in the event of time travel.
|
|
|
|
|
He probably thought it was to 'lock' the file, so that someone else won't be able to get a handle to the file.
|
|
|
|
|
|
It is possible, I suppose, that path was originally an instance variable and this was subsequently refactored to make it local to the method. That would explain it, if someone just didn't bother removing the lock on path when they did the refactoring.
It's also possible, of course, that whoever wrote it just didn't understand lock.
|
|
|
|
|
lock doesn't care whether it's an instance or local variable. It's locking the object, not the variable.
As strings with the same content might or might not be shared by the .NET runtime (depending on how the strings were created, .NET version, compilation options, etc.), no one can ever know what exactly that code was locking. But even if that originally was an instance variable, the original code would have been incorrect.
David Skelly wrote:
It's also possible, of course, that whoever wrote it just didn't understand lock.
That's the only possible explanation.
|
|
|
|
|
Daniel Grunwald wrote: That's the only possible explanation.
I'm amazed at how many people seem to think that the way to avoid problems with concurrent access to an object is to arbitrarily pick something kinda-sorta related to that object and lock it. They see all the warnings about the risks of locking publicly-available objects and try to avoid doing that, despite the fact that if a lock must be held between calls to an objects methods or properties, it must be publicly available. To be sure, it's often best if things can be arranged so a lock needn't/won't be held while running 'outside' code, but when it's necessary one shouldn't try to avoid exposing the lock.
|
|
|
|