CSANecromancer
Erfahrenes Mitglied
Eine Warnung vorweg:
Mein Problem ist grundlegend designtechnischer Natur, daher kann ich keinen echten Source angeben. Leider habe ich auch nicht genügend Webspace zur Verfügung um jeden einzelnen Problemschritt grafisch zu veranschaulichen, aber ich werde versuchen, mich so klar wie nur irgendwie auszudrücken.
Gegeben sei folgendes (theoretisch einfaches) Problem:
Ich habe ein Programm (erstellt mit dem CBuilder 5), daß auf eine Datenbank zugreift. Dieses Programm soll jetzt in der Lage sein z.B. aus dem Datenbestand eine Kundenliste zu extrahieren und am Bildschirm anzuzeigen. Zusätzlich soll die Kundenliste sortierbar sein, ausgedruckt werden können etc.pp., was halt alles so dazu gehört.
Das Programm soll über ein Hauptmenü (z.B. Datei->Drucker einrichten, Ansicht->Kundenliste, Hilfe->Index, Hilfe->Info usw.) verfügen, genauso würde ich gerne eine Leiste mit Schnellbuttons anlegen, die je nach Funktionalität sichtbar/unsichtbar bzw. aktiviert/deaktiviert sind (z.B. wären bei der Kundenliste die Buttons "Drucken", "Sortieren" aktiviert, "Ansicht Kundenliste" wäre zwar sichtbar aber deaktiviert). Auch eine Statusleite, die z.B. die Anzahl der gefundenen Datensätze oder den Bearbeitungsstatus eines einzelnen Datensatzes anzeigt wäre ideal.
Doch wie setze ich das Ganze am Besten um, vor allem, wenn das Programm weitere Eingabemasken enthalten soll?
ACHTUNG! BEVOR MIT DEM LESEN BEREITS AUFGEHÖRT WIRD!
Versteht mich nicht falsch, mir geht es beileibe nicht um die Implementierung der einzelnen Routinen. Mein Problem ist Folgendes:
Möglichkeit 1:
Ich bastel eine ganz normale SDI-Anwendung, d.h. ich habe ein Hautpfenster, fertig, aus. Innerhalb dieses Hauptfensters muß sich alles abspielen. Dazu könnte ich die Inhalte aller Bildschirmmasken (Kundenliste, Details eines Kundensatzes) auf einzelnen Panels ablegen, die ich aktiviere oder deaktivere. Das Hauptfenster würde das Menü, die Schnellbuttons und die Statusleiste beinhalten. Rein theoretisch eine durchaus machbare Möglichkeit, an der mir aber zwei Punkte nicht gefallen:
a) Das Einrichten der einzelnen Panels für die einzelnen Bildschirmmasken wäre, gelinde gesagt, die reinste Tierquälerei und die Erweiterbarkeit des Programms würde drastisch sinken, u.a. auch deswegen, weil die maximale Anzahl von Objekten innerhalb eines Formulars begrenzt ist.
b) Es muß doch einfach eine Möglichkeit geben, das eleganter zu lösen.
Möglichkeit 2:
Ich mache eine MDI-Anwedung. Wiederum würde das Hauptfenster die Hauptsteuerelemente (Menüleiste, Mausbuttons, Statusleiste) beinhalten, die einzelnen Bildschirmmasken wären MDI-Formulare. Dabei gefällt mir aber ganz und gar nicht, daß jedes MDI-Formular (in diesem Falle jede Bildschirmmaske) seinen eigenen Fensterrahmen hat und daß der Zugriff der MDI-Formulare auf Funktionen des Hauptfensters nur äußerst schwer zu realisieren ist. Außerdem soll das Programm ja nicht mehrere Dokumente verwalten, sondern nur verschiedene Bildschirmmasken haben.
Möglichkeit 3:
Ich mache eine SDI-Anwedung und jede Bildschirmmaske ist ein eigenes Formular. Klingt für mich ziemlich logisch und vernünftig, hat jedoch wieder ein paar Schönheitsfehler: Das Hauptformular muß (auch bei allen anderen Möglichkeiten) permanent aktiv sein, egal ob es sichtbar ist oder nicht. Das stört ja auch nicht weiter. Wird vom Hauptformular aus auf andere Bildschirmmasken verzweigt, dann lässt sich das mit Hilfe einer public Routine im Hauptformular lösen, welche dem neu aufzurufenden Formular solche Dinge wie x/y-Position und Größe mitteilt. Das funktioniert auch ganz famos. Aber...
a) Wenn das Programm minimiert wird, dann gibt es Probleme. Von der Hauptmaske aus - alles Bestens. Das Programm wird minimiert und erscheint nur noch in der Taskleiste, beim erneuten Aktivieren ist es wieder da. Befinde ich mich jedoch in einer anderen Bildschirmmaske als dem Hauptformular, dann hat auch diese Bildschirmmaske den Fokus und wenn ich sie minimiere, wird sie minimiert innerhalb der Hauptmaske
angezeigt. Mit anderen Worten: Das Hauptformular ist immer noch aktiv, voll auf dem Bildschirm (wenn auch unsichtbar) und die minimierte Bildschirmmaske klebt irgendwo mitten auf dem Desktop herum statt in der Taskleiste. Durchaus lösbar wäre das noch über eine Routine, die im Bedarfsfall nicht die angezeigte Bildschirmmaske sondern stattdessen das Hauptprogramm minimiert. Aber selbst dann bleibt noch
b) Sowohl auf den Formularen als auch in den Sources müsste ich die Steuerelemente Menüleiste, Schnellbuttons und Statusleiste jeweils separat implementieren. Dank copy&paste nicht so der unglaubliche Aufwand doch für meinen Geschmack eine Redundanz sondergleichen und Verschwendung von Ressourcen.
Möglichkeit 4:
Ich realisiere das Programm mit Hilfe von Frames. Damit komme ich dem Gewünschten noch am nächsten. Das Hauptfenster beinhaltet Menü, Schnellbuttons und Statusleiste, die einzelnen Bildschirmmasken sind Frames innerhalb des Hauptfensters, die ich je nach Belieben laden kann, beim Minimieren wird auch wirklich das gesamte Programm minimiert ohne daß ein "unsichtbarer Rest" aktiv bleibt, ich kann die Frames wie Formulare separat anlegen und designen, der Zugriff der Frames auf Funktionen des Hauptfensters stellt kein Problem dar. Eigentlich könnte ich mit dieser Möglichkeit voll und ganz zufrieden sein.
Wenn mir nicht der Focus einen Strich durch die Rechnung machen würde.
An und für sich ist das alles nicht so tragisch. Ich kann auf Eingabefelder des Frames zugreifen, das Menü des Hauptfensters bedienen, die Schnellbuttons anklicken, funktioniert alles fehlerfrei. Doch sobald ich eine automatische Funktion des Hauptfensters aktiviere, bekomme ich danach den Fokus nicht mehr ohne Probleme auf den Frame.
Aktuelles Beispiel:
Mir wird im Frame die Bildschirmmaske für die Kundenliste angezeigt. Diese Bildschirmmaske/dieser Frame beinhalten nicht nur ein DBGrid mit den Daten sondern auch Eingabefelder für Sortierparameter und einen Button um eine Sortierung zu aktivieren. Es funktioniert zunächst alles Bestens. Ich kann die angezeigte Kundenliste auf einen bestimmten Kundenstamm einschränken und er wird mir angezeigt.
Klicke ich jetzt auf den Schnellbutton für "Drucken", der im Hauptfenster liegt, dann wird die Liste auch wunderbar ausgedruckt, komplett gemäß der angegebenen Sortierparameter. Nach dem Druck sage ich im Source des Hauptfensters FMKundenliste->EingabefeldName->SetFocus(), damit der Fokus wieder auf das Eingabefeld für den Sortierparameter Name im angezeigten Frame gelegt wird. Aber der Fokus wird nicht darauf gelegt. Nachdem die Liste gedruckt worden ist, liegt der Fokus quasi im Nirwana. Wenn ich das Eingabefeld Name explizit anklicke funktioniert alles fehlerfrei.
Daher hier meine Frage:
Wie kann ich nach Aufruf einer Funktion des Hauptfensters den aktuellen Fokus des Programms wieder auf ein Element des angezeigten Frames legen und/oder den angezeigten Frame aktualisieren?
Ich hoffe mein Problem und die dazu gehörende Frage kamen einigermaßen verständlich rüber.
Mein Problem ist grundlegend designtechnischer Natur, daher kann ich keinen echten Source angeben. Leider habe ich auch nicht genügend Webspace zur Verfügung um jeden einzelnen Problemschritt grafisch zu veranschaulichen, aber ich werde versuchen, mich so klar wie nur irgendwie auszudrücken.
Gegeben sei folgendes (theoretisch einfaches) Problem:
Ich habe ein Programm (erstellt mit dem CBuilder 5), daß auf eine Datenbank zugreift. Dieses Programm soll jetzt in der Lage sein z.B. aus dem Datenbestand eine Kundenliste zu extrahieren und am Bildschirm anzuzeigen. Zusätzlich soll die Kundenliste sortierbar sein, ausgedruckt werden können etc.pp., was halt alles so dazu gehört.
Das Programm soll über ein Hauptmenü (z.B. Datei->Drucker einrichten, Ansicht->Kundenliste, Hilfe->Index, Hilfe->Info usw.) verfügen, genauso würde ich gerne eine Leiste mit Schnellbuttons anlegen, die je nach Funktionalität sichtbar/unsichtbar bzw. aktiviert/deaktiviert sind (z.B. wären bei der Kundenliste die Buttons "Drucken", "Sortieren" aktiviert, "Ansicht Kundenliste" wäre zwar sichtbar aber deaktiviert). Auch eine Statusleite, die z.B. die Anzahl der gefundenen Datensätze oder den Bearbeitungsstatus eines einzelnen Datensatzes anzeigt wäre ideal.
Doch wie setze ich das Ganze am Besten um, vor allem, wenn das Programm weitere Eingabemasken enthalten soll?
ACHTUNG! BEVOR MIT DEM LESEN BEREITS AUFGEHÖRT WIRD!
Versteht mich nicht falsch, mir geht es beileibe nicht um die Implementierung der einzelnen Routinen. Mein Problem ist Folgendes:
Möglichkeit 1:
Ich bastel eine ganz normale SDI-Anwendung, d.h. ich habe ein Hautpfenster, fertig, aus. Innerhalb dieses Hauptfensters muß sich alles abspielen. Dazu könnte ich die Inhalte aller Bildschirmmasken (Kundenliste, Details eines Kundensatzes) auf einzelnen Panels ablegen, die ich aktiviere oder deaktivere. Das Hauptfenster würde das Menü, die Schnellbuttons und die Statusleiste beinhalten. Rein theoretisch eine durchaus machbare Möglichkeit, an der mir aber zwei Punkte nicht gefallen:
a) Das Einrichten der einzelnen Panels für die einzelnen Bildschirmmasken wäre, gelinde gesagt, die reinste Tierquälerei und die Erweiterbarkeit des Programms würde drastisch sinken, u.a. auch deswegen, weil die maximale Anzahl von Objekten innerhalb eines Formulars begrenzt ist.
b) Es muß doch einfach eine Möglichkeit geben, das eleganter zu lösen.
Möglichkeit 2:
Ich mache eine MDI-Anwedung. Wiederum würde das Hauptfenster die Hauptsteuerelemente (Menüleiste, Mausbuttons, Statusleiste) beinhalten, die einzelnen Bildschirmmasken wären MDI-Formulare. Dabei gefällt mir aber ganz und gar nicht, daß jedes MDI-Formular (in diesem Falle jede Bildschirmmaske) seinen eigenen Fensterrahmen hat und daß der Zugriff der MDI-Formulare auf Funktionen des Hauptfensters nur äußerst schwer zu realisieren ist. Außerdem soll das Programm ja nicht mehrere Dokumente verwalten, sondern nur verschiedene Bildschirmmasken haben.
Möglichkeit 3:
Ich mache eine SDI-Anwedung und jede Bildschirmmaske ist ein eigenes Formular. Klingt für mich ziemlich logisch und vernünftig, hat jedoch wieder ein paar Schönheitsfehler: Das Hauptformular muß (auch bei allen anderen Möglichkeiten) permanent aktiv sein, egal ob es sichtbar ist oder nicht. Das stört ja auch nicht weiter. Wird vom Hauptformular aus auf andere Bildschirmmasken verzweigt, dann lässt sich das mit Hilfe einer public Routine im Hauptformular lösen, welche dem neu aufzurufenden Formular solche Dinge wie x/y-Position und Größe mitteilt. Das funktioniert auch ganz famos. Aber...
a) Wenn das Programm minimiert wird, dann gibt es Probleme. Von der Hauptmaske aus - alles Bestens. Das Programm wird minimiert und erscheint nur noch in der Taskleiste, beim erneuten Aktivieren ist es wieder da. Befinde ich mich jedoch in einer anderen Bildschirmmaske als dem Hauptformular, dann hat auch diese Bildschirmmaske den Fokus und wenn ich sie minimiere, wird sie minimiert innerhalb der Hauptmaske
angezeigt. Mit anderen Worten: Das Hauptformular ist immer noch aktiv, voll auf dem Bildschirm (wenn auch unsichtbar) und die minimierte Bildschirmmaske klebt irgendwo mitten auf dem Desktop herum statt in der Taskleiste. Durchaus lösbar wäre das noch über eine Routine, die im Bedarfsfall nicht die angezeigte Bildschirmmaske sondern stattdessen das Hauptprogramm minimiert. Aber selbst dann bleibt nochb) Sowohl auf den Formularen als auch in den Sources müsste ich die Steuerelemente Menüleiste, Schnellbuttons und Statusleiste jeweils separat implementieren. Dank copy&paste nicht so der unglaubliche Aufwand doch für meinen Geschmack eine Redundanz sondergleichen und Verschwendung von Ressourcen.
Möglichkeit 4:
Ich realisiere das Programm mit Hilfe von Frames. Damit komme ich dem Gewünschten noch am nächsten. Das Hauptfenster beinhaltet Menü, Schnellbuttons und Statusleiste, die einzelnen Bildschirmmasken sind Frames innerhalb des Hauptfensters, die ich je nach Belieben laden kann, beim Minimieren wird auch wirklich das gesamte Programm minimiert ohne daß ein "unsichtbarer Rest" aktiv bleibt, ich kann die Frames wie Formulare separat anlegen und designen, der Zugriff der Frames auf Funktionen des Hauptfensters stellt kein Problem dar. Eigentlich könnte ich mit dieser Möglichkeit voll und ganz zufrieden sein.
Wenn mir nicht der Focus einen Strich durch die Rechnung machen würde.
An und für sich ist das alles nicht so tragisch. Ich kann auf Eingabefelder des Frames zugreifen, das Menü des Hauptfensters bedienen, die Schnellbuttons anklicken, funktioniert alles fehlerfrei. Doch sobald ich eine automatische Funktion des Hauptfensters aktiviere, bekomme ich danach den Fokus nicht mehr ohne Probleme auf den Frame.
Aktuelles Beispiel:
Mir wird im Frame die Bildschirmmaske für die Kundenliste angezeigt. Diese Bildschirmmaske/dieser Frame beinhalten nicht nur ein DBGrid mit den Daten sondern auch Eingabefelder für Sortierparameter und einen Button um eine Sortierung zu aktivieren. Es funktioniert zunächst alles Bestens. Ich kann die angezeigte Kundenliste auf einen bestimmten Kundenstamm einschränken und er wird mir angezeigt.
Klicke ich jetzt auf den Schnellbutton für "Drucken", der im Hauptfenster liegt, dann wird die Liste auch wunderbar ausgedruckt, komplett gemäß der angegebenen Sortierparameter. Nach dem Druck sage ich im Source des Hauptfensters FMKundenliste->EingabefeldName->SetFocus(), damit der Fokus wieder auf das Eingabefeld für den Sortierparameter Name im angezeigten Frame gelegt wird. Aber der Fokus wird nicht darauf gelegt. Nachdem die Liste gedruckt worden ist, liegt der Fokus quasi im Nirwana. Wenn ich das Eingabefeld Name explizit anklicke funktioniert alles fehlerfrei.
Daher hier meine Frage:
Wie kann ich nach Aufruf einer Funktion des Hauptfensters den aktuellen Fokus des Programms wieder auf ein Element des angezeigten Frames legen und/oder den angezeigten Frame aktualisieren?
Ich hoffe mein Problem und die dazu gehörende Frage kamen einigermaßen verständlich rüber.
