Fortschrittsanzeige

Knuddlbaer

Original erstellt von RenéG:
**Nochmal zur Frage, warum dynamic_cast nicht klappen kann:

Ich weiss nicht genau, wo im Speicher, aber eines ist klar:
Die Laufzeitinformationen, welche bei GetDlgItem zurückgeliefert werden:
CObject::CWnd

Ein dynamic_cast auf CProgressCtrl würde voraussetzen, dass es sich bei den Laufzeitinformationen um
CObject::CWnd::CProgressCtrl handeln muss.

Siehe MSDN:
[quote]
void f()
{
   B* pb = new D;                     // unclear but ok
   B* pb2 = new B;

   D* pd = dynamic_cast<D*>(pb);      // ok: pb actually points to a D
   ...
   D* pd2 = dynamic_cast<D*>(pb2);   // pb2 points to a B not a D
                                    // cast was bad so pd2 == NULL
   ...
}
**

[/QUOTE]

Warum funzt das trotzdem?
Mit GetDlgItem von CWnd wird dem gelieferten HWND ein schon existierendes CWnd aus der HandleMap zugeordnet, welches direkt auf das Objekt zeigt, als welches es erstellt wurde. Falls diese Zuordnung nicht existiert, wird ein temporäres CWnd-Objekt erzeugt, welchem das HWND zugeordnet wird.

Erst mal vielen Dank für die Antwort. Am Anfang hattest Du aber geschrieben das es sich um das CWnd handelt das on der Klassenhirachie des MFCControls (ok in diesem Speziellen fall das Prograssdings) handelt. Nun zeigst Du quelltext der Zeigt das es sich nicht um das CWnd handelt sondern um eines das temporär erzeugt wird. (Somit geht der dynamic_cast nicht und es ist das der Fall was weiter oben diskutiert wurde). Das mit der Handlemap hab ich nach suchen ebenfalls gefunden und genau das irritiert mich nun stark da es doch irgendwie niht zusammenpasst

Wenn wir das eventuell nich klären könnten... Hätt ich es vllt. komplett verstanden und kann es nachvollziehen. Denn das irritiert mich denn nun doch.

@Shagy

Die Lösung für das ganze sähe z.B. so aus das Control als variable anzulegen (ctrl + doppelklick auf das MFC Control z.B. ProgressBar) und mit DDX_Control
arbeiten. (Kann gerne mal ein kleines Beispiel schreiben das zeigt wie ich es bisher machte....)

@ll auf jedenfall schon mal thx das ihr nicht aufgebt es mir zu erklären

[ Dieser Beitrag wurde am 31.03.2003 um 08:59 Uhr von Knuddlbaer editiert. ]

RenéG

@Knuddelbaer
Das mit dem DDX_Control ist uns allen bekannt.

Nachteil dieser Methode:
- +1 Zeile für Membervariable in Headerdatei
- +1 Zeile in der DoDataExchange-Methode
- Subclassen des Controls->neue WindowProc, die gar nicht benötigt wird.

Und das alles nur, weil ich irgendwo eine Methode habe, die den Fortschrittsbalken per SetPos oder StepIt aktivieren soll?

[ Dieser Beitrag wurde am 31.03.2003 um 09:15 Uhr von RenéG editiert. ]

RenéG

?? Was passt nicht zusammen ??

Wurde das Objekt angelegt und initialisiert, so steht der 'echte' Zeiger in der HandleMap der MFC. Dann funzt auch ein dynamic_cast!
Aber, wenn dieses Objekt existiert, wozu brauche ich dann noch ein GetDlgItem? Dann kann ich ja gleich direkt zugreifen!
2.
Gibt es kein passendes Control, wird ein temporäres CWnd angelegt, welches einfach nur das HWND kapselt und ein paar einfachere Funktionen statt API bereitstellt. Der this-Zeiger kann durchaus benutzt werden. Die aufgerufenen Funktionen des Controls, auf das gecastet wird, dürfen allerdings NUR das HWND das CWnd betreffen.

Knuddlbaer

Hm, ich glaub so langsam raff ich es *juhu endlich ?! *

Also:

Wenn ich das COntrol mit dem DDX Krempel anlege bekomm ich das CWnd aus der Handlemap.

In allen anderen Fällen nur ein temporäres CWnd ?

Die aufgerufenen Funktionen des Controls, auf das gecastet wird, dürfen allerdings NUR das HWND das CWnd betreffen

Hm, wie kann ich das zuverlässig rausbekommen ?

thx

Shaggy

Gibt es kein passendes Control, wird ein temporäres CWnd angelegt, welches einfach nur das HWND kapselt und ein paar einfachere Funktionen statt API bereitstellt. Der this-Zeiger kann durchaus benutzt werden. Die aufgerufenen Funktionen des Controls, auf das gecastet wird, dürfen allerdings NUR das HWND das CWnd betreffen.

Und so wie ich das sehe (siehe meine irgendwo weit vorher gezeigten MFC-Source-Auszüge) macht ein CProgressCtrl nix anderes, als Nachrichten an das CWnd (HWND) zu schicken. Also klappt auf jeden Fall ein (CProgressCtrl*)(GetDlgCtrl(ID_MYCTRL)), oder? Aber beim dynamic_cast geht's wieder nicht? Und wie ist es mit static_cast?

Also, ganz ehrlich, bevor ich mich tagelang mit dynamic_cast rumärgere, mache ich meinen FWuW-Cast!

Shaggy

@Knuddlbaer:

Schau in die MFC-Sourcen (siehe z.B. irgendwo weit oben). Und wenn es ein Standard-WinDoof-Control ist, gibt's grundsätzlich keine eigenen Member-Variablen.

RenéG

In allen anderen Fällen nur ein temporäres CWnd ?

Nein, erst wird natürlich geschaut, ob es in der permanenten HandleMap schon das Handle gibt!

Die aufgerufenen Funktionen des Controls, auf das gecastet wird, dürfen allerdings NUR das HWND das CWnd betreffen.

Hm, vielleicht mit 'sizeof(CProgressCtrl)==sizeof(CWnd)'

Also, ganz ehrlich, bevor ich mich tagelang mit dynamic_cast rumärgere, mache ich meinen FWuW-Cast!

Ganz davon abgesehen, dass die Laufzeitinformationen, die ich bei API- und MFC-Programmierung eh nur höchst selten benötige, die Executable unverhältnismässig aufblähen.

[ Dieser Beitrag wurde am 31.03.2003 um 09:46 Uhr von RenéG editiert. ]

Shaggy

@ReneG:

Richtig, daran hab ich auch schon gedacht. Was würde ein Sortieralgorithmus für 1.000.000 Elemente mit Verwendung von dynamic_cast wohl länger brauchen?

RenéG

Keine Ahnung, allerdings würde ich für solche Aufgaben eher folgenden Konstrukt verwenden:

B* b;
#ifdef _DEBUG
  b = dynamic_cast<B*>( a);
#else
  b = reinterpret_cast<B*>( a);
#endif

oder:

#ifdef _DEBUG
  #define MYCAST( class, ptr) (dynamic_cast<class*>( ptr));
#else
  #define MYCAST( class, ptr) (reinterpret_cast<class*>( ptr));
#endif

[ Dieser Beitrag wurde am 31.03.2003 um 09:59 Uhr von RenéG editiert. ]

lol

Knuddlbaer

Hm,

ich hab mir den Source mal angeschaut, es gibt wirklich ne Handvoll Klassen die keine Member haben.

Ich darf also bei jedem Zugriff dieser Art prüfen ob es legal ist, auch bei jeder neuen Version der MFC (Microsoft is für alles gut

Ich fühle mich dabei dann unsicher vorallem weil ich bei jedem Control was mir über den Weg läuft prüfen darf ob das geht - und das bei jeder neuen Version.

@Shagy so pauschal wie Du es sagst würde ich sagen das die Kosten des einmaligen Casts bei der Sortierung der 1.000.000 Elemente nicht im verhältnis steht.

So eine Frage hab ich noch an Rene,

wann taucht das CWnd denn in der HandleMap nun auf ?!

thx @ll für die geduld - es hat einiges an Wissen mit sich gebracht

Shaggy

Also gehe ich recht in der Annahme (hoffentlich diesmal ), dass reinterpret_cast und der ()-cast genau das gleiche machen?

Und static_cast castet nur zwischen Zeigertypen die in einer Klassenhierarchie untereinanderstehen, aber ohne Runtime-Checking, während dynamic_cast das gleiche macht, nur mit Runtime-Checking?

Shaggy

@Knuddlbaer:

Wenn ich eine Sortierfunktion vom Typ

int CMyList::Sort(CBase* p1, CBase* p2)
{
}

habe und ich bei jedem Aufruf zweimal dynamic_cast machen muss, dann wird es sicherlich schon einen Unterschied geben. Zumal bei 1.000.000 Elementen diese Funktion wohl etwas häufiger aufgerufen werden wird. Allerdings kann es natürlich sein, dass das checken recht schnell geht. Keine Ahnung, war nur 'ne Idee.

Bei Standard-WinDoof-Controls gibt es - wie gesagt - grundsätzlich keine eigenen Member-Variablen, bei anderen normalerweise schon. Du musst ja nur in die Header-Datei schauen, ob es Member-Variablen gibt oder nicht. Und das geht schnell.

Wenn das Steuerelement von den MFC erstellt wurde, dann befindet sich auch ein Eintrag in der Handle-Map mit einem Zeiger auf das wirkliche Objekt. Dann ist ein Cast doch völlig legal. (static_cast<> )

RenéG

@Knuddelbaer

wann taucht das CWnd denn in der HandleMap nun auf ?!
Wenn das Fenster erstellt( Create) oder subclassed (SubclassWindow) wird!
@Shaggy
[quote]
während dynamic_cast das gleiche macht

Nicht ganz, bei Standardtypen int/char ... funzt dynamic_cast net.

wann taucht das CWnd denn in der HandleMap nun auf ?!

Nach dem es erstellt wurde.

RenéG

@cole
3x den gleichen Beitrag brauchen wir nicht

Doch

Knuddlbaer

wann taucht das CWnd denn in der HandleMap nun auf ?!
Wenn das Fenster erstellt( Create) oder subclassed (SubclassWindow) wird!

Ich glaub hier steh ich einfach nur auf'm schlauch und komm allein nich runter.

Über SubClass weiß ich nix. *gleich mal zugeb - ich kenn mich mit MFC kaum aus, da bin ich noch noob*

Aber create - wird das nicht generell aufgerufen wenn ein Control erstellt wird ?

@Shagy

Wenn ich eine Sortierfunktion vom Typ

int CMyList::Sort(CBase* p1, CBase* p2)
{
}

Der Sortieralgo arbeitet i.d.r. mit operatoren. Wenn die Klassen vererbt wurden und die RTTI an ist wird auch der passende operator aufgerufen. Wenn die RTTI nicht an ist kann es wieder zu undefinierten bzw. zu falschen sortierergebnissen kommen ?!

Ich kenne die sortierung der List nicht in der implementierung. Sie könnte z.B. durch den operator < realisiert sein. Und der könnte für CDerived das in der Liste gehalten wird anderst funktionieren als in CBase - eventuell virtual.

Bei eingeschalteter RTTI kein Problem , ohne RTTI schwer zu durchblicken ?!

[ Dieser Beitrag wurde am 31.03.2003 um 10:41 Uhr von Knuddlbaer editiert. ]

Immer wenn CWnd::Attach aufgerufen wird