Klar kann man das auch in einer
Unit kapseln, aber im Grunde würde sogar eine INCLUDE-Datei reichen. Das basiert ja alles auf Werten der
Unit "Forms". Weil dafür bei Delphi 1 die
Unit "Multimon" fehlt, hatte ich dann daraus die weiter vorne in einem Beispiel enthaltene
Unit "MMM" gebastelt, die auch mit Delphi 1 funktioniert. Wenn man also die Direktzugriffe in eine eigene
Unit kapseln will, reicht es, die Initalisierung und Freigabe von "MyMonitor" (das ist vom Typ "TMonitor" der
Unit "Forms") vorzunehmen und die in meinen Beispielen direkt auf die RadioGroups gesetzten Ergebnisse eben entsprechend der eigenen Bedürfnisse anzupassen. Das sind doch nur reine Abfragen dessen, was "Forms" schon selbst automatisch zur Verfügung stellt.
Was "askuser" betrifft, so gibt es da jetzt tatsächlich einen Fehler. Das liegt an der Reihenfolge der Zuweisungen hinsichtlich der neuen RadioGroup3.
Ändere "FormShow" mal so:
Delphi-Quellcode:
procedure TBaseForm.FormShow(Sender: TObject);
var
s: string;
m: integer;
begin
MyMonitor:=TMonitor.Create;
s:=' Monitor';
GetMonitors;
m:=Screen.MonitorCount;
RadioGroup3.visible:=m>1;
RadioGroup3.ItemIndex:=0; // sicherheitshalber erster Monitor ?
RadioGroup1.ItemIndex:=0; // sicherheitshalber erster Monitor ?
// RadioGroup1.ItemIndex:=m-1; //letzter Monitor
IF m>1 THEN if askuser // global
THEN Start_Mon; // = Benutzer wählen lassen !
RadioGroup2.visible:=m>1;
RadioGroup2.ItemIndex:=0; // sicherheitshalber erster Monitor ?
if m>1 then s:=s+'e';
Caption:=IntToStr(m)+s;
Form2.Show;
end;
Dann wird der ItemIndex für RadioGroup3 vor dem für RadioGroup1 gesetzt. Wenn die Zuweisungen für Form2 auch vorgezogen werden, würde Form2 bereits vor der Abfrage (also auch vor der Sichtbarkeit der Hauptform) gezeigt.
In ein paar Tagen habe ich hoffentlich verbesserte Möglichkeiten und mehr Zeit, das zu verfeinern. Beispielsweise habe ich ja auch keine dynamische Höhenanpassung der Radiogroups drin, die entsprechend der Monitoranzahl nötig wäre. Bei der momentanen fest eingestellten Höhe könnte man schon ab ca. 4 oder 5 Monitoren nichts mehr lesen, weil alles zusammen gequetscht wäre.
Außerdem müßte man noch berücksichtigen, daß der Anwender natürlich die Forms auch unabhängig vom jeweiligen Monitor manuell verschieben können will. Die geänderten Relativpositionen müßten dann natürlich angepaßt werden. Wenn die Monitore unterschiedliche Grafikauflösungen haben, muß dafür gesorgt werden, daß die Forms nicht im Nirvana verschwinden, sondern dann zumindest in den noch sichtbaren Bereich verschoben werden. Aber das sind alles Ausgestaltungen und haben mit der reinen Funktionalität, etwas auf einem bestimmten Monitor zu platzieren, nichts mehr zu tun.
Im Grunde steht doch alles Wesentliche im Typ "TMonitor" drin. Es kommt also allenfalls darauf an, Schnittstellen bereitzustellen, mit denen das Hauptprogramm dann kommunizieren kann. In meinem Beispiel sind das die Radiogroups, weil dadurch die Umschaltung erfolgt. Natürlich kann man die Zuweisung auch in Prozeduren kapseln, vielleicht sogar besser in Funktionen (wegen der Möglichkeit z.B. eines Rückgabewerts "FALSE") ...
Aber erzähl doch mal, was Du gekapselt haben willst, bzw. auch wie.
Die Sache mit nicht gefundenen Resourcen läßt sich in der Regel per Übergabeparameter regeln. Das mit "ShowModal" läßt sich wohl auch noch rausfinden, aber ich würde sowas eher mit FormStyle "fsStayOnTop" und BorderStyle "bsToolWindow" machen, wie z.B. bei diversen Grafikprogrammen.
Mir ging es ja mit dem Beispiel nur drum, zu zeigen, daß die eigentliche Umschaltung auch sehr einfach erfolgen kann. Wirklich komplexe Multimonitoranwendungen mit echter Funktionalität könnten auch gut als Gemeinschaftprojekte mehrere Beteiligter zustandekommen.