Click here to Skip to main content

Comments by Luc Pattyn (Top 68 by date)

Luc Pattyn at 3-Mar-12 9:35am View
   
Reason for my vote of 3
Hmm. I had to read the code several times before I could guess what this was about. Some more explanation would be welcome.
 
I do have two comments:
 
1. a case-insensitive string compare is better handled by string.Compare, the code shown creates two new objects nobody really wants.
 
2. Some file systems are case-sensitive (typically UNIX based ones), so if you mount one of them and map them to a drive letter, a copy operation such as COPY abc.txt ABC.txt will silently be swallowed by your code??
 
:)
Luc Pattyn at 28-Jan-12 7:46am View
   
Deleted
WTF.
plagiarism + bizarre title + image not showing + wrong tag + ...
Luc Pattyn at 11-Jan-12 3:34am View
   
Deleted
Actually I'm not surprised other alternatives are faster; it is all about how often the string is scanned, and my compact approach scans thrice: Length, Replace(=copy), Length.
 
Your original code is bound to be the fastest as it scans only once, and does so at the lowest level, i.e. inside IndexOf, which I trust is doing a good job at it.
 
:)
Luc Pattyn at 4-Jan-12 15:58pm View
   
Deleted
Neat!
 
:)
Luc Pattyn at 28-Nov-11 4:54am View
   
Deleted
if (testSubject is UltraTabPageControl) {
aPage = testSubject as UltraTabPageControl;
...
}
 
such is-as pattern, while very readable, is wasting CPU cycles as the type checking is executed twice. The better apporach is:
 
aPage = testSubject as UltraTabPageControl;
if (aPage!=null) {
 
...
}
 
:)
Luc Pattyn at 5-Nov-11 19:22pm View
   
Deleted
Slightly different, taking advantage of some binary operator, thus eliminating the need for divisions or modulo's:
 
public static string SwapCharPairs(string input) {
int length=input.Length;
int lengthEven=length&-2; // -2 has all bits set except bit 0
StringBuilder sb=new StringBuilder(length);
for (int i=0; i<lengthEven; i++) sb.Append(input[i^1]); // ^1 toggles bit 0
if (lengthEven!=length) sb.Append(input[lengthEven]);
return sb.ToString();
}
 

:)
Luc Pattyn at 10-Oct-11 21:55pm View
   
IMO if (textBox!=null) would be adequate, no need for object.ReferenceEquals()
 
:)
Luc Pattyn at 29-Sep-11 8:08am View
   
Deleted
Reason for my vote of 3
Controls can form a hierarchy as in a TextBox inside a GroupBox inside a Panel inside a SplitContainer. So you need recursion to do something to all (or some) of them.
Luc Pattyn at 24-Sep-11 23:04pm View
   
Deleted
Not quite. Two examples:
1) If the textbox contains 214748364, then typing 7 at the RHS is OK (results in 0x7FFFFFFF), however typing it at the LHS clearly gives an overflow which your code is not detecting.
2) If the textbox contains digits only, then typing a minus sign at the LHS is OK, whereas your code will reject it.
Luc Pattyn at 21-Sep-11 12:55pm View
   
Deleted
That is incorrect, your code is assuming the caret is at the RHS, which isn't necessarily true. It's better to wait for the TextChanged event, and check there. Otherwise, you have to compute the new string under all circumstances, including paste and cut-paste.
Luc Pattyn at 14-Sep-11 16:36pm View
   
Deleted
The cross-thread limitations are not specific to CF or a particular version thereof, they are present (and basically always the same) for all versions of the Framework. I described the whole shebang here.
Luc Pattyn at 3-Sep-11 11:05am View
   
Deleted
Hi Phil,
 
version 2 is OK IMO, and I like it!
 
there is just a minor mistake: "The call to KeepAlive simply tells the Garbage Collector..." is not completely accurate; it really instructs the compiler to keep a reference (and hence the object alive), as it will be used as a parameter (to an empty method, which hasn't been executed yet at the point where you were risking of seeing the object killed). Any which way you choose to keep a reference around is fine; calling Dispose() is, however if that is not what you want, GC.KeepAlive() is a nice way without any side effects (while it is an empty method, I assume it has some attributes to make sure it doesn't get optimized away).
 
And finally, I think "Treat the execution of a finalizer as a bug" is too strong a statement; finalizers can be put to good use (I don't have a simple example around though, I typically seem not to need them); however if all they do is call Dispose, then yes, you should try and call Dispose directly if at all possible.
 
:)
Luc Pattyn at 31-Aug-11 18:02pm View
   
Deleted
Thanks Walt. I do like compact code, unless readability would suffer.
Luc Pattyn at 31-Aug-11 12:00pm View
   
Deleted
yes
Luc Pattyn at 29-Aug-11 14:38pm View
   
Deleted
Me again, I now read one of the MS pages your article referred to. And I fully agree with what MS says there: GC.KeepAlive is one way to make sure the object's reference has to be kept around (and hence the object remains alive) until after your native call returns. They did not name some alternatives, such as: return b;, or Console.WriteLine(b.ToString()) or b.Dispose(). And they certainly did not say b.Dispose() is not sufficient!
Luc Pattyn at 29-Aug-11 14:24pm View
   
Deleted
Hi Phil,
 
0. yes I am familiar with the internals of compilers and garbage collectors, I have been involved in several projects creating such, albeit some time ago and not .NET specific.
1.I hadn't read the article until now; now I have, and I don't trust it. It doesn't give me any proof of what is claimed.
2. Your statement "The compilers analyze the code and determine that a particular object is collectable beyond a certain point" is completely false; a compiler analyzes source code and generates either IL/MSIL or native code. It doesn't worry about object survival (except for scope checking while accepting your code), and in particular it does not instruct the run-time about killing or keeping alive objects. That is handled entirely by the garbage collector; and then the GC isn't interested in your code at all, it only looks at the data (static classes, stacks, CPU registers, and the like); and when in doubt, it has to take the conservative approach and not drop objects when in doubt.
3. This is what neither the article nor you have mentioned: objects may be MOVED in memory by the GC (a GC pass will "compact" the regular heap, by moving all surviving objects to one end, reducing the possible fragmentation risks). Managed code doesn't care about that, it copes automatically. However, pointers passed to native code may become invalid. There are some remedies, one is automatic pinning, which may or may not work reliably, I just don't know, I have never really trusted it. I most always use explicit pinning through the GCHandle class. I don't know how you could pass a pointer without automatic or explicit pinning, the only way I can see things go wrong for sure is when your native code would continue to use the pointer after the function returned, which cannot possibly be remedied automatically. That is where GCHandle is necessary. I wrote two articles that touch the subject, which you can find here and here
Note: if my #3 is relevant to your situation, then GC.KeepAlive() helping out would puzzle me, all it does is offer a way to refer to a reference you don't want to die; the method is actually empty, you can check with a disassembler tool such as Reflector! Obviously, being empty (and not having been called yet) doesn't contribute to pinning.
 
Hope this helps.
 
I also hope the above is somewhat clear; if it isn't I strongly suggest you move the discussion to a real forum where one can use an almost decent edit page, rather than the silly 4-line edit box (extensible to a whopping 5-line!) the TT comment subsystem provides.
Luc Pattyn at 29-Aug-11 8:34am View
   
Deleted
"the use of using or an explicit invocation of Dispose reduces the probability of premature disposal ... but does NOT eliminate it."
I fail to see how that could be possible. When you have:

Foobar b=new Foobar();
b.CallAMethod();
orDoSomethingTo(b);
b.Dispose();

(or a using construct which the compiler turns into a try-finally-dispose) then obviously b has to remain alive till its Dispose method is called, there is no way the GC could collect b in the mean time (barring a .NET bug, of which I'm unaware).
I'm afraid your observations haven't been completely accurate about this; alternatively I would be interested in an actual example that does fail in keeping such b alive when it should.
 
:)
Luc Pattyn at 28-Aug-11 5:16am View
   
Deleted
I worked on some pretty complex managed/unmanaged applications (mostly without COM though), and had a similar experience once, however I never used GC.KeepAlive() to remedy it. In my experience either one of the following should suffice:
- make Foobar b a class member instead of a local variable;
- make Foobar implement IDisposable and use using (Foobar b=new Foobar()), which essentially adds a b.Dispose() statement and hence a reference that keeps the Foobar instance alive until it gets executed.
 
Obviously I prefer the latter as it is safer and matches the situation at hand; your Foobar objects being half native deserve to be disposable.
 
:)
Luc Pattyn at 22-Aug-11 23:00pm View
   
i = i + 4; //Do this to make it faster.
 
that comment made me laugh aloud, which doesn't happen very often.
If you want multiples of 5, then step by 5, not by 1, nor by 1 then by 4.
Just get the initial value corrected, like so:
for (int i=(from+4)/5*5; i<to; i+=5) ...
 
There is no need for a modulo operation here!
 

:)
Luc Pattyn at 21-Aug-11 5:57am View
   
Deleted
VS2008 has done that for years...
Luc Pattyn at 15-Aug-11 20:57pm View
   
Deleted
WOW64 is NOT an x86 emulator; there is no need for such emulation: the 64-bit Intel or AMD chip includes one or more 32-bit as well as 64-bit CPUs, there is no need to emulate the 32-bit instruction set, registers, or programmer's model. What WOW64 does is emulate a 32-bit version of Windows, as if an actual 32-bit Windows XP/Vista/7 were present.
Luc Pattyn at 26-Jun-11 19:11pm View
   
Deleted
Reason for my vote of 2
slightly better. A few examples would be welcome, and an explanation how it works, and what external resources are being used, if any.
Luc Pattyn at 25-Jun-11 19:20pm View
   
Deleted
Reason for my vote of 1
No description, no explanation, no text whatsoever.
Luc Pattyn at 14-Jun-11 7:20am View
   
Deleted
Excellent. And the crypticism gets balanced very well by the comment lines.
 
:)
Luc Pattyn at 12-Jun-11 20:59pm View
   
Deleted
Nice little function, a bit cryptic though, and probably not quite correct. 22 gives 22th.
I guess there is a bug in k = (int)(v % 100);
BTW: you don't need the variable w at all. Start setting res to v.ToString, then reduce v to v%100, later do k = (int)(v % 10), and all is well.
 
:)
Luc Pattyn at 12-Jun-11 20:39pm View
   
Deleted
yep. problem solved.
IIRC you also changed the way positives get returned. Having had trouble with a leading NULL? I had been wondering about SET @minus = '' too but didn't mention it (it wouldn't compile in the languages I'm used to, I don't know how SQL treats it, my guess now is it turns it into a NULL character, i.e. a '\0')
Luc Pattyn at 12-Jun-11 15:05pm View
   
Deleted
I'm also puzzled about SET @minus = '-1', shouldn't that be SET @minus = '-'
 
?=?
Luc Pattyn at 12-Jun-11 15:01pm View
   
Deleted
That is the typical way to do these things, however it is the first time I see it done in SQL.
 
Unfortunately, it is bound to fail for the smallest possible input value. Have you tested with -9,223,372,036,854,775,808?
 
As you are relying on the system's int-to-string conversion anyway, why not avoid the bug and convert the original number rather than the attempted ABS value, and then deal with the possible '-' character from there?
 
:)
Luc Pattyn at 8-Jun-11 10:15am View
   
Deleted
I don't want to change the functionality. All I said is: if all replacements are single chars (as in the example I gave), then, for that instance, use a string, not a string array.
:)
Luc Pattyn at 8-Jun-11 10:00am View
   
Deleted
you seem to have missed part of the suggestion, you could still simplify: when the replacement is a single character, use a string, not a string array.
Like so:
private static string[] ReplacingCharDegree33And48 = ReplacingCharDegree16And32.Concat(new string[] { "$", "$", "£", "£", "(", "(", "¥", "¥", "µ", "µ", "Ð", "Ð" }).ToArray();
becomes
private static string ReplacingCharDegree33And48 = "$$££((¥¥µµÐÐ";
and then a simple indexing gives the one character you want.
 
:)
Luc Pattyn at 8-Jun-11 7:27am View
   
Deleted
I don't know what the expected action would be.
Personally, I don't like drastic changes as they make it hard to understand what all the existing comments are about, so I would add an alternate.
 
:)
Luc Pattyn at 7-Jun-11 19:58pm View
   
Deleted
Great tip.
Right-clicking a folder while holding SHIFT down adds "Open command window here" on Vista too.
 
:)
Luc Pattyn at 1-Jun-11 6:28am View
   
Deleted
Reason for my vote of 1
Philippe is right.
Luc Pattyn at 11-May-11 21:17pm View
   
Deleted
I agree with your approach.
The sad thing is for any given type T compositeValues is going to be calculated over and over again, always yielding the same value. The enum type really should offer a solution to avoid that.
 
I will add an alternative that may remedy that to some extent.
 
:)
Luc Pattyn at 25-Apr-11 15:45pm View
   
Deleted
When in doubt, go for an article I'd say. Things tend to grow anyway, some people never can get enough.
Maybe add some nice pictures, a few use cases, actual SQL code, and come up with a demo app or web site.
 
^_^
Luc Pattyn at 25-Apr-11 10:39am View
   
Deleted
Great tip!
 
BTW: assuming the username is case-insensitive, you may choose to add robustness by making the hashing case-insensitive too.

 
Of course not storing the password in one way or other also makes it impossible to return the password in case it gets lost. The suggestion would then be to have a mechanism for the user to provide a new password, probably by re-instating the original password, which was provided by the system, and has to be replaced by the user right away.
 
FWIW: As hashing is a kind of compression, an infinite number of strings may result in the same hash value; therefore if both your hashing code and someone's hash value are known, you can obtain a working password for it (a 2^32 brute-force effort) and hence impersonate him on the system. On the plus side, this isn't going to be the original password, so it won't work for other sites, assuming they use a different hashing code snippet. I recommend adding not only the account name but also some string literal that is unique for the site.
 
:)
Luc Pattyn at 20-Apr-11 9:09am View
   
Deleted
OK, we're half done now. I'll use my original numbers again:
1. what I meant to say is this tip/trick should only show the conversion method; having a test bed (Form, Button, PictureBox) is nice, but should be in a separate class (and probably not shown here).
3. calling MeasureString was fine, however you should capture its return value and store it as a Size, then use its Width and Height properties. The way you had it, the code was calling MeasureString twice, so the expense of measuring the text got doubled.
5. The brushes and fonts you create need being disposed; that too can be handled by using statements.
 
:)
Luc Pattyn at 19-Apr-11 18:24pm View
   
Deleted
Your code needs some cleaning up. Here are some comments:
1. why would there be a need for a Form? the Convert_Text_to_Image() method belongs in a static class (and its name should follow standard C# naming conventions)
2. why do you create two bitmaps? and two graphics, one for each bitmap?
3. why do you execute MeasureString twice?
4. you should dispose of the Graphics you create. The "using" pattern would work well here.
5. you probably want the brush color to be a parameter too; note: if you were to create a brush, you'd have to dispose it too.
 
:)
Luc Pattyn at 14-Apr-11 15:29pm View
   
"lotion programmer" doesn't sound right, does it? :)
Luc Pattyn at 12-Apr-11 11:56am View
   
Deleted
Thanks. Searching a bit you could stumble on this one :)
Luc Pattyn at 10-Apr-11 4:52am View
   
you're welcome. :)
Luc Pattyn at 14-Mar-11 17:10pm View
   
Deleted
I fixed the < mistake, thanks. And no, I'm no longer trying to quote the exact text as it changes all the time. :)
Luc Pattyn at 28-Feb-11 12:55pm View
   
Deleted
Reason for my vote of 2
no text, no tip.
Luc Pattyn at 24-Feb-11 10:12am View
   
I would vote that up if I knew how to do so...
And I am in favor of PRE-tag support everywhere.
 
:)
Luc Pattyn at 13-Jan-11 16:49pm View
   
I agree on the performance aspect. When error reporting comes into play, I prefer all problems reported at once, not one at a time, so I don't need multiple user iterations; nested IFs wouldn't do that for me.
Luc Pattyn at 13-Jan-11 14:36pm View
   
I agree, however I wouldn't use nested ifs, the beaty of TryParse is you can simply AND a lot of them together, without investing lots of spaces, tabs, and curlies. :)
Luc Pattyn at 13-Jan-11 12:43pm View
   
Deleted
Reason for my vote of 5
Hi Dave. Well done. Except for the stack issue of course. :laugh:
Luc Pattyn at 13-Jan-11 12:42pm View
   
Deleted
I wonder what really happened here. The parameter is part of the Win32 API, it is not really .NET related. And it is optional, i.e. NULL is good. So I'm puzzled why it wouldn't fail on all Windows versions and .NET versions, or work on all of them. Unless .NET 4.0 here really came together with a 64-bit Winodws version, which would pass parameters differently and get confused by the value it found instead of the missing template pointer.
Luc Pattyn at 10-Jan-11 8:23am View
   
Deleted
Visual Studio does east-coasting without any problem. There are dozens of formatting options, apparently your choices and mine are different.
Luc Pattyn at 9-Jan-11 14:46pm View
   
Deleted
Wrong? The compiler is happy with it. I do that all the time, and call it east-coast formatting.
Luc Pattyn at 4-Jan-11 13:19pm View
   
Deleted
I don't see it (maybe because it really is missing??)
Luc Pattyn at 2-Jan-11 12:58pm View
   
Deleted
If you were to show only a fraction of the code, explaining it, telling us how it works and how it is special; and then provide a download application that demonstates it somehow; it could make a good article. But never a tip/trick.
 
PS: I added this as a separate comment because the voting tool only gives a minute edit box.
Luc Pattyn at 2-Jan-11 12:56pm View
   
Deleted
Reason for my vote of 1
Too much code.
Luc Pattyn at 1-Jan-11 11:26am View
   
Deleted
I did in the line len--;
Luc Pattyn at 29-Nov-10 16:03pm View
   
Deleted
for positive values of Days both (7+Days) Mod 7 and Days Mod 7 are equivalent, but unequal to just Days (think of Days values >=7)
Luc Pattyn at 18-Sep-10 22:03pm View
   
Deleted
Reason for my vote of 1
I'm afraid I don't agree. The tip was about the bitness of the OS, not the process.
 
If you build native code for 32-bit, it will always say 32-bit. If you build it for 64-bit, it will fail on Win32.
 
If you build managed code for AnyCPU, it will adapt itself by default; but I guess you could force it to run in 32-bit mode, hence lying about the OS bitness.
 
My conclusion is you cannot reliably get the OS bitness without looking outside the process.
Luc Pattyn at 12-Sep-10 12:46pm View
   
Deleted
Reason for my vote of 3
fixing vote
Luc Pattyn at 24-Aug-10 20:01pm View
   
I object. It's unacceptable. Roman numbers use upper-case. always. no exceptions. none whatsoever.
I need a completely-disgusted icon here. In fact an entire line of them.
Luc Pattyn at 19-Aug-10 8:54am View
   
Deleted
I'd like to see some unit tests, your method seems a bit error prone. Otherwise excellent.
Luc Pattyn at 20-Jul-10 13:48pm View
   
Deleted
Reason for my vote of 2
bug
Luc Pattyn at 20-Jul-10 13:47pm View
   
Deleted
QuarterOfDate seems quite wrong, it numbers the quarters as 4, 1, 2, 3?
all it takes IMO is return (curDate.Month+2)/3; if one wants quarters 1, 2, 3, 4.
Luc Pattyn at 19-Jun-10 7:53am View
   
Deleted
Reason for my vote of 1
The best way? it isn't even readable! It starts and ends with a failing PRE tag, not sure if this is all one snippet, or some text is embedded, explaining what this is about.
Luc Pattyn at 8-May-10 14:17pm View
   
Deleted
not going to delete this
Luc Pattyn at 8-May-10 14:16pm View
   
going to delete this
Har! Har! I have made it available again. - Henry. :-)
And I have deleted the one you were going to leave.
Am I able to make these changes because of my site status or can anybody do this?
Luc Pattyn at 8-May-10 14:16pm View
   
Correction: yes I can edit them, however the edit box gets preloaded with the content of an arbitrary comment, not necessarily the one I want to edit.
Luc Pattyn at 4-May-10 10:23am View
   
???
Luc Pattyn at 4-May-10 10:01am View
   
Deleted
Hi John,
I'm testing the new comment facilities. Can you reply to this? If so, will I be able to react on your reply? is it hierarchical again, as forums are, or did it just go from a one-level to a two-level structure?
BTW: your first code snippet has a little HTML problem around the LT/GT signs.
Luc Pattyn at 4-May-10 9:56am View
   
Hi Henry
just testing comment feature

Advertise | Privacy | Mobile
Web04 | 2.8.140916.1 | Last Updated 1 Jan 1900
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid