Back to Blog index.
Poor thing, I had to ride it to the garage today.
The weather has turned so cold and rainy, that I decided to give shelter to my Kawasaki and ride it to a warm place.
Already having my mind set to the next biking season, the winter is well spent with looking at the new models for 2005.
I drove my new car to the repairshop Laakkonen in Espoo yesterday, and they did a routine check + oil change for it.
The rear brake light problem seems to be gone now, at least I haven't seen the warning message for a while. Knock knock.
Also, there was no need to replace the rear brake lumps, it was just a case of a missing wear indicator both at the front and at the rear. The previous owned simply took a shortcut to cut costs and only replaced the brake lumps, it seems.
And while surfing last evening, I found a Canadian page (from 2002, but nonetheless) dedicated to BMW E34's. It appears to have nice repair and troubleshooting tips.
Last week gave me insight into network packet sizes that I thought I would never need to bother my head with.
That is, one of the PCs I need to administer suddenly failed to login to an domain user account properly.
Yes, we had modified the network packet size (frame buffer size) of the network interface card (NIC) to a somewhat lesser value for our switch was not operating properly with jumbo-sized packets.
After the change, this single PC failed to login, and it took even very long for it to figure that out.
Naturally, Google gave wild answers to this problem, but nothing seemed to help. Finally, we reset the network packet size back to close the original value (we had dropped it to 1K for testing), and suddenly everything worked fine.
The lesson: if you fiddle with network packet sizes, Windows Active Directory might not like it. Solution: make sure the server and the workstation have the same packet size! Good luck...
I noticed that my new car has issues with the brake lights. The Service Indicator Lights (SIL) indicate that there's a problem with the brake light circuity ("Bremsli. Elektri" it says), and first I went and checked the fuse #1.
Even though it appeared fine, I replaced it, and the brake lights started to work okay. Good. But, after driving a while and parking to a gas station, I noticed the same message again. I checked the fuse #1 again, and it was fine. After riding home, the lights worked fine for an instant, but then broke again. Must be bad wiring then.
Oh, in case you are wondering, my BMW 525iA is from the year 1991, so I would say it's a E34 model with the M50 engine.
As the winter is approaching and I soon need to ride my bike into the garage, I decided to visit a nearby suburb called Tuusula with my friend yesterday.
From there, I found (after a fast-lane test drive) a nice BMW 525 with automatic transmission. It's a 1991 model, so not one of the newest, but the engine and the chassis seem to be in good shape.
And, the thing is pretty fast, so the thing is a joy to drive.
In case you need good images for your publication, visit GoodShoot.com.
The site seems to contain quality image libraries, but naturally they won't come cheap.
But it's fun to surf their pages nonetheless. For some reason the .com address redirects to a DynDNS address. Not a professional touch, though.
I spent my yesterday afternoon and evening at the Delphi 2005 launch event in Helsinki. It was fun meeting those familiar Borlanders again, and see what I think is the best ever Delphi version.
Also, I got tons of questions about the new company I work for, so it took time to get the message through to everybody.
But in the end, I think I can feel satisfied for both the product and the response I got from the audience.
For at least two years I've had two separate web pages, one for business and one for personal use.
I decided to combine these two sites into on for easier maintenance, and now, there's only one site.
My personal site at the helsinki.fi domain is still running for the photos and weblog pages, but in the future these links will be merged into the new look.
Feedback is always welcome.
Just updated my photo pages with pictures from Satu and Leevi.
I also took about 110 pictures from the seashore today. I hope to have them on-line soon, along with those pictures from N.Y. and San Jose.
Since the beginning of October, I've had a new employer called Moonsoft Oy, based in Espoo Finland.
Just today, we got our Finnish web site live on the 'Net, so please go and check it out.
I'm happy to say that we've got the chance to use latest .NET technologies, and naturally the magic of Delphi.
It's a joy to read what CNN reports today about the private company's spacecraft and its second flight into space.
The $10 million that the X Prize Foundation gave to Peter Diamandis, Brian Binnie and Burt Rutan are well earned.
Godspeed, gentlemen!
As I today had the time to continue my C# sample project, I wanted to make sure my code is "clean" and easy to read.
Naturally, a good coding convention (or "coding standard") document is a good way to start, so I turned to Google.
I was a bit disappointed first, when I only found very ignorant standards (from people who cannot accept that both Java and C# can co-exist in this world), but luckily, by scrolling down, I found Lance Hunt's "C# Coding Standards for .NET" as a PDF file.
Although I don't argue with exactly 100% of the rules or conventions, Lance's document appears very good.
So, if you are writing code in C#, I can recommend this document. At the writing of this, the latest version is 1.13a from August 2004. And the document is good reading even if you are using Delphi.
If you have studied the C# language, you might be aware of the lock statement.
This is a very handy statement in multi-threaded applications. But, if you are a Delphi developed trying to hack together some example code from the net, you are at loss because Delphi doesn't support this statement.
But, since we all have a IL disassembler, it is easy to see what kind of code a C# creates when using the lock statement.
When I wrote a very simple C# application like this:
class Test
{
public static void Main()
{
System.Console.WriteLine("Before");
lock (new Test()) {
System.Console.WriteLine("Inside");
}
System.Console.WriteLine("After");
}
}
...it turned out that the generated IL code was this:
.method public hidebysig static void Main() cil managed
{
.entrypoint
// Code size 52 (0x34)
.maxstack 2
.locals init (class Test V_0)
IL_0000: ldstr "Before"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: newobj instance void Test::.ctor()
IL_000f: dup
IL_0010: stloc.0
IL_0011: call void [mscorlib]System.Threading.Monitor::Enter(object)
.try
{
IL_0016: ldstr "Inside"
IL_001b: call void [mscorlib]System.Console::WriteLine(string)
IL_0020: leave.s IL_0029
} // end .try
finally
{
IL_0022: ldloc.0
IL_0023: call void [mscorlib]System.Threading.Monitor::Exit(object)
IL_0028: endfinally
} // end handler
IL_0029: ldstr "After"
IL_002e: call void [mscorlib]System.Console::WriteLine(string)
IL_0033: ret
} // end of method Test::Main
So, the conclusion is that the C# lock statement uses the System.Threading.Monitor class internally.
The conclusion: if you encounted the C# lock statement in code you need to translate into Delphi code, simply use the Monitor.Enter and Monitor.Exit methods around the statement(s). And don't forget try-finally!
It cost me one Friday evening to try to figure out why some special characters in ASP.NET query strings were not passed into my Delphi application.
For example, I had a basic HTML form that forwards data to an .ASPX page using the GET method.
This worked fine until I decided to test some Finnish characters like Ä and Ö. For example, giving the input "Järvinen" and then using the Request.QueryString property to read the data only revealed "Jrvinen".
My first impression was that this was some kind of ASP.NET security setting for I had earlier learned about ASP.NET's way of protecting web applications from scripting attacks, etc. But I was wrong. So, my application misbehaved just the same when I did set the @Page directive's ValidateRequest atrribute to "false".
Next, I have Google a workout, but that didn't solve my problem. I even created a test project in Visual Studio .NET to see if this was a Delphi problem, but it was not.
Finally, I decided to launch up my Mozilla Firefox browser to check to see what data my ASP.NET web application returns.
At this point I noticed how the default character set for my web applications was UTF-8, and luckily that rang a bell in my head. That is, when I create web pages using Dreamweaver, I always use the "iso-8859-1" encoding, which is of course different than "utf-8". Once I changed my HTML page to use UTF-8, the special characters were no longer missing or disappearing.
Given this hindsight, it was easy to find a Microsoft Knowledge Base (KB) article that details this "error". You can find it by using the number 835385.
For a reference, you can change an ASP.NET application's default character set in the web.config file under the "globalization" section. This is an example how to use "iso-8859-1" everywhere:
<configuration>
<system.web>
<globalization
requestEncoding="iso-8859-1"
responseEncoding="iso-8859-1"/>
</system.web>
</configuration>
› Blog Archive