tListView-Spalten

[Thunderchild]

Hallo zusammen,

ich habe ein Programm, in dem ich ein tListView eingebaut habe. Hier werden in einstellbar vielen Spalten Daten angezeigt. In einer INI speichere ich die Breite der Spalten, damit sie beim nächsten Start so wieder erscheinen wie beim Beenden.

Jetzt die Frage:
wenn ich die Windows-Kombination [Strg]+[Num +] verwende, werden die Spaltenbreiten automatisch auf den Inhalt der Spalten angepasst. Jedoch wird diese Breite nicht in die Width-Eigenschaft der Spalte eingetragen, da steht noch der alte Wert.
Wie bekomme ich diese Breite?

[neolithos]

Delphi-Quellcode:

ListView_GetColumnWidth

Lies mal die breite damit aus!

[CalganX]

Hi neolithos,
das wird nich funktionieren, weil das ein C++-Makro ist. ;)

Chris

PS:

Delphi-Quellcode:

  ListView1.Column[0].Width; // zum Bleistift

[Thunderchild]

So mach ich's ja momentan, aber das kann das erkennt nicht die [Strg]+[+]-Änderung. Das ist ja mein Problem.

MfG

[neolithos]

Bei mir steckt die in der CommCtrl.

[neolithos]

Delphi-Quellcode:

  ShowMessage(IntToStr(ListView1.Columns[0].Width));
  ShowMessage(IntToStr(ListView_GetColumnWidth(ListView1.Handle, 0)));

Ich habe gerade folgendes ausprobiert!

Die Werte sind wirklich ungleich nach Strg+NumPlus! :shock:

[CalganX]

Hi,
seit wann funktionieren dann C++-Makros unter Delphi? :shock:

Welches davon ist denn korrekt? Eigentlich doch das erste, oder?

Chris

[neolithos]

Ne, das zweite!

Und ListView_??? sind keine Makro's sondern Funktionen!

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

Die Erfahrung musste ich nämlich schon machen!

[Chewie]

Zitat:

Zitat von neolithos

Und ListView_??? sind keine Makro's sondern Funktionen!

Jain :wink:
In den C-Header-Files sind die ListView_???-Dinger als Makros definiert. Da es sowas in ObjectPascal nicht gibt, haben die Borländer Funktionen draus gemacht.

[CalganX]

Hi,
danke für das Füllen dieser Bildungslücke. Und das meinte ich ja auch... ;)

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.

Chris

[Chewie]

Zitat:

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 :wink:

[Luckie]

Zitat:

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! :roll:

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:

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:

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:

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]

[MathiasSimmack]

Zitat:

Zitat von neolithos

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

Ja, genau das wollte ich damit sagen. Da gibt´s ein paar interessante Funktionen (und die Gruppierung von LV-Items ist IMHO eine sehr nützliche Funktion), die man bei .NET bisher noch nicht nutzen kann. Wir sehen das also beide ähnlich.

[Luckie]

Darf ich mal kurz stören? Ja? Danke.

Wenn euch das Thema am Herzen liegt, dann macht doch bitte dazu einen extra Thread auf, denn das wird etwas offtopic jetzt. Danke.