Fragensteller
Fenster in VFP-Anwendung im Stil von Windows 10

Frage
Alle Antworten
-
Hi Winfried,
das kannst Du erreichen indem Du bei Deinen Forms die Titelleiste ausblendest und die 10er Optik anschliessend nachbaust.
Guillermo Carrero hat dies bspw. mit seiner FoxRibbon Bibliothek gemacht. Diese wurde jedoch nach seinem Tod in 2013 nicht weiterentwickelt. Wenn ich mich recht entsinne gab es auch noch eine russische Bibliothek mit ähnlicher Optik. Emerson Reed hat seine auf VFPX Tools basierenden Themed Controls Bibliothek unter vfpx.codeplex.com bereitgestellt. Diese basiert jedoch noch auf dem Windows 7 Design und muß stark an die 10er Optik angepasst werden. Wenn Du nur den oberen Bereich Deiner Forms mit anderer Optik versehen möchtest ist Markus Winhards ThemedTitleBar ganz interessant. Diese befindet sich ebenfalls auf der VFPX Seite von Codeplex.
Wir haben vor Jahren die Themed Controls genommen und deren Optik an unsere Bedürfnisse angepasst. Unter Windows 10 sieht das dann bspw. so aus:
Aufgrund von Problemen mit Citrix waren wir gezwungen, die ursprünglich ausgeblendete Titelleiste wieder zu reaktivieren. Deswegen entspricht die Optik nicht exakt Windows10. Die Shortcut Buttons sind dadurch wieder auf Höhe der Tabs. Aber bisher hat es noch niemanden wirklich gestört.
Grundsätzlich gilt: Immer wieder mal auf vfpx.codeplex.com vorbeischauen. Dort gibt es eine tolle Auswahl an Tools jedweder Art welche Dir Dein Leben als VFP Entwickler leichter machen.
HTH
Gruss / Best regards
-Tom
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it. 010101100100011001010000011110000101001001101111011000110110101101110011Donnerstag, 24. November 2016 07:48 -
Hallo Winfried, hallo Tom,
vielleicht stehe ich ja gerade etwas auf meiner Leitung ;-)
... oder ich verstehe die Frage bzw. die Antwort nicht, denn:
- wenn ich eine FoxPro-App unter Windows 10 starte, erscheint die Non-Client-Area der Fenster (Titelzeile + Rahmen + Farben, etc.) doch ganz automatisch im Windows 10-Design ?!?!?
Gruß, Stefan
Samstag, 26. November 2016 23:13 -
Hi Stefan,
von Windows 10 Design kann da leider keine Rede sein. Alles was Du bekommst ist das Farbschema. Nicht mehr und nicht weniger.
Du erhältst keine Shortcuts in der Titelleiste, keine Ribbonbar, etc.
Ob man das haben möchte/muß hängt zum einen davon ab, ob die Applikation eine aktuelle/moderne Optik haben soll und zum anderen ob die Anwender es fordern/erwarten.
Eine alte VFP Applikation heute noch auf moderne Optik zu trimmen ist mit den diversen Klassen mit einem gewissen Maß an Aufwand zu erreichen. Aber es ist natürlich auch ein großes Maß an Augenwischerei, denn letztlich werden damit nicht alle modernen Features bereitgestellt. Die VFP App sieht halt einfach nicht mehr ganz so altertümlich aus.
Gruss / Best regards
-Tom
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it. 010101100100011001010000011110000101001001101111011000110110101101110011Montag, 28. November 2016 10:14 -
Hallo Tom,
OK, ich verstehe :-)
Du hast natürlich zu 100 % Recht, das ist so wie bei fast allem im Leben Geschmackssache (ich persönliche lege da nicht soviel Wert drauf)
- wenn man jedoch seine App absolut modern "aufpeppen" möchte, würde ich auf jeden Fall mal einen Blick auf die ActiveX-Controls von CodeJock werfen:
- CodeJock ActiveX COM: da gibt es sehr viele Controls für alles mögliche !!!
- entweder einzeln oder im Bundle als Suite Pro
Gruß, Stefan
Montag, 28. November 2016 13:25 -
Hm, ich meine eigentlich, ich hatte heute Morgen dazu etwas gepostet.
Ich sehe da einerseits Unterschiede zwischen IDE und EXE aber vor allem zwischen Top-Level und In-Top-Level Formen, die komischerweise einen nicht flachen Look bekommen.
Ribbons sind ein Win10 Feature? Eher Office, oder nicht? Dito Tabs in Mailprogrammen oder Browsern. Ich glaube ja nicht, dass es Winfried um Shortcuts in der Titelleiste geht oder ähnliches, sondern einfach um den Borderlook überhaupt, flat und monochrom statt Aero oder andere ältere Looks.
Wenn ich zuhause bin, will ich nochmal damit experimentieren, ob es einen Unterschied ausmacht statt ein In-Top-Level Form zu starten ein As-Top-Level Form mittels SetParent einem anderen unterzuordnen. Aber ganz grundsätzlich hat schon immer Windows die Verantwortung für den Windowsrahmen gehabt, VFP nur für den inneren Canvas. Das ist auch für andere Programmiersprachen eine übliche Unterteilung der Verantwortklichkeiten und nicht nur auf VFP und Winforms beschränkt.
Das Verhalten der je nachdem wie Du Deine Anwendung designt hast ja wahrscheinlich meisten In-Screen Forms ist - so nehme ich an - evtl. durch den Bugfix wegen Aero-Look durch VFP9 SP2 jetzt ein Win10-Look Bug geworden. Es gab damals Workarounds mit Windows-API Aufrufen und dem Properties DoCreate=.T. Eintrag, dessen Positionierung an den Anfang oder ans Ende des Memos gezogen werden musste. Auf das Problem und die Diskussionen darum könnte man auch nochmal zurückgreifen.
Tschüß, Olaf.
Olaf Doschke - TMN Systemberatung GmbH
PS: Nach/Durch SetParent wird der Border-Look eines Formulares von Win10 auf Win7/Vista zurückgeworfen. Ich könnte mir noch vorstellen, dass man etwas über das in jede EXE eingebettete Manifest machen kann...- Bearbeitet Olaf Doschke Montag, 28. November 2016 19:24
Montag, 28. November 2016 17:38 -
Ich finde nur immer mehr Dinge, die zu dem alten Look führen. Hat man sein Top-Level Form auf maximiert gestellt (WindowState 2), wird auch die Top-Level Form Titelbar in dem alten Look gezeichnet.
Es gibt einen Abschnitt im Applikationsmanifest über Kompatibilität, darin habe ich folgendes leider erfolglos ausprobiert, aber vielleicht möchte ja jemand in der Richtung weiter experimentieren:
...
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
</compatibility>...
Man findet Aussagen, dass ohne explizite Angaben über supportedOS Ids das Vista Verhalten Standard wird. Wenn das so wäre dürfte aber kein Formular Windows 10 Look haben, nicht einmal die nicht maximierten Top-Level-Forms.
Tschüß, Olaf.
Olaf Doschke - TMN Systemberatung GmbH
- Bearbeitet Olaf Doschke Montag, 28. November 2016 19:49
Montag, 28. November 2016 19:47 -
Rückblende auf das VFP9 Border und Aero Problemfeld:
https://support.microsoft.com/en-us/kb/967160: Kann man vergessen und nur als erste Beobachtung ansehen.
https://blogs.msdn.microsoft.com/calvin_hsia/2007/04/27/fix-your-forms-to-paint-borders-correctly-under-vista-aero/Hier kann man über die Bedeutung der DoCreate Pseudoeigenschaft etwas lernen.
Last not least ein Workaround mit ACTIVATE WINDOW:
http://www.bingo-ev.de/~mw368/vfp9_vista.htmlIch würde mal ausprobieren, ob etwas davon sich auch (wieder) auf die Win10 Border von VFP Formularen anwenden läßt. Eigentlich sollte keins der Workarounds mit dem SP2 nötig sein. Aber das Windows 10 Look sich in vielen Situationen selbst unter VFP9 SP2 nicht durchsetzt weist darauf hin, dass der Bugfix sehr Vista/Win7 spezifisch war.
Verwandte Theme sind der Combobox bug under Vista und das ClearType Problem mit Fonts/Captions und dazu gab es workarounds, die mit Hilfe von Windows API ein Redraw von Formularbereichen forcierten.
Ich denke, wenn man etwas tiefer gräbt, findet sich auch eine Lösung, die Windows die Formularrahmenverantwortung wieder komplett übernehmen läßt und nicht nur per Methodik, den Borderbereich selbst zu zeichnen und auch Mouseverhalten (Drag an der Titlebar) dafür zu programmieren.
Die GDI+ Titlebar Events aus dem Sample "Binding to Windows Message Events" zeichnen übrigens auch nicht mehr auf die Titlebar, obwohl die Events WM_NCPAINT und WM_NCACTIVATE noch passieren.
Tschüß, Olaf.
Olaf Doschke - TMN Systemberatung GmbH
- Bearbeitet Olaf Doschke Dienstag, 29. November 2016 13:17
Dienstag, 29. November 2016 13:16 -
Hi Olaf,
meine bisherigen Erfahrungen haben gezeigt, dass sämtliche Forms im alten Stil dargestellt werden solange sie innerhalb eines MDI definiert sind. Sobald die Form frei auf dem Windowsdesktop bewegbar ist (Desktop = .T.) oder als TopLevelForm (ShowWindow = 2) deklariert wurde greift umgehend der jeweilige Windowsstil.
oForm1=CREATEOBJECT( [frmInScrDtF] ) oForm1.Show(1) oForm1=CREATEOBJECT( [frmInScrDtT] ) oForm1.Show(1) oForm1=CREATEOBJECT( [frmInTlfDtF] ) oForm1.Show(1) oForm1=CREATEOBJECT( [frmInTlfDtT] ) oForm1.Show(1) oForm1=CREATEOBJECT( [frmAsTlfDtF] ) oForm1.Show(1) READ EVENTS oForm1=CREATEOBJECT( [frmAsTlfDtT] ) oForm1.Show(1) READ EVENTS DEFINE CLASS frmInSCRDtF AS form Caption = [In Screen, Desktop = .F.] ShowWindow = 0 ENDDEFINE DEFINE CLASS frmInScrDtT AS form Caption = [In Screen, Desktop = .T.] ShowWindow = 0 Desktop = .T. ENDDEFINE DEFINE CLASS frmInTlfDtF AS form Caption = [In Toplevel, Desktop = .F.] ShowWindow = 1 Visible = .T. ENDDEFINE DEFINE CLASS frmInTlfDtT AS form Caption = [In Toplevel, Desktop = .T.] ShowWindow = 1 Desktop = .T. Visible = .T. ENDDEFINE DEFINE CLASS frmAsTlfDtF AS form Caption = [As Toplevel, Desktop = .F.] ShowWindow = 2 Visible = .T. PROCEDURE unload CLEAR EVENTS ENDPROC ENDDEFINE DEFINE CLASS frmAsTlfDtT AS form Caption = [As Toplevel, Desktop = .T.] ShowWindow = 2 Desktop = .T. Visible = .T. PROCEDURE unload CLEAR EVENTS ENDPROC ENDDEFINE
Gruss / Best regards
-Tom
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it. 010101100100011001010000011110000101001001101111011000110110101101110011Freitag, 2. Dezember 2016 07:40 -
Forms im alten Stil dargestellt werden solange sie innerhalb eines MDI definiert sind.
Das ist eine gute Klassifizierung.'Nebenbei, Dir ist schon klar, das Top Level Forms auch bei Show(1) nicht modal werden?
Ich habe gelesen, es mag noch Unterschiede zwischen PRG Form-Klassen und VCX/SCX Forms geben, aber sehe das nicht, das galt evtl. bei dem Border Bug, schleißlich hat eine PRG-Formklasse kein Property-Memo, was die DoCreate-Pseudoeigenschaft haben kann.
Die Frage ist nun noch, warum genau der Stil für die anderen Forms gezeichnet wird, der gezeichnet wird und das dürfte eigentlich auf dem Manifest beruhen bzw. damit übersteuert werden können, nur greifen die OS Ids nicht, zumindest nicht bezüglich des Windowsstils.
Die VFP Runtime scheint den Vista/Win7 Stil hart verdrahtet eingebaut zu haben.
Man könnte probieren mit In-Screen und Desktop=.T. Forms auszukommen, diese Forms erscheinen im neuen Look und nicht als Einträge in der Taskbar.
Nachteile:
1. Solche Forms können nicht Dockable = 1 oder 2 sein
2. Im Vergleich zu normalen (Desktop=..F.) In-Screen Formularen bleiben sie nicht im _Screen.
Da Dockable sowieso auch immer nur im Zusammenhang mit HalfHeightCaption geht wäre das denke ich sowieso nie im Windows 10 Stil.SDI Anwendungen im Windows 10 Stil gehen jedoch, da sollte man schon seit jeher mit einer Top-Level Form arbeiten und einer in die EXE eingebetteten config.fpw mit SCREEN=OFF und natürlich wegen der Nichtmodalität von Top-Level-Formularen mit READ EVENTS im main.prg
Tschüß, Olaf.
Olaf Doschke - TMN Systemberatung GmbH
- Bearbeitet Olaf Doschke Sonntag, 4. Dezember 2016 14:08
Sonntag, 4. Dezember 2016 14:06