MDI Fenster verbergen

Und wieso? Auch das ChildWindow hat die Eigenschaft Visible. Man muß es nur dereferenzieren:

TmyChild* myChild = dynamic_cast<TmyChild*>(ActiveMDIChild);
  if (myChild != NULL)
  {
    myChild->Visible = false;
  }

Wenn es nicht das aktive Child betreffen soll, muß man es über den internen Zähler dereferenzieren (TControl). Einen anderen Weg wüßte ich auch nicht.

Indirekt kann man das Prob ggf. lösen, indem man ein anderes Child in den Vordergrund ruft (eigentlich der übliche Weg). Entweder via Previous(), Next() oder (bei Fenstern nicht getestet) myControl->BringToFront(). Aber immer dereferenzieren, sonst wird eine Exeption ausgelöst.

wilfrid

Es soll das aktive Child betreffen..
ich will aus Zeitgründen einige Fenster im Hintergrund schon generieren,
aber noch unsichtbar halten...
Beim MDIChild bekomme ich aber die Meldung, daß ich das nicht darf !
"Untergeordnetes MDI-Fenster kann nicht verborgen werden"
(selbst im BCB beim Erstellen, also NICHT zur Laufzeit, sondern im Objektinspektor)

Sorry, hab es halt nie probiert. Ich öffne die Fenster immer nach Bedarf. Wüßte jetzt auch keinen Nutzen von einer Vorhaltung.

Bereite doch die Fenster soweit vor, wie es die Situation erfordert.

myControl->Show();

sagst du erst, wenn es gebraucht wird. Mit Vorbehalt, auch das hab ich nicht getestet.

-Aber Zeitgründe wären eher bei älteren Maschinen und ggf. sehr umfangreichen Fenstern denkbar. Ist der Vorteil der Vorbereitung wirklich so gravierend? Ein Blitz, und es ist da. Hab nur eine mittlere Maschine mit 800-er Duron. Ist aber alles situationsabhängig.

wilfrid

ja auf den ersten Blick richtig...
ich bin dabei eine DB-App zu schreiben und will das Fenster so ungefähr als "Suchfenster" nutzen... dazu lade ich zur Zeit beim SuchenEreignis ein MDI-Fenster das dann dynamisch den DB-Aufbau ins Fenster bringt...
.. und das ist grottenlahm !!
->siehe Thread DBGrid Performance ..

trotzdem danke für die Bemühungen
Wilfrid

Oh ja. Bei größeren Datenbeständen ist einfache Datenverwaltung schon ein ziemliches Handicap. Hab damit nur beim Einstieg 'ne Weile gespielt. Dann sah ich schon die Grenzen der Möglichkeiten. Weiß nicht warum, aber ich hatte ohne jede Ahnung bereits eine relationale Lösung im Visier - wenn auch nur vage. Hab mal kurz in mySQL reingeschnüffelt und eine Tabellenstructur erstellt. Da bestehen die Möglichkeiten, die gebraucht werden. Jede Eigenschaft für sich, kurze Suchwege. Oder ODBC... kostet aber.

Was kann in der Situation die Vorbereitung bringen? Die meiste Zeit wird doch durch Suchen verbraucht. Bzw. kannst du einlesen lassen, was bereits gefunden wurde? Das könnte dann ggf etwas Zeit sparen.

JeGr

Seh ich ähnlich wie Omega-X.

Das meiste an Performance kannst du echt in der DB selbst heraus holen (sofern du die Möglichkeit dazu hast),
also Optimierung der einzelnen Tabellen (Stichwort normalisieren).

Ansonsten wird dir wohl nur der Weg bleiben, die Daten anders darzustellen (StringGrid, ListView etc).
Dadurch könntest du dann eben "verzögert" die Daten anzeigen (also nicht in einem Rutsch, sondern über mehrere Zeitpunkte verteilt, vielleicht könnte man dies sogar Thread-gesteuert angehen...)

junix

Für gewöhnlich benutzt man für kurzzeitig einzublendende Fenster wie z.B. einen Such-Dialog in MDI apps ein normales Formular auf einem modalen Style.. (ganz wies hald benötigt wird). Da brauchste kein MDI-Fenster für. Würde auch gegen des Gedanken des MDI verstossen.

Ein MDI soll eigentlich nur die Möglichkeit bieten, mehrere Dokumente zu öffnen und anzuzeigen. Sprich alles gleiche Fenster. Für alles andere sind spezielle Dialoge gefragt.

...soweit die Theorie (-;

-junix

Du benutzt ja 'ne mySQL. Die Teilchen haben ansich die edle Eigenschaft, schon recht schnell zu sein. Sehr viel Foren usw. laufen auf solchen Datenbanken. Der Zugriff ist eigentlich blitzschnell, da in den Tabellen parallel gesucht wird.

Erst mal muß die Tabellenstruktur optimiert sein. Keine Datensätze verwalten, das kann jede Datenverwaltung. Leg für jedes Detail eine eigene Tabelle an. Die Zuordnungen sind nicht starr verbunden sondern nur verknüpft (ID).

Dann richte für jeden Haupteinsatzfall eine Maske ein. Leere Maskengruppen wechseln geht via Visible total schnell. Dann brauchst du genügend Connect, sollte aber das kleinste Prob sein. Jedes Element kann seine Daten separat anfordern.

Die Steuerung im Verbund kann von jedem Element aus erfolgen. Die Abhängigkeiten sind verknüpft, über die ID suchen sie alle gleichzeitig.

So in Etwa. Beim "Kleingedruckten" kommt es halt auf die Aufgabenstellung an. Nur jeweils einzelne Daten wie in der Personalverwaltung, Bilder, Bilderserien, ganze Listen ggf. zur weiteren Auswahl... das muß man raustüfteln.

Auf jeden Fall sollte sich die Geschichte ziemlich optimieren lassen. Und wie gesagt, alles steht und fällt von Vornherein mit einen sinnvollen und richtigen Tabellenaufbau.

wilfrid

Danke für die Anregungen..

mySQL ist seit 2 Jahren meine erste Wahl bei DB-Apps , da kann ich den
Beitrag von Omega-X nur bestätigen....
Was auch hier bei meinem Problem die Sache langsam macht ist das DBGrid,
da die Daten leider lange nicht so schnell verarbeiten kann wie's die DB
hergibt..!

Ich hatte in meinem Fenster noch mit einer ComboxBox rumexperientiert,
das ist eher noch langsamer als die DBGrids... seit ich die rausgeworfen
habe gehts ein bischen besser mit der Performance...

Wilfrid

*MalInsBlaueSchieß*:

Eine Schleife könnte die Daten abrufen und sie jeweils direkt in die Zeilen einer Strinliste/Memo/Editfelder plazieren.

Bei einem Spaltenaufbau wäre das je Spalte eine Liste. Entsprechend bei ungeordnetem, formularartigem Aufbau.

Mit Bildern würde ich es auch auf die Art versuchen. Strings und Bilder können auch parallel abgefragt werden (in der gleichen Schleife).

Die Schleife ist blitzschnell. Könnte sowas klappen?