Where to get it? Although, I am one of those guys that like to go into a store and just take the stuff with me, this was not possible this time as said receiver is quite uncommon (newly on the market and quite expensive [but sounds very nice]), so buying online was my only way to get it.
They promised delivery somewhere around February, 10th, but the stuff was here already yesterday. They've worked fast and professional. Very nice.
If you live near switzerland and need exotic AV-stuffm especially modified consoles or DVD-players (region code, macrovision, ... - they even wrote a new firmware for Pioneer Players from scratch), give them a shot!Read on →
Delphi, WinXP and Password Edits
I'm still into making Delphi apps look more "native" when run under Windows XP. Now that I got the IE-Control working, I was looking into the password-edit case.
The Problem: When using the standard way for creating password edits (Drop a TEdit on the Form and set the PasswordChar property to ° ), this may look and work on in Win 9x, NT and 2000, but under XP, some features are missing:
- In XP, password-edits cannot be read from other applications by sending the WMGETTEXT message. Delphi's TEdit can.
- In XP, the edits have a nice bullet instead of a * to mark the entered characters
- When CapsLock is active, a balloon-hint appears warning the user that maybe she is not doing what she expects
How to fix this?
Simple: Create a descendant of TEdit, override CreateParams and set the controls style to ESPASSWORD. Provided you are supplying a valid Manifest for XP, you now have a fully fledged and nice working password-edit:
procedure TPasswordEdit.CreateParams(var Params: TCreateParams); begin inherited; Params.Style := Params.Style or ESPASSWORD; end;
Oh. One thing is still missing: The dots look wrong. This is because Delphi does not use Windows' standart font per default but overrides this with "MS Sans Serif" where "Tahoma" is the standard under XP. So Delphi-Apps generally look kind of foreign - even more so, when ClearType is enabled (MS Sans Serif is a bitmap font and cannot be antialiased).
This can be fixed by setting each forms DesktopFont property to true. Note that it's a protected property, so it must me called from withing the form.
Now the bullets look right and the font's in your application are proper anti-aliased (provided ParentFont is set to true in every component on the form).
Easier to use? Cheaper because of that? Dream on!
The Exchange Server I already had strange problems [read this and related postings there] with, today had another one of them. I had to give reading-permission to some public folder to some users (although the GUI to do that from within Outlook is really easy to use, some people rely on me doing that for them because that's even easier).
The Exchange Server Manager threw a strange message at me whenever I tried to expand the folder-list in the tree. The text was useless as ever and nothing was posted to the event-logs - as ever. Why is there a logging-framework if it is not used? (besides, if it would have been used, the message would have been just as un-understandable as the one I was getting).
This time, I was lucky: I got an error number along with the message that was even known to the knowledgebase. The error was 80040e19 and the knowledgebase article was Q328659.
The problem was easy to fix and had something to do with some "security-tool" that got installed alongside the IIS-Lockdown tool which itself got installed alongside the common Windows-Update procedure. Nice to know that just updating the system via such an easy procedure can bring essential functions down without any warning.
Microsoft always emphasises the ease of use of their products and the better support you are getting when using their closed source solutions. Granted: The "ease of use"-thing can sometimes really be true (many things just work out-of-the box with not nearly as much work as I would have when using a common linux distribution), but when something does not work, fixing microsofts server software is much more difficult than fixing equivalent linux software as the fixes are un-obvious and the error messages are unusable.
The level of support for me is just the same as with comparable open-source software: Use google, enter the error message you get and pray someone had a fix for it posted somewhere. If not, I see virtually no solution in Microsoft land (besides paying a lot of money for support) whereas in the open-source land I would be able to fix the problem sometime later as I have readable error-messages and if that does not help I could try to understand the problem by reading the sourcecode.
That's why I usually prefer open solutions. Or have you ever seen software working flawlessly?Read on →
Double double dash
This is what I've ever wanted to do, but I have neither enough room, nor enough friends willing to participate nor enough equipement. Maybe later...Read on →