List Control - Zeilennamen

flofian

Hallo zusammen,

mir stellt sich folgendes Problem:
Ich brauche in einem Dialog eine Tabelle.
Diese Tabelle soll eine Art Additionstabelle sein. Das bedeutet, ich möchte einen "Überschrift" für jede Spalte und jede Zeile.
Die Anzahl der Zeilen und Spalten muss variabel sein.

Bis jetzt habe ich herausgefunden, dass man mit einer ListControl recht einfach Tabellen erzeugen kann und auch den Spalten "Namen" geben kann.

Weiß jemand, wie man das Problem mit der "Überschrift" für eine Zeile lösen kann?

Vielen Dank schonmal

Florian

AndyDD

Dann schau dir mal das hier an: http://www.codeproject.com/KB/miscctrl/gridctrl.aspx

flofian

Danke für den Link!

Die Demo sieht auf jeden Fall gut aus.

Eine einfachere Möglichkeit ohne eine solche Erweiterung gibt es wohl nicht?

Grüße

Florian

AndyDD

Ich kenn mich mit Controls nicht ganz so gut aus. Aber der Name ListControl sagts ja schon: Liste. Ich kenn sowas eben nur mit Spaltenüberschriften. Möglicherweise kann man da auch eine eigene Klasse ableiten, deren Draw-Funktion man überschreinen müsste. Sowas sieht ja stark nach Owner-Draw aus und dafür gibts bestimmt was fertiges. Hatte nur mal kurz bei Code-Project geschaut und das da gefunden. Gibt sicher auch schlichtere Varianten...

flofian

ok,
vielen Dank auf jeden Fall!

Wenn ich aber auch gleich mein nächstes Problem dran hängen muss.

Ich habe mir das von dir verlinkte MFC Grid Ctrl runtergeladen und mal ein Testprojekt erstellt.

Beim kompilieren treten auch keine Fehler soweit auf. Nur beim ausführen kommt:

`Debug Assertion Failed!

Program:[Den Pfad lasse ich mal weg]gridcell.cpp

Line: 228

For information on how your program can cause an assertion failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)`

Ich hab keine Ahnung, was ich dagegen machen kann!

Danke schonmal

AndyDD

Bekommst du das Demoprogramm zum laufen? Ich hab mal in die cpp geschaut. Das Problem tritt beim Aufruf

VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0));

auf, wenn ich richtig geschaut habe. Welches OS benutzt Du denn?

flofian

ja, die demo läuft ohne Problem.

meinst du mit OS die Version?

AndyDD

Welches OS benutzt du? Wie hast du es eingebunden. Zeig mal etwas Code...

flofian

Also ich kann dir gerne etwas Code zeigen, weiß aber nicht, was du davon sehen willst.

Ich hab bis jetzt noch nicht viel damit gemacht.

Meine Vorgehensweise war folgende:

Ich habe ein Dialogfeldbasierendes MFC-Projekt (in VS 2008) erstellt, es kompiliert und ausgeführt. keine probleme (wäre auch schlimm)

Ich habe die heruntergeladenen Dateien dem Projekt hinzugefügt ( CellRange.h, GridCell.cpp, GridCell.h, GridCellBase.cpp, GridCellBase.h, GridCtrl.cpp, GridCtrl.h, GridDropTarget.cpp, GridDropTarget.h, InPlaceEdit.cpp, InPlaceEdit.h, MemDC.h, TitleTip.cpp, TitleTip.h ; Version 2.26 Beta)

Ich habe wie in der Anleitung beschrieben ein "Custom Control" Element erzeugt und als Klasse "MFCGridCtrl" eingegeben.
Eine Variable dafür erzeugt (Typ CGridCtrl ) und das DDX.GridControl in DoDataExchange durch DDX_Control ersetzt.

kompiliert -> keine fehler

ausführen --> der Fehler tritt auf

Ich hoffe, dass die Informationen, die du brauchst, dabei sind

Edit: natürlich hab ich DDX_Control durch DDX_GridControl ersetzt

AndyDD

Wenn ich das richtig sehe tritt der Fehler im Konstruktor CGridDefaultCell::CGridDefaultCell() auf.

CGridDefaultCell::CGridDefaultCell() 
{
#ifdef _WIN32_WCE
    m_nFormat = DT_LEFT|DT_VCENTER|DT_SINGLELINE|DT_NOPREFIX;
#else
    m_nFormat = DT_LEFT|DT_VCENTER|DT_SINGLELINE|DT_NOPREFIX | DT_END_ELLIPSIS;
#endif
    m_crFgClr = CLR_DEFAULT;
    m_crBkClr = CLR_DEFAULT;
    m_Size    = CSize(30,10);
    m_dwStyle = 0;

#ifdef _WIN32_WCE
    LOGFONT lf;
    GetObject(GetStockObject(SYSTEM_FONT), sizeof(LOGFONT), &lf);
    SetFont(&lf);
#else // not CE
    NONCLIENTMETRICS ncm;
    ncm.cbSize = sizeof(NONCLIENTMETRICS);
    VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0));
    SetFont(&(ncm.lfMessageFont));
#endif
}

Wäre hier im Post Zeile 20. Du müsstest mal schauen wie das aufgerufen wird. IMHO werden die DDX-Funktionen erst nach dem Konstruktor aufgerufen. Scheint nicht ganz banal zu sein diese Klasse zu verwenden.
Du verwendest VS 2008 (Professional??), unter welchem Betriebssystem? Bei mir unter Win2000 mit VS 2003 läufts.

flofian

Auf die Zeile bin ich auch schon gekommen. Nur was da schief geht, kann ich leider nicht nachvollziehen.

Hab ich doch glatt ein paar Informationen vergessen. Also, VS 2008 Professional unter Windows XP.

Auch auf die Gefahr hin, dass ich mich lächerlich mache. Was meinst du bitt mit

AndyDD schrieb:

IMHO werden die DDX-Funktionen erst nach dem Konstruktor aufgerufen.

Also ich meine das IMHO .

Ich möchte auch nicht ausschließen, dass ich beim Einbinden etwas verkehrt gemacht habe. Meine Programmierkenntnisse reichen leider noch nicht besonders über das hinaus, was ich im Studium gelernt habe. Aber bis hierhin war ja eigentlich noch nicht wirklich viel falsch zu machen.

flofian

Was ich bis jetzt herausgefunden habe:

in der Zeile

VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), &ncm, 0));

sollen die Maße der beteiligten, nichtminimierten Fenster abgefragt werden.

Als Rückgabewert hat SystemParametersInfo einen Wert !0 falls es funktioniert hat.

VERIFY lößt diese Debug Assertion aus, wenn VERIFY(0) --> der Rückgabewert der Funktion muss 0 sein.

Aber was kann denn bitte bei einer solche Abfrage schief laufen?

flofian

Ich hab des Rätsels Lösung gefunden:

ich habe in stdafx.h folgendes eingefügt:

#ifndef WINVER
#define WINVER 0x0501
#endif

kompiliert

ausgeführt

und siehe da, es funktioniert!!!

Viel Dank an AndyDD, für die Hilfe!

AndyDD

Dachte mir schon das es was mit dem OS zu tun hat. Warum lief allerdings dann das Demoprojekt bei Dir? Das ist sehr komisch.
IMHO heißt "In my humble/honest opinion..." - "Meiner bescheidenen/ehrlichen Meinung nach..." Da hätteste auch mal Google fragen können.
Allerdings versteh ich nicht warum es nach der WINVER-Definition funktioniert. Der springt ja immer in den else-Zweig, da Du ja kein CE hast.

Martin Richter

Welches SDK wurde verwendet?
War evtl. WINVER >= 0x0600 definiert? Dann ist das kein Wunder dennin diesem Fall ist die Strukturgröße anders.

Ansonsten wäre ein wenig mehr Code sinnreich.

AndyDD

Martin Richter schrieb:

Welches SDK wurde verwendet?
War evtl. WINVER >= 0x0600 definiert? Dann ist das kein Wunder dennin diesem Fall ist die Strukturgröße anders.

Ansonsten wäre ein wenig mehr Code sinnreich.

Ja Martin, meine Rede. Aber er hat doch mit

#ifndef WINVER
#define WINVER 0x0501
#endif

WINVER definiert, da scheint es ja vorher nicht existent gewesen zu sein. Sonst ware der Präcompiler doch nicht in den ifndef-Zweig gesprungen, oder seh ich das falsch?

Martin Richter

Es hängt vom SDK ab, was als Default verwednet wird. Wenn kein WINVER verwendet wird, wird der Default im Ausgabefenster angezeigt.
Ich wollte mit meinem Hinweis einfach erfragen, was nun die wirkliche Ursache war.

Weil weder Compiler noch SDK Version angegeben wurde.

AndyDD

Martin Richter schrieb:

Es hängt vom SDK ab, was als Default verwednet wird. Wenn kein WINVER verwendet wird, wird der Default im Ausgabefenster angezeigt.
Ich wollte mit meinem Hinweis einfach erfragen, was nun die wirkliche Ursache war.

Weil weder Compiler noch SDK Version angegeben wurde.

Heißt das in dem Fall (nix angegeben) das WINVER gar nicht definiert ist? Ok, dann springt er ja auch in den else-Zweig.

Martin Richter

Nein! Je nach SDK bedeutet das, dass ein Default Wert angenommen wird.
Wird in VS-2005 kein WINVER definiert, dann gilt IMHO automatisch 0x0501!

Das ist also extrem Abhängig vom SDK! In den neuen SDKs ist immer WINVER definiert.

flofian

SDK Version habe ich die 6.1

Ich weiß, dass wenn WINVER nicht definiert ist, das eigentlich im Ausgabefenster beim kompiliern angezeigt wird. Wurde aber nicht, sonst wäre ich ja schon früher drauf gekommen.

Bei gleicher SDK und gleichem Kompiler in einem anderen Projekt wurde es mir vor kurzem erst noch angezeigt.
Dort wurde WINVER automatisch auf 0x0600 (Windows Vista) gesetzt.