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 WM_GETTEXT 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 ES_PASSWORD. 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 ES_PASSWORD;
    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).

    delphi_pwchar.png

Delphi, Windows XP, Styles and embedded IE

Let’s say you have a delphi (delphi 7 – altough prior versions can use Mike Lischkes Theme Manager application which embedds the Microsoft Internet Explorer ActiveX Control. Let’s assume furhter that you have created your Manifest so the application appears in the themed style under Windows XP.

Unfortunatly, the embedded IE does not do that: Controls are still drawn in the old theme-less style. Why? How to tell the Control to use the themed style (which it certainly supports – just look at IE itself)?

For long I was looking for a solution which I’ve just found.

First, call SetThemeAppProperties (defined in UxTheme.pas), then send WM_THEMECANGED to your forms – at least to the one that uses the IE-Control. Example:

  SetThemeAppProperties( STAP_ALLOW_NONCLIENT OR
       STAP_ALLOW_CONTROLS OR
       STAP_ALLOW_WEBCONTENT );
  PostMessage(frmBrowser.Handle, WM_THEMECHANGED, 0, 0);

Especially important is the flag STAP_ALLOW_WEBCONTENT

Then, in the form containing the browser, just add a message-procedure:

Form-declaration:

  private
    procedure wmthemechanged (var msg: TMessage); message wm_themechanged;

Update: I’ve turned off the comment-feature as this entry somehow got listed in some spammers database. I’m currently deleting about 10 entries per day that are just there to provide links to some stange sites. I’ll post about this later.

The anatomy of a delphi crash

Delphi has the habit of crashing on exit from time to time. This time it was quite resourceful in finidng different styles of error-messages:

Harmless
Quite ordinary

Overlay
Overlay

Transparent
Transparent

Captionless
And finally: Captionless

New messages popped out just after closing the previous one with “OK”. Finally I had to close the delphi32.exe process using the Task Manager. Delphi would be the perfect piece of software if only it’d be more stable.

What I dislike about Java

I really tried to get into programming something in Java. Alone the psossibilities with JSP/Servelets seem very interesting compared to what you get when using PHP. Another thing would be the many excellent IDE’s (even free ones like Eclipse) out there that only support java (I know that PHP-Plugins for Eclipse exist, but they are not really usable – a thing I’ll write about in the future).

But I never really took off and until today I never really could describe what is holding me back.

Today I found this article which explains it by using examples to compare python to java. Although it’s about python (a language I don’t really like), most of the point in there apply to other scripting languages (PHP, Perl, Ruby,…) too.

Really good read and finally the explanation I was looking for.

SOAP needs soap

For our Web-Portal superspeed, I am working on a webservice to give some clients access to our provider/offer database.

As the whole portal is written in PHP, I deceided to write the Webservice (fully fledged using the SOAP-Protocol) in PHP too. After some searching, found NuSOAP and the SOAP-Package in PEAR.

Both packages have virtually no documentation, but the PEAR-package has some nicely documented samples (disco_server.php, example_server.php just to name the most interesting two).

While nuSOAP is very easy to handle, it doesn’t have a way to autogenerate WSDL-output which would have forced me to learn writing WSDL. Unfortunatly I did not have time for this, so I went with the PEAR-Package which is able to create the WSDL for you.

The first tests using PHP as SOAP client worked very well.

tip: to increase “debugability” to an actually useful level, use something like the code here for debugging your server:

// include the actual server class
require_once 'modules/ss3_Provider/xml_access.php';

if ($_SERVER['argv'][1] != 'direct'){
    // use the SOAP-Interface to our class
    include("SOAP/Client.php");
    $wsdl = new SOAP_WSDL("http://your.server.com/server.php?wsdl");
    $object = $wsdl->getProxy();
}else{
   // Use the class directly
    $object = new CProvServiceInfo_Class();
}
// do something with $object

If the script is called with the “direct” parameter, the class will be used directly thus giving you back all the debug information you need without an XML-parser trying and failing to unserstand them.

As the customer for this service is going to use ASP.NET to access the webservice, the next step was to try accessing the service via Visual Studio.NET. This was not fun (pasting the complete error here in the hope that google will catch this and will help future users having my problem):

Custom tool warning: At least one import Binding for the ServiceDescription is an unsupported type and has been ignored.

The hairy thing: I have no expirience at all with VS.NET, so I first thought this was a minor problem and I was just too stupid to actually use the imported class. But sooner or later (after trying out importing the Google Webservice), I came to the conclusion that this warning actually is a grave error: Nothing got imported. Nothing at all.

Searching google did not yield any results.

The next step for me was to learn WSDL (which I did not want to in the first place ;-). Unfortunatly, the PHP generated WSDL-File seemed quite ok (besides the missing <documentation>-Tags).

I could not get VS to report a mor detailed/useful error message.

Just when I wanted to give up, i thought of this tool, wsdl.exe that gets installed with the .NET Framework SDK. Running wsdl <filename.wsdl> gave me the same error message, but with a note to look into the generated .cs-File.

This finally gave an usable error-message:

// CODEGEN: The binding 'SuperspeedProvidersBinding' from namespace 'urn:SuperspeedProviders' was ignored. There is no SoapTransportImporter that understands the transport 'http://schemas.xmlsoap.org/soap/http/'.

A quick comparison of the <soap:binding&gt-Tags showed:

Googles Version: http://schemas.xmlsoap.org/soap/http
PHP’s Version: http://schemas.xmlsoap.org/soap/http/

Note the slash at the end.

I hate problems with simple solutions that are so awfully difficult to find because of un-usable error messages!

Just for reference: The following patch fixes the wrong Transport-URL in PEAR::SOAP (0.7.3 – I will report this to the author, so maybe it’s fixed in later versions):

--- Base.php    Thu Jun  5 13:16:03 2003
+++ -   Fri Jun  6 22:51:08 2003
@@ -91,7 +91,7 @@
 define('SCHEMA_DISCO_SCL',          'http://schemas.xmlsoap.org/disco/scl/');

 define('SCHEMA_SOAP',               'http://schemas.xmlsoap.org/wsdl/soap/');
-define('SCHEMA_SOAP_HTTP',          'http://schemas.xmlsoap.org/soap/http/');
+define('SCHEMA_SOAP_HTTP',          'http://schemas.xmlsoap.org/soap/http');
 define('SCHEMA_WSDL_HTTP',          'http://schemas.xmlsoap.org/wsdl/http/');
 define('SCHEMA_MIME',               'http://schemas.xmlsoap.org/wsdl/mime/');
 define('SCHEMA_WSDL',               'http://schemas.xmlsoap.org/wsdl/');

As you can see, there are more URLs having a slash at the end – possibly more candidates? We’ll see. At least I know now, how to debug such problems…

Two more bugs… gone!

No. This is not about the new iPods, Apple announced today (of course I’ve ordered myself a 30GB one, but this really is another history).

I’m just very pleased that two Bugs in jEdit’s current CVS-Version that have been fixed by Slava the same day, I’ve reported them. This is just great!

If you are in need of a good editor, go and get jEdit!