tListView-Spalten

[Chewie]

Zitat von Chakotay1308:

denn im Endeffekt ist es doch nur eine Abkürzung für SendMessage-Nachrichten.

...die aber im Platform SDK explizit genannt wird. Für unbedarfte Entwickler wäre es sehr verwirrend, wenn sie LVM_GETCOLUMN benutzen könnten, aber nicht ListView_GetColumn. Denk ich mal

[Luckie]

Zitat von neolithos:

Aber Vorsicht bei ???W-Funktionen, die sind meist falsch implementiert!

Öhm, Beweise?

[neolithos]

Was könnte wohl daran falsch sein?

Delphi-Quellcode:

function ListView_InsertItemW(hWnd: HWND; const pItem: TLVItemW): Integer;
begin
  Result := Integer( SendMessage(hWnd, LVM_INSERTITEM, 0, Longint(@pItem)) );
end;

function ListView_FindItemW(hWnd: HWND; iStart: Integer;
  const plvfi: TLVFindInfoW): Integer;
begin
  Result := SendMessage(hWnd, LVM_FINDITEM, iStart, Longint(@plvfi));
end;

function ListView_GetStringWidthW(hwndLV: HWND; psz: PWideChar): Integer;
begin
  Result := SendMessage(hwndLV, LVM_GETSTRINGWIDTH, 0, Longint(psz));
end;

u.s.w.

[CalganX]

Hi,
also wenn die Borland so definiert hat, dann will ich nichts gesagt haben.

Chris

[neolithos]

Alle die den Source "CommCtrl.pas" haben können es bestätigen!

Gut das ich ihn an dem Tag (wo mir das aufgefallen ist) hatte!
Ich hatte nämlich schon an mir selbst gezweifelt! Warum es nicht funktioniert und nur ein Buchstabe angefügt wird!

Aber nun weis ich es ja!

[Thunderchild]

Um mal zu meinem Problem zurück zu kommen:

neolithos Methode funktioniert jedenfalls. Hab halt die CommCtrl eingebunden.
Danke.

[MathiasSimmack]

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 .

[neolithos]

Das man Delphi-Programm, ob nonVCL oder VCL, nicht auf Uni-Code umschalten kann stört mich seit dem ich die vorzüge für Mehrsprachige Anwendungen entdeckt habe!

Weiterhin ist die Schlampig umgesetzte Thread-Sicherheit in der VCL mir ein Dorn im Auge!

Ich halte viel auf Delphi bzw. Object-Pascal, aber die zwei wünsche hätten die Borland-Leute schon mal Regeln können!

Doch wird durch .NET-Geschichte (was mich noch nicht überzeugt hat) ja die ganze VCL in den Hintergrund rücken! *schade*

Das war vielleicht OT aber ich musste es mal loswerden!

[MathiasSimmack]

Zitat von neolithos:

Doch wird durch .NET-Geschichte (was mich noch nicht überzeugt hat) ja die ganze VCL in den Hintergrund rücken! *schade*

Ich find´s gut. Die Programme werden wieder kleiner, weil die .NET-"Kompos" ja schon vorhanden sind. Und (habe ich mal irgendwann in einem Crashkurs von A.Kosch gelesen) wir müssen nicht mehr darauf warten, dass irgendwer neue Headerdateien übersetzt, bzw. wir müssen das nicht mehr selbst machen.

Was mich lediglich interessieren würde, sind ein paar spezielle Win XP-Dinge und deren Umsetzung in .NET. Okay, ich habe nur Beta 2 vom letzten VS.NET (nicht die aktuelle Version!), vielleicht ist das im aktuellen Visual Studio ja schon anders, aber irgendwie habe ich bspw. bei der List-View die neuen Befehle (Gruppierung, Spalte markieren) vermisst.

[neolithos]

Im .NET gibt es kein

ScrollWindow
SetCaret
ListView-Owner-Data
ListView-Owner-Draw
...

jedenfalls habe ich es noch nicht gefunden!

Und API-Rufe (PInvokes) will ich nicht verwenden weil dies gegen den .NET-Etos (Plattform-Unabhängigkeit - die derzeit nicht existiert) verstoße.

Will man API-Rufe verwenden muss man C-Header doch wieder übersetzen.

[das geht hier langsam vom Thema ab]