Wie groß ist ein Formular wirklich?
Michael König
ich habe ein Verständnisproblem, in das ich mich mittlerweile ziemlich
verrannt habe: wie groß ist ein Formular "außen"? Ich meine damit
folgendes: in VBA kann man die Höhen der einzelnen Formularbereiche
abholen und summieren, und ich war der Meinung, da müsste das selbe
rauskommen wie bei der Eigenschaft "Me.InsideHeight", is' aber nich'.
Dann kommen noch die Höhen von Symbolleiste(n) und Menüzeile(n) dazu,
aber wieviele und welche sind sichtbar (mit GetSystemMetrics bekommt man
die Höhen einzeln, aber man weiß doch zunächst nicht, welche Zeilen
sichtbar sind). Schließlich kommen noch die "Höhen" der Ränder dazu, und
das alles ergibt die "äußere" Höhe eines Formulars. Ähnliches gilt wohl
auch für die "äußere" Breite eines Formulars. Aber wie ermittle ich
jetzt tatsächlich die äußeren Abmessungen eines Formulars?
Vielen Dank im voraus für Eure Hilfe.
Einen schönen Feiertag und Gruß
Michael König
Karl Donaubauer
>
> ich habe ein Verständnisproblem, in das ich mich mittlerweile ziemlich
> verrannt habe: wie groß ist ein Formular "außen"? Ich meine damit
> folgendes: in VBA kann man die Höhen der einzelnen Formularbereiche
> abholen und summieren, und ich war der Meinung, da müsste das selbe
> rauskommen wie bei der Eigenschaft "Me.InsideHeight", is' aber nich'.
> Dann kommen noch die Höhen von Symbolleiste(n) und Menüzeile(n) dazu,
> aber wieviele und welche sind sichtbar (mit GetSystemMetrics bekommt
> man die Höhen einzeln, aber man weiß doch zunächst nicht, welche
> Zeilen sichtbar sind). Schließlich kommen noch die "Höhen" der Ränder
> dazu, und das alles ergibt die "äußere" Höhe eines Formulars.
> Ähnliches gilt wohl auch für die "äußere" Breite eines Formulars.
> Aber wie ermittle ich jetzt tatsächlich die äußeren Abmessungen eines
> Formulars?
Hast du es schon mit Me.WindowHeight und Me.WindowWidth versucht?
--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com
3. SQL Server-Entwickler-Konferenz - Nürnberg im Mai
Michael König
danke für Deine Antwort (btw: ich hab' es wieder mal vergessen: ich
verwende Access 2000 ;-) )
Karl Donaubauer schrieb:
>
> Hast du es schon mit Me.WindowHeight und Me.WindowWidth versucht?
>
Mit diesen beiden Eigenschaften erhalte ich die Größe des Formulars so
wie es zuletzt angezeigt wurde (jedenfalls habe ich das so verstanden).
Mein Wunsch ist es, das Fenster/Formular so groß anzuzeigen wie es in
den Formulareigenschaften gespeichert ist, also mit der dort
eingetragenen Breite und der Summe der einzelnen Bereiche (plus die
Ränder, Menü- und Symbolzeilen). Ich habe irgendwo gelesen, auf
DoCmd.Maximize zu verzichten, da dies auf alle Fenster wirkt.
Gruß aus dem sonnigen Franken
Michael
Karl Donaubauer
> Karl Donaubauer schrieb:
>>
>> Hast du es schon mit Me.WindowHeight und Me.WindowWidth versucht?
>>
>
> Mit diesen beiden Eigenschaften erhalte ich die Größe des Formulars so
> wie es zuletzt angezeigt wurde (jedenfalls habe ich das so verstanden).
> Mein Wunsch ist es, das Fenster/Formular so groß anzuzeigen wie es in
> den Formulareigenschaften gespeichert ist, also mit der dort
> eingetragenen Breite und der Summe der einzelnen Bereiche (plus die
> Ränder, Menü- und Symbolzeilen). Ich habe irgendwo gelesen, auf
> DoCmd.Maximize zu verzichten, da dies auf alle Fenster wirkt.
Schwer zu interpretieren, was du eigentlich willst.
Die innere Höhe (InsideHeight) passt dir nicht, die äußere Höhe
(WindowHeight) passt dir nicht. Mehr an Formularhöhe gibt es nicht.
Da du von "Menü- und Symbolzeilen" schreibst, die nichts mit der
Formularhöhe zu tun haben, und von Nicht-Maximize, vermute ich
als nächstes, dass du dein Formular innerhalb des Accessfensters
maximieren willst, ohne Maximize zu verwenden. Das macht z.B.
der Code in http://www.mvps.org/access/api/api0022.htm.
Thomas Möller
"Michael König" <m...@its-mkg.de> schrieb:
>> Hast du es schon mit Me.WindowHeight und Me.WindowWidth versucht?
>
> Mit diesen beiden Eigenschaften erhalte ich die Größe des Formulars so wie
> es zuletzt angezeigt wurde (jedenfalls habe ich das so verstanden). Mein
> Wunsch ist es, das Fenster/Formular so groß anzuzeigen wie es in den
> Formulareigenschaften gespeichert ist, also mit der dort eingetragenen
> Breite und der Summe der einzelnen Bereiche (plus die Ränder, Menü- und
> Symbolzeilen). Ich habe irgendwo gelesen, auf DoCmd.Maximize zu
> verzichten, da dies auf alle Fenster wirkt.
mir geht es wie Karl: Ich verstehe Dein Anliegen nicht ganz.
Schau Dir mal bitte den Befehl DoCmd.MoveSize näher an. Damit kannst Du die
Position und die Ausdehnung eines Fensters festlegen.
HTH
--
Thomas
Homepage: www.Team-Moeller.de
Stefan Hoffmann
Michael König schrieb:
> Mein Wunsch ist es, das Fenster/Formular so groß anzuzeigen wie es in
> den Formulareigenschaften gespeichert ist, also mit der dort
> eingetragenen Breite und der Summe der einzelnen Bereiche (plus die
> Ränder, Menü- und Symbolzeilen).
D.h. du willst AutoResize (Größe anpassen = Ja) nicht verwenden?
mfG
--> stefan <--
--
Access-FAQ http://www.donkarl.com/
KnowHow.mdb http://www.freeaccess.de
Newbie-Info http://www.doerbandt.de/Access/Newbie.htm
Michael König
Karl Donaubauer schrieb:
> Michael König wrote:
>> Karl Donaubauer schrieb:
>>>
>>> Hast du es schon mit Me.WindowHeight und Me.WindowWidth versucht?
>>>
>>
>> Mit diesen beiden Eigenschaften erhalte ich die Größe des Formulars so
>> wie es zuletzt angezeigt wurde (jedenfalls habe ich das so verstanden).
>> Mein Wunsch ist es, das Fenster/Formular so groß anzuzeigen wie es in
>> den Formulareigenschaften gespeichert ist, also mit der dort
>> eingetragenen Breite und der Summe der einzelnen Bereiche (plus die
>> Ränder, Menü- und Symbolzeilen). Ich habe irgendwo gelesen, auf
>> DoCmd.Maximize zu verzichten, da dies auf alle Fenster wirkt.
>
> Schwer zu interpretieren, was du eigentlich willst.
> Die innere Höhe (InsideHeight) passt dir nicht, die äußere Höhe
> (WindowHeight) passt dir nicht. Mehr an Formularhöhe gibt es nicht.
>
> Da du von "Menü- und Symbolzeilen" schreibst, die nichts mit der
> Formularhöhe zu tun haben, und von Nicht-Maximize, vermute ich
> als nächstes, dass du dein Formular innerhalb des Accessfensters
> maximieren willst, ohne Maximize zu verwenden. Das macht z.B.
> der Code in http://www.mvps.org/access/api/api0022.htm.
>
nun denn: ich möchte das Access-Fenster(!) in der Größe dem geöffneten
Formular anpassen, ich weiß, ein bisschen ungewöhnlich (?), aber der
Kunde möchte seinen Desktop nicht durch ein zu großes Access-Fenster
teilweise verdeckt sehen. Ich hab' ja gesagt: ein bisschen dämlich und
ein bisschen verrannt, aber der Kunde will es partout so. Beispiel: der
Kunde hat in einer anderen Access-Anwendung sein Access-Fenster in
irgend einer Größe verlassen. Nun startet er eine andere
Access-Anwendung und möchte, dass das Access-Fenster - so wie es zuletzt
verlassen wurde - nicht über das Fenster der neuen Anwendung hinausragt.
Fragt mich bitte nicht, warum, es soll so sein. Ich hoffe, das erklärt
mein Problem ein bisschen deutlicher.
Zu den Menü- und Symbolleisten: Mir ist die Definition von InsideHeight
und WindowHeight schon klar, aber ich glaub(t)e z.B. die Gesamthöhe
eines Formulars errechnen zu können, eben aus InsideHeight + Höhe von
Symbolleiste(n), Menüzeile und Rändern. Ich meine ja auch, ein bisschen
arg auf dem Holzweg zu sein, aber vielleicht ist jetzt irgendwie klarer,
was ich meine.
Gruß Michael
Jens Schilling
Michael König wrote:
> Karl Donaubauer schrieb:
>> Michael König wrote:
>>> Karl Donaubauer schrieb:
> nun denn: ich möchte das Access-Fenster(!) in der Größe dem geöffneten
> Formular anpassen, ich weiß, ein bisschen ungewöhnlich (?), aber der
> Kunde möchte seinen Desktop nicht durch ein zu großes Access-Fenster
> teilweise verdeckt sehen. Ich hab' ja gesagt: ein bisschen dämlich und
> ein bisschen verrannt, aber der Kunde will es partout so.
Kauf Dir einen neuen Kunden ;-)
oder schau, ob Du über diese Demo weiter kommst :
L:\Access\Beispieldatenbanken\Access_Samples\Thomaskessler\access_fenster_groesse_beim_start_festlegen\Access_Fenster_Groesse_beim_Start_festlegen_A97.mdb
( Link in eine Zeile !! )
Statt der darin verwendeten statischen Grössen könnte ich mir vorstellen,
dass man z.B. die Formulargrösse beim Schliessen speichert, und beim
Neustart entsprechend ausliest ....
Gruss
Jens
Jens Schilling
Jens Schilling wrote:
> ( Link in eine Zeile !! )
Der sollte aber so aussehen:
Gruss
Ingrid
Jens Schilling
So sollte er auch nicht aussehen - ich wollte auf die entsprechene Web-Page
verlinken, nicht direkt auf den Download; also noch ein Versuch:
http://www.tksoft-online.de/Downloads/System/View-category.html
Dort zu "Die Größe des Accessfensters beim Start festlegen"
herunterscrollen, und auf Details klicken.
Puhh, ist das schwer, einen Link zu posten ;-)
Gruss
Ingrid
Peter Doering
Michael König wrote:
>
> nun denn: ich möchte das Access-Fenster(!) in der Größe dem geöffneten
> Formular anpassen, ich weiß, ein bisschen ungewöhnlich (?), aber der
> Kunde möchte seinen Desktop nicht durch ein zu großes Access-Fenster
> teilweise verdeckt sehen. Ich hab' ja gesagt: ein bisschen dämlich und
> ein bisschen verrannt, aber der Kunde will es partout so. Beispiel: der
> Kunde hat in einer anderen Access-Anwendung sein Access-Fenster in
> irgend einer Größe verlassen. Nun startet er eine andere
> Access-Anwendung und möchte, dass das Access-Fenster - so wie es zuletzt
> verlassen wurde - nicht über das Fenster der neuen Anwendung hinausragt.
Also, Standardverhalten ist, dass das Accessfenster in der Groesse
geoeffnet wird, in der es zuletzt geschlossen worden ist. Das gilt
natuerlich nicht, wenn du in Anwendung A die Groessen aenderst und /nicht/
schliesst, aber Anwendung B oeffnest. In dem Fall ist das Fenster so gross
wie beim Oeffnen von Anwendung A.
> Zu den Menü- und Symbolleisten: Mir ist die Definition von InsideHeight
> und WindowHeight schon klar, aber ich glaub(t)e z.B. die Gesamthöhe
> eines Formulars errechnen zu können, eben aus InsideHeight + Höhe von
> Symbolleiste(n), Menüzeile und Rändern. Ich meine ja auch, ein bisschen
> arg auf dem Holzweg zu sein, aber vielleicht ist jetzt irgendwie klarer,
> was ich meine.
Fuer dich waere wahrscheinlich A07 ein Segen: das Ribbon ist immer genau 28
mm hoch, wenn es nicht gerade hockgeklappt ist ;-)
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
3. SEK Sa/So 16./17.5.2009, Nürnberg
Peter Doering
Jens Schilling wrote:
>
> Puhh, ist das schwer, einen Link zu posten ;-)
Mit einem Newsreader waere das nicht passiert. <g,d&r>
Gruss - Peter
Karl Donaubauer
> ...
> nun denn: ich möchte das Access-Fenster(!) in der Größe dem geöffneten
> Formular anpassen, ich weiß, ein bisschen ungewöhnlich (?), aber der
> Kunde möchte seinen Desktop nicht durch ein zu großes Access-Fenster
> teilweise verdeckt sehen. Ich hab' ja gesagt: ein bisschen dämlich und
> ein bisschen verrannt, aber der Kunde will es partout so. Beispiel: der
> Kunde hat in einer anderen Access-Anwendung sein Access-Fenster in
> irgend einer Größe verlassen. Nun startet er eine andere
> Access-Anwendung und möchte, dass das Access-Fenster - so wie es zuletzt
> verlassen wurde - nicht über das Fenster der neuen Anwendung hinausragt.
Diese Beschreibung, d.h. den letzten Teil, verstehe ich noch immer
nicht, aber vielleicht tut das ja jemand anderer hier.
> Fragt mich bitte nicht, warum, es soll so sein. Ich hoffe, das erklärt
> mein Problem ein bisschen deutlicher.
> Zu den Menü- und Symbolleisten: Mir ist die Definition von InsideHeight
> und WindowHeight schon klar, aber ich glaub(t)e z.B. die Gesamthöhe
> eines Formulars errechnen zu können, eben aus InsideHeight + Höhe von
> Symbolleiste(n), Menüzeile und Rändern. Ich meine ja auch, ein bisschen
> arg auf dem Holzweg zu sein, aber vielleicht ist jetzt irgendwie klarer,
> was ich meine.
Naa. Falls du auch sonst noch keine hilfreichen Antworten bekommst,
solltest du evtl. nochmal neu ansetzen mit einem Erklärungsversuch,
in dem du schilderst, was du erreichen möchtest. Nicht die Methoden,
sondern, was das Endziel der Bemühungen ist.
Michael König
> Michael König wrote:
>
> nicht, aber vielleicht tut das ja jemand anderer hier.
>
>
> solltest du evtl. nochmal neu ansetzen mit einem Erklärungsversuch,
> in dem du schilderst, was du erreichen möchtest. Nicht die Methoden,
> sondern, was das Endziel der Bemühungen ist.
>
Okay, ich versuch's nochmal anders: es gibt bei dem Kunden eine
Access-Anwendung A und (m)eine Anwendung B. Anwendung A wird ausgeführt
und ordentlich abgeschlossen. Dabei ist das Access-Fenster in irgend
einer Größe gespeichert. Nun wird Anwendung B gestartet mit einem
Start-Formular. Dieses Start-Formular soll nun innerhalb des
Access-Fensters maximiert werden (z.B. mit MaximizeRestoredForm oder mit
DoCmd.Maximize), das Access-Fenster, welches zuletzt evtl. größer als
das Start-Formular von Anwendung B gespeichert wurde, soll aber nicht
über das Start-Formular von Anwendung B hinausragen und damit andere
Teile des Desktop überdecken. Mit anderen Worten: das Access-Fenster
soll "geschrumpft" werden auf die äußeren Abmessungen des
Start-Formulars von Anwendung B. Puh, ich hoffe diese Erklärung ist
verständlicher ;-)
Frohe Ostern an alle
Michael
Thomas Winkler
> Okay, ich versuch's nochmal anders: es gibt bei dem Kunden eine
> Access-Anwendung A und (m)eine Anwendung B. Anwendung A wird ausgeführt
> und ordentlich abgeschlossen. Dabei ist das Access-Fenster in irgend
> einer Größe gespeichert. Nun wird Anwendung B gestartet mit einem
> Start-Formular. Dieses Start-Formular soll nun innerhalb des
> Access-Fensters maximiert werden (z.B. mit MaximizeRestoredForm oder mit
> DoCmd.Maximize), das Access-Fenster, welches zuletzt evtl. größer als
> das Start-Formular von Anwendung B gespeichert wurde, soll aber nicht
> über das Start-Formular von Anwendung B hinausragen und damit andere
> Teile des Desktop überdecken. Mit anderen Worten: das Access-Fenster
> soll "geschrumpft" werden auf die äußeren Abmessungen des
> Start-Formulars von Anwendung B. Puh, ich hoffe diese Erklärung ist
> verständlicher ;-)
Du willst also nicht wirklich die Form-Größe wissen, sondern die Größe
des Access-Fensters? Wenn das (Position und Größe) nicht schon per
nativen Funktionen zu regeln ist, sollte es zumindest mit API-Funktionen
klappen. Du solltest aber weiterhin min Docmd.maximize arbeiten, denn
das hat nur ein "Vollbild" innherhalb des Access-Fensters zur Folge und
keinerlei Einfluss auf das Access-Fenster selbst.
HTH
Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Michael König
Thomas Winkler schrieb:
Du hast es erfasst. Okay, das mit DoCmd.Maximize mache ich, aber jetzt
geht's noch um das Drum Herum: Wie groß muss das Access-Fenster sein,
damit das Formular (möglichst genau) hinein passt? Native Funktionen
hierzu kenne ich nicht, man könnte eben in VBA mit MoveWindow die Größe
einstellen, aber eben wie groß?
Gruß Michael
Oliver Straub
> ... es gibt bei dem Kunden eine Access-Anwendung A und (m)eine Anwendung
> B. Anwendung A wird ausgeführt und ordentlich abgeschlossen. Dabei ist das
> Access-Fenster in irgend einer Größe gespeichert. Nun wird Anwendung B
> gestartet mit einem Start-Formular. Dieses Start-Formular soll nun
> innerhalb des Access-Fensters maximiert werden (z.B. mit
> MaximizeRestoredForm oder mit DoCmd.Maximize), das Access-Fenster, welches
> zuletzt evtl. größer als das Start-Formular von Anwendung B gespeichert
> wurde, soll aber nicht über das Start-Formular von Anwendung B hinausragen
> und damit andere Teile des Desktop überdecken. Mit anderen Worten: das
> Access-Fenster soll "geschrumpft" werden auf die äußeren Abmessungen des
> Start-Formulars von Anwendung
es ist ja schön, dass der Kunde so gute Ideen hat. Das Blöde daran ist nur,
dass sich das mit Access gar nicht ordentlich verwirklichen lässt. Am Ende
wirst Du auf jeden Fall feststellen, dass Du das Problem mit der
Symbolleiste nicht ohne ein Timer-Event-Gewurschtel in den Griff bekommst.
Die Systemleiste wird erst gesetzt, wenn das Formular geöffnet ist. Wird
eine vorhandene Leiste ausgeblendet, bleibt oben der Platz frei, ist es
andersherum, wird das Formular nach unten geschoben und zusätzlich die
Scrollbars eingeblendet...
IMO solltest Du es vergessen, die Größen in Echtzeit zu ermitteln, und statt
dessen mit festen Werten arbeiten. Du weist doch wie groß Dein Startformular
ist, und wie groß das Access-Fenster seien muss. Beim Starten der Anwendung
kannst du dann den gewünschten Zustand einstellen. Du musst halt auch die
Symbolleiste berücksichtigen. (Bin mir aber trotzdem nicht sicher, ob das
überhaupt geht.)
Gruss
Oliver
Klaus Oberdalhoff
Michael König
Klaus Oberdalhoff schrieb:
vielen Dank für Deinen Hinweis. Das Beispiel kannte ich schon und - so
ausführlich und hilfreich es auch ist - es löst mein Problem leider
nicht, da ich die Minimal- und gleichzeitig Maximalgröße des
Access-Fensters bestimmen wollte/will, die erforderlich ist, um ein
geöffnetes Start-Formular vollständig zu enthalten, ohne andere Teile
des Desktop zu verdecken.
Gruß Michael
Klaus Oberdalhoff
> vielen Dank für Deinen Hinweis. Das Beispiel kannte ich schon und - so
> ausführlich und hilfreich es auch ist - es löst mein Problem leider nicht,
> da ich die Minimal- und gleichzeitig Maximalgröße des Access-Fensters
> bestimmen wollte/will, die erforderlich ist, um ein geöffnetes
> Start-Formular vollständig zu enthalten, ohne andere Teile des Desktop zu
> verdecken.
Ich arbeite viel mit tabellenartigen Unterformularen (=Datenblattansicht)
und habe dann die Unterformulare der Bildschirmgröße angepasst, so dass ein
größerer Bildschirm tatsächlich mehr Informationen zeigt.
Auf Kundenwunsch habe ich das Problem mal wie folgt lösen (müssen) :
Ein Formular mit Splitter, den/die man verschieben kann. (Kein OCX, ein
einfaches Label mittels Mousemove bewegt und die Fenster entsprechend
angepasst) <Idee: Pumhösl>
Wobei die Splitterprogrammierung noch das Einfachste ist <g>
WESENTLICH mühsamer war es, das Unter-Unterformular auf die jeweilige
Bildschirmauflösung anzupassen.
Warum ich das schreibe ? Weil man sich einen Bildschirmaufbau vorstellen
kann, der durch die Splitter das Fenster nie verdeckt sondern immer sichtbar
bleibt, aber es sich der Kunde auf die Größe zurechtschieben kann, die er
möchte...
Nur als Anregung.
mfg
Klaus
Thomas Winkler
zugegeben, nach allem was Du in diesem Posting schreibst, verstehe ich
Dein Anliegen nun wieder überhaupt nicht mehr. Einmal willst Du aus
Access heraus ermitteln wie *klein* das Access-Fenster werden darf damit
noch alle Inhalte ohne Scrollen sichtbar sind (is das richtig?) dann
willst Du ermitteln, dass andere (Access-)Fenster nicht überdeckt werden?
Kann ich mir das so vorstellen, dass der Kunde sich den Desktop in z.B.
vier Rechtecke gekachelt vorstellt und jede Access-Anwendung in einer
"eigenen" Kachel zu sehen sein soll - vielleicht noch mit Andocken beim
verschieben?
> nicht, da ich die Minimal- und
<Luftcode>
dim frm as access.form
dim ctl as access.control
dim lngMaxWidth as Long
dim lngMaxHeight as Long
set frm = Forms!DeinStartForm
lngMaxWidth = 0
lngMaxHeight = 0
For each ctl in frm
if ctl.left+ctl.width > lngMaxWidth then lngmaxwidth = ctl.left+ctl.width
if ctl.top+ctl.height > lngMaxheight then lngmaxheight =
ctl.top+ctl.height
next ctl
set frm = nothing
</Luftcode>
Das ermittelt den maximal durch Steuerelemente eingenommenen Bereich -
was ja auch gleichzeitig die Minimal-Größe des Access-Fensters ist. IMO
dürfte die Einheit Twips sein. Eine Umrechnung von Twips nach Pixel kann
ich bei Bedarf nachreichen.
> gleichzeitig Maximalgröße des
> Access-Fensters bestimmen wollte/will, die erforderlich ist, um ein
> geöffnetes Start-Formular vollständig zu enthalten, ohne andere Teile
> des Desktop zu verdecken.
??? siehe oben
Was denn jetzt - Minimal oder Maximal? Maximal wäre doch Bildschirmgröße
oder nicht? Fragen über Fragen...
Michael König
ach ja, wenn ich's nur besser beschreiben könnte **seufz** Ich glaube,
der nachfolgende Text aus einem früheren Posting beschreibt das Problem
noch am besten:
> Okay, ich versuch's nochmal anders: es gibt bei dem Kunden eine
Access-Anwendung A und (m)eine Anwendung B. Anwendung A wird ausgeführt
und ordentlich abgeschlossen. Dabei ist das Access-Fenster in irgend
einer Größe gespeichert. Nun wird Anwendung B gestartet mit einem
Start-Formular. Dieses Start-Formular soll nun innerhalb des
Access-Fensters maximiert werden (z.B. mit MaximizeRestoredForm oder mit
DoCmd.Maximize), das Access-Fenster, welches zuletzt evtl. größer als
das Start-Formular von Anwendung B gespeichert wurde, soll aber nicht
über das Start-Formular von Anwendung B hinausragen und damit andere
Teile des Desktop überdecken. Mit anderen Worten: das Access-Fenster
soll "geschrumpft" werden auf die äußeren Abmessungen des
Start-Formulars von Anwendung B. Puh, ich hoffe diese Erklärung ist
verständlicher ;-)
Es geht also nicht um mehrere Access-Anwendungen gleichzeitig, sondern
nacheinander. Es soll nur z.B. ein bereits geöffneter Termin-Kalender
(irgendeine Freeware) und/oder ein bereits geöffneter Rechner nicht
durch die nach Anwendung A (nicht von mir, verwendet größere Formulare)
gestartete Anwendung B (von mir, kleinere Formulare) teilweise übereckt
werden, sondern das Access-Fenster soll das Fenster der Anwendung B
"umschließen", aber nicht mehr Platz benötigen.
Zahlenbeispiel: Der Bildschirm ist ein 17" mit einer Auflösung von 1920
x 1200. Das Access-Fenster der Anwendung A ist ca. 25 cm breit, meine
Anwendung kommt mit einer Breite von 18 cm daher. Startet man Access
jetzt ohne irgendeine Anwendung, so ist das Access-Fenster ca. 25 cm
breit. Ruft man dagegen meine Anwendung auf, so ist das Access-Fenster
immer noch 25 cm breit, es werden aber nur ca. 18 cm benutzt. Also soll
das Access-Fenster auf ca. 18 cm Breite geschrumpft werden, so dass man
keine Rollbalken benötigt. Analoges soll für die Höhe gelten, nur sind
hier noch die Höhen von Menüzeile und Symbolleiste zu berücksichtigen.
CU
Peter Doering
Michael König wrote:
> ach ja, wenn ich's nur besser beschreiben könnte **seufz**
Kleiner Tipp am Rande:
Mach 2 Screenshots, einen, wie es im Moment aussieht und einen, wie es sein
soll.
Die stellst du irgendwo fuer uns zur Ansicht ins Netz. Evtl. kannst du mit
Paintbrush noch die entscheidenden Unterschiede markieren, falls sie nicht
offensichtlich sind.
Gruss - Peter
--
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
3. SEK Sa/So 16./17.5.2009, Nürnberg http://www.donkarl.com/SEK/
Thomas Winkler
> Es geht also nicht um mehrere Access-Anwendungen gleichzeitig, sondern
> nacheinander. Es soll nur z.B. ein bereits geöffneter Termin-Kalender
> (irgendeine Freeware) und/oder ein bereits geöffneter Rechner nicht
> durch die nach Anwendung A (nicht von mir, verwendet größere Formulare)
> gestartete Anwendung B (von mir, kleinere Formulare) teilweise übereckt
> werden, sondern das Access-Fenster soll das Fenster der Anwendung B
> "umschließen", aber nicht mehr Platz benötigen.
>
> Zahlenbeispiel: Der Bildschirm ist ein 17" mit einer Auflösung von 1920
> x 1200. Das Access-Fenster der Anwendung A ist ca. 25 cm breit, meine
> Anwendung kommt mit einer Breite von 18 cm daher. Startet man Access
> jetzt ohne irgendeine Anwendung, so ist das Access-Fenster ca. 25 cm
> breit. Ruft man dagegen meine Anwendung auf, so ist das Access-Fenster
> immer noch 25 cm breit, es werden aber nur ca. 18 cm benutzt. Also soll
> das Access-Fenster auf ca. 18 cm Breite geschrumpft werden, so dass man
> keine Rollbalken benötigt. Analoges soll für die Höhe gelten, nur sind
> hier noch die Höhen von Menüzeile und Symbolleiste zu berücksichtigen.
Jetzt hab' ichs. Dann solltest Du doch mit dem von mir geposteten Code
klarkommen, um den *minidestens* von Deinem Form beanspruchten Bereich
zu ermitteln.
Mit diesem Ergebnis (Einheit Twisp, evtl. noch in Pixel umrechen) und
der Höhe der Symbolleisten
'Benötigt einen Verweis auf die Office-Library
Dim cmb As Office.CommandBar
For Each cmb In Application.CommandBars
Debug.Print cmb.Name & ": " & cmb.Height
Next cmb
lässt sich IMHO die benötigte Fensterhöhe und -breite in Pixel berechnen.
(BTW: Scheint mir sehr kompliziert - da gibt's bestimmt noch bessere Wege.)
Bei der Suche nach
http://www.google.de/search?q=access+fenster+positionieren kam mir auch
ein Link nach
http://www.fullaccess.de/CONT_EN_5cdbd58a-5dae-4ea6-90e0-4238af91f6c9.aspx
unter, den ich dann mit Hilfe von
http://msdn.microsoft.com/en-us/library/dd469351(VS.85).aspx und
http://www.vbarchiv.net/api/details.php?id=getwindowrect zu folgendem
umgebaut habe:
Private Type RECT
left As Long
top As Long
right As Long
bottom As Long
End Type
Declare Function SetWindowPos Lib "user32.dll" (ByVal hwnd As Long,
ByVal hWndInsertAfter As Long, ByVal x As Long, ByVal y As Long, ByVal
cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
Declare Function GetSystemMetrics Lib "user32.dll" (ByVal nIndex As
Long) As Long
Declare Function GetWindowRect Lib "user32.dll" (ByVal hwnd As Long,
lpRect As RECT) As Long
Private Type RECT
left As Long
top As Long
right As Long
bottom As Long
End Type
Declare Function SetWindowPos Lib "user32.dll" (ByVal hwnd As Long,
ByVal hWndInsertAfter As Long, ByVal x As Long, ByVal y As Long, ByVal
cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
Declare Function GetWindowRect Lib "user32.dll" (ByVal hwnd As Long,
lpRect As RECT) As Long
Public Const SWP_NOZORDER = &H4
Public Const SWP_NORMAL = 1
Public Sub AccessFensterPositionieren(ByVal intX1 As Integer, ByVal
intY1 As Integer, Optional ByVal intX2 As Integer = 0, Optional ByVal
intY2 As Integer = 0)
Dim myRect As RECT
If ((intX2 = 0) And (intY2 = 0)) Then
If GetWindowRect(Application.hWndAccessApp, myRect) Then
intX2 = intX1
intY2 = intY1
intX1 = myRect.left
intY1 = myRect.top
End If
End If
SetWindowPos Application.hWndAccessApp, 0, intX1, intY1, intX2,
intY2, SWP_NOZORDER
End Sub
Die Funktion "AccessFensterPositionieren" lässt sich sowohl mit *zwei*
Parametern aufrufen (als neue Breite/Höhe bei gleichbleibender Position
interpretiert) als auch mit *vier* Parametern (neue Position und neue
Breite/Höhe).
Michael König
Peter Doering schrieb:
>
> Mach 2 Screenshots, einen, wie es im Moment aussieht und einen, wie es sein
> soll.
>
> Die stellst du irgendwo fuer uns zur Ansicht ins Netz. Evtl. kannst du mit
> Paintbrush noch die entscheidenden Unterschiede markieren, falls sie nicht
> offensichtlich sind.
>
sehr gerne, nur weiß ich nicht, wo ich die Screenshots im Netz ablegen
kann, ich habe dies noch nie benutzt.
Gruß Michael
Jens Schilling
Thomas Winkler
> zu folgendem umgebaut habe:
<snip/>
HTH
Mark Doerbandt
Winfried Sonntag [MVP]:
>> http://rapidshare.com/
> Das ist IMHO eine der schlechtesten Möglichkeiten, besser wäre
> http://www.file-upload.net/ oder http://www.directupload.net/ ;-)
ganz naiv: warum? Pros & cons?
Gruss - Mark
Winfried Sonntag [MVP]
> Hier z.B.:
>
> http://rapidshare.com/
Das ist IMHO eine der schlechtesten Möglichkeiten, besser wäre
http://www.file-upload.net/ oder http://www.directupload.net/ ;-)
Servus
Winfried
--
KnowHow.mdb: http://www.freeaccess.de/knowhow.asp
Access-FAQ: http://www.donkarl.com/AccessFAQ.htm
Access-Stammtisch: http://www.access-muenchen.de/
Richtig zitieren: http://einklich.net/usenet/zitier.htm
Michael König
"dienstbaren Geister",
danke für Eure Unterstützung; hier zwei Links zu den Screenshots (ich
hoffe, es richtig gemacht zu haben):
http://www.file-upload.net/view-1588085/so-nicht.jpg.html
http://www.file-upload.net/view-1588086/sondern-so.jpg.html
@Thomas: danke für Deinen Code; den muss ich mir erst noch in Ruhe zu
Gemüte führen.
CU
Thomas Möller
Michael König schrieb:
vielen Dank für die Screenshots. Spätestens jetzt sollte klar sein, was
Du willst. ;-)
Ich habe den Eindruck, dass Du die ganze Sache dynamisch angehen willst.
Hierfür sehe ich den Sinn noch nicht. Ändert sich die Größe Deines
Startbildschirms laufend? Oder warum willst Du das tun?
IMHO wäre es ausreichend, wenn Du das Access-Fenster mit der von Thomas
W. geposteten Funktion an die gewünschte Größe anpasst. Die Werte dafür
kannst Du einmalig oder auch durch "Try and Error" ermitteln und dann
verwenden.
Einen netten Nebeneffekt hat die ganze Sache noch. Wenn Du eine
Mitteilung mit einer MsgBox ausgibst, dann wird diese MsgBox auf den
Bildschirm zentriert und nicht auf Dein Anwendungsfenster. Aber das wird
Dein Kunde sich auch noch feststellen. ;-)
CU
--
Thomas
Homepage: www.Team-Moeller.de
Michael König
Thomas Möller schrieb:
> Hallo Michael,
>
> Ich habe den Eindruck, dass Du die ganze Sache dynamisch angehen willst.
> Hierfür sehe ich den Sinn noch nicht. Ändert sich die Größe Deines
> Startbildschirms laufend? Oder warum willst Du das tun?
>
> IMHO wäre es ausreichend, wenn Du das Access-Fenster mit der von Thomas
> W. geposteten Funktion an die gewünschte Größe anpasst. Die Werte dafür
> kannst Du einmalig oder auch durch "Try and Error" ermitteln und dann
> verwenden.
>
Also, die Größe des Startbildschirms ändert sich nicht, es ist also
sicher möglich, so zu verfahren wie Du es vorschlägst. Aber mit dem
"dynamisch" hast Du trotzdem nicht so ganz unrecht: ich wollte mich halt
wappnen vor anderen Formularen/Anwendungen mit neuen Fenstergrößen und
hoff(t)e auf eine Funktion, die mir die Größenermittelung "von Hand"
abnimmt, damit ich dieses doofe Thema vergessen kann.
> Einen netten Nebeneffekt hat die ganze Sache noch. Wenn Du eine
> Mitteilung mit einer MsgBox ausgibst, dann wird diese MsgBox auf den
> Bildschirm zentriert und nicht auf Dein Anwendungsfenster. Aber das wird
> Dein Kunde sich auch noch feststellen. ;-)
>
Gruß Michael
Thomas Möller
Michael König schrieb:
> Also, die Größe des Startbildschirms ändert sich nicht, es ist also
> sicher möglich, so zu verfahren wie Du es vorschlägst. Aber mit dem
> "dynamisch" hast Du trotzdem nicht so ganz unrecht: ich wollte mich halt
> wappnen vor anderen Formularen/Anwendungen mit neuen Fenstergrößen und
> hoff(t)e auf eine Funktion, die mir die Größenermittelung "von Hand"
> abnimmt, damit ich dieses doofe Thema vergessen kann.
dem nächsten Kunden machst Du einfach deutlich, dass ihn dieses
"Feature" 2 Std. multipliziert mit Deinem individuellen Stundensatz
kostet. Häufig sind solche "Features" dann nicht mehr so wichtig. ;-)
Jens Schilling
Winfried Sonntag [MVP] wrote:
> Jens Schilling schrieb:
>> http://rapidshare.com/
>
> Das ist IMHO eine der schlechtesten Möglichkeiten, besser wäre
> http://www.file-upload.net/ oder http://www.directupload.net/ ;-)
Das war aber die Einzige, die ich spontan runtertippen konnte ;-)
Da ich diese Dienste selbst aber nicht nutze, bin ich ebenfalls auf Deine
Antwort auf Marks Rückfrage gespannt.
Tschüs
Jens
Jens Schilling
Thomas Möller wrote:
> IMHO wäre es ausreichend, wenn Du das Access-Fenster mit der von
> Thomas W. geposteten Funktion an die gewünschte Größe anpasst.
Oder wie in dem Beispiel, dass ich bereits vor 5 Tagen gepostet habe ;-)
> Werte dafür kannst Du einmalig oder auch durch "Try and Error"
> ermitteln und dann verwenden.
So, oder die (letzte) Formulargröße irgendwo hinterlegen, und wieder
auslesen ( und ggfls. etwas korrigieren) .
Tschüs
Jens
Winfried Sonntag
> Winfried Sonntag [MVP]:
>
>>> http://rapidshare.com/
>> Das ist IMHO eine der schlechtesten Möglichkeiten, besser wäre
>> http://www.file-upload.net/ oder http://www.directupload.net/ ;-)
>
> ganz naiv: warum? Pros & cons?
Bei Rapidshare kommt sehr viel Werbung, und man muß 30 oder mehr
Sekunden warten um downloaden zu können. Außer man kauft sich ein, und
genau das kann man vermeiden. Die erst genannte Alternative ist in
Sachen Werbung recht still und bietet IMHO alles um dafür genutzt zu
werden.
Negatives Beispiel für Rapidshare:
http://rapidshare.com/files/196316197/passalert_errlog.txt.html
Servus
Winfried
--
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
Oliver Straub
> Mit diesem Ergebnis (Einheit Twisp, evtl. noch in Pixel umrechen) und der
> Höhe der Symbolleisten
>
> 'Benötigt einen Verweis auf die Office-Library
> Dim cmb As Office.CommandBar
>
> For Each cmb In Application.CommandBars
> Debug.Print cmb.Name & ": " & cmb.Height
> Next cmb
>
> lässt sich IMHO die benötigte Fensterhöhe und -breite in Pixel berechnen.
dieser Lösungsansatz liegt ja auf der Hand, das Problem dabei sind die
Commandbars der Formulare. Diese werden erst gesetzt, wenn das
"Startformular" geöffnet ist und eben keine weiteren Ereignisse mehr
ausgelöst werden. Aus diesem Grund kommt man nicht umhin, die
Größenanpassung mit dem Timer-Event anzusteuern. Das ist ja eigentlich auch
völlig in Ordnung, nur musst man halt den Intervall nach "Gefühl" setzen.
D.h. es wird gesteuert nicht geregelt, das finde ich eben etwas pfuschig(,
aber auch nicht soo schlimm, das kann man [zur Not] schon machen:)
Gruss
Oliver
Michael König
Oliver Straub schrieb:
>
> dieser Lösungsansatz liegt ja auf der Hand, das Problem dabei sind die
> Commandbars der Formulare. Diese werden erst gesetzt, wenn das
> "Startformular" geöffnet ist und eben keine weiteren Ereignisse mehr
> ausgelöst werden.
das wusste ich z.B. auch noch nicht.
> Aus diesem Grund kommt man nicht umhin, die
> Größenanpassung mit dem Timer-Event anzusteuern. Das ist ja eigentlich auch
> völlig in Ordnung, nur musst man halt den Intervall nach "Gefühl" setzen.
> D.h. es wird gesteuert nicht geregelt, das finde ich eben etwas pfuschig(,
> aber auch nicht soo schlimm, das kann man [zur Not] schon machen:)
>
Könntest Du mir bitte mal skizzieren, wie das mit der
Timer-Event-Steuerung hinzukriegen wäre? Sowas habe ich auch noch nicht
gemacht.
Gruß Michael
Thomas Winkler
> Könntest Du mir bitte mal skizzieren, wie das mit der
> Timer-Event-Steuerung hinzukriegen wäre? Sowas habe ich auch noch nicht
> gemacht.
In Form_Open setzt Du eine TimerIntervall.
Me.TimerIntervall = 3000 'für 3 Sekunden
Nach diesen 3 Sekunden feuert das Event Form_Timer. Dort führst Du die
nötigen Aktionen durch und setzt danach
Me.TimerIntervall = 0
Damit ist der Timer wieder deaktiviert - ansonsten feuert er *alle* 3
Sekunden, und das willst Du ja nicht.
Die 3000 ms ist jetzt ein von mir beispielhaft gewählter Wert. Da musst
Du natürlich empirisch einen passenden Wert ermitteln.
Oliver Straub
> ...
> Die 3000 ms ist jetzt ein von mir beispielhaft gewählter Wert. Da musst Du
> natürlich empirisch einen passenden Wert ermitteln.
zu hoffen wäre natürlich, dass man wenigstens mit 1 Sec. zurecht kommt, aber
genau wissen kann man' s eben leider nicht. Immerhin, wenn man die Größen
dann im Timer-Event ermittelt, langt dafür der Code, den schon der Karl
gelinkt hatte:
http://www.mvps.org:80/access/api/api0022.htm
Eine weitere Unsicherheit, bleiben aber die Scrollbars, denn man kann (imo?)
nicht feststellen, ob diese sichtbar sind oder nicht. Der "api0022"-Code
zeigt immer nur die Größe des freien Clientbereichs. Man sollte wohl zu erst
das "Startfenster" auf L:0/T:0 positionieren und dann erst die Clientgröße
abfragen... aber wenn das Access-Fenster zu klein gespeichert wurde, dann
werden die Scrollbars ja trotzdem eingeblendet und das kann man eben nicht
richtig feststellen. => Das echtzeitige Berechnen der beteiligten Größen ist
(auch wenn man's erst nicht glaubt) ein echtes Problem! Besser ist es dann,
mit festen Werten zu arbeiten, die kann man ja flexibilisieren und optional
auch speichern lassen. So wird dann ja auch eine Standardfunktion draus, die
für weitere Fenster verwendet werden kann
Gruss
Oliver
Michael König
Thomas Winkler schrieb:
> Hi,
>
> In Form_Open setzt Du eine TimerIntervall.
>
> Me.TimerIntervall = 3000 'für 3 Sekunden
>
> Nach diesen 3 Sekunden feuert das Event Form_Timer. Dort führst Du die
> nötigen Aktionen durch und setzt danach
>
> Me.TimerIntervall = 0
>
> Damit ist der Timer wieder deaktiviert - ansonsten feuert er *alle* 3
> Sekunden, und das willst Du ja nicht.
>
> Die 3000 ms ist jetzt ein von mir beispielhaft gewählter Wert. Da musst
> Du natürlich empirisch einen passenden Wert ermitteln.
>
okay, danke, das Verfahren als solches habe ich soweit geschnallt. Jetzt
stellt sich mir die Frage, welchen Code Du meinst, den ich im
Timer-Event unterbringen sollte?
CU
Peter Doering
Michael König wrote:
> Thomas Winkler schrieb:
>>
>> In Form_Open setzt Du eine TimerIntervall.
>>
>> Me.TimerIntervall = 3000 'für 3 Sekunden
>>
>> Nach diesen 3 Sekunden feuert das Event Form_Timer. Dort führst Du die
>> nötigen Aktionen durch und setzt danach
>>
>> Me.TimerIntervall = 0
>
> okay, danke, das Verfahren als solches habe ich soweit geschnallt. Jetzt
> stellt sich mir die Frage, welchen Code Du meinst, den ich im
> Timer-Event unterbringen sollte?
Einfach nur den Aufruf der Prozedur, die letztendlich die Groesse des
Access-Fensters aendert. Dafuer hast du einige Vorschlaege bekommen. Hast
du dich schon fuer einen Weg entschieden? Fuer welchen?
Ich persoenlich wuerde erst garnicht versuchen, die Groesse zu ermitteln,
sondern vorgeben. Damit waere die Timer-Geschichte hinfaellig, du koenntest
die Groesse im Open-Ereignis des Startformular festlegen.
Thomas Winkler
> okay, danke, das Verfahren als solches habe ich soweit geschnallt. Jetzt
> stellt sich mir die Frage, welchen Code Du meinst, den ich im
> Timer-Event unterbringen sollte?
Lieferst Du MDEs an den Kunden aus oder MDBs?
Brauchst Du irgendwelche Symbolleisten zwingend?
Wenn nicht, dann blende sie beim Anwendungsstart mit
'Benötigt einen Verweis auf die Office-Library
Dim cmb As Office.CommandBar 'oder As Object ' das erspart Dir eine
Verknüpfung
For Each cmb In Application.CommandBars
cmb.Enabled = false
Next cmb
aus und beerdige damit alle Probleme mit den CommandBars. Dann kannst Du
auch auf den Timer verzichten.
Michael König
Thomas Winkler schrieb:
> Lieferst Du MDEs an den Kunden aus oder MDBs?
Der Kunde erhält eine MDE als FE und eine (passwort-geschützte) MDB als BE
> Brauchst Du irgendwelche Symbolleisten zwingend?
nicht wirklich; ich erzeuge eine eigene Menüzeile und ein paar
Funktionen wie Kopieren, Ausschneiden etc. habe ich in einem Kontextmenü
untergebracht. Allerdings in der Entwicklungs-MDB sind die CommandBars
nicht unterdrückt.
@Peter: Ich habe mich für folgende Lösung entschieden: ich ermittele
einmalig - so ungefähr - die benötigte Größe des Access-Fensters und
lege diese in einer Tabelle ab, die ich ohnehin schon zu
Steuerungszwecken erzeugt habe. Beim Start der Anwendung hole ich die
Werte ab und setze die Größe des Access-Fensters. Zusätzlich wird das
Access-Fenster auf dem Desktop zentriert, und der Kunde muss es halt
verschieben, wenn es andere Anwendungen überdeckt. Ich hoffe, er ist
damit einverstanden ;-)
Dank und Gruß
Michael