Zitat von
neolithos:
Was könnte wohl daran falsch sein?
Ich tippe mal auf das fehlende W in den Nachrichten, weil Borland standardmäßig die normale Nachricht (ohne A und W) mit der
Ansi-Version gleichsetzt:
Delphi-Quellcode:
const
{$EXTERNALSYM LVM_GETSTRINGWIDTHA}
LVM_GETSTRINGWIDTHA = LVM_FIRST + 17;
{$EXTERNALSYM LVM_GETSTRINGWIDTHW}
LVM_GETSTRINGWIDTHW = LVM_FIRST + 87;
{$EXTERNALSYM LVM_GETSTRINGWIDTH}
LVM_GETSTRINGWIDTH = LVM_GETSTRINGWIDTHA;
In den C-Headerdateien gibt´s dafür die
UNICODE-Definition. Ist die gesetzt, wird bei der Nutzung der Header auch die korrekte Nachricht (in dem Fall LVM_GETSTRINGWIDTHW) benutzt. Den gleichen Effekt könnte man mit bedingter Compilierung
Delphi-Quellcode:
{$DEFINE UNICODE}
// ... viele Codezeilen ...
const
{$EXTERNALSYM LVM_GETSTRINGWIDTH}
{$IFDEF UNICODE}
LVM_GETSTRINGWIDTH = LVM_GETSTRINGWIDTHW;
{$ELSE}
LVM_GETSTRINGWIDTH = LVM_GETSTRINGWIDTHA;
{$ENDIF}
natürlich auch in den Units von Borland erreichen. Das setzt aber den Quellcode voraus, und man muss diesen bearbeiten ... bei der Masse an Units könnte das u.U. eine ganze Weile dauern, bis man alles nach evtl.
Ansi- und
Unicode-Nachrichten abgegrast hat.
Zitat von
Chakotay1308:
Was mich wunderte war nur, dass Borland diese überhaupt übersetzt hat, denn im Endeffekt ist es doch nur eine Abkürzung für SendMessage-Nachrichten.
Ehrlich gesagt arbeite ich lieber mit den Makros, weil ich mir dabei in der Regel keine Gedanken um die Parameter der Nachricht machen muss. Ich übergebe das Notwendige an das Makro (= im Funktionskopf), und dann vertraue ich mal darauf, dass das Makro weiß was es tut.
Dass auch Microsoft dabei Fehler unterlaufen, beweisen
Edit_GetCueBannerText und die dazu gehörende Nachricht EM_GETCUEBANNER
.