Manifest-Creator

[himitsu]

Moin Leutchen,

hatte mir eben mal schnell 'nen billiges (inzwischen leicht aufgemotztes) Progrämmchen erstellt,
womit man sich 'nen XP-Manifest zusammenklicken könnte.

vielleicht kann's ja wer gebrauchen



Ist jetzt nix Besonderes und ich weiß auch noch nicht, ob auch alles so richtig läuft

Erstellt wird die XML-Resource, welche man in eine *.manifest kopiert/speichert
und dann entweder so mit seinem Programm mitliefert oder direkt in die Resourcen einbindet.
Wie man es halt so kennt.

Zusätzlich wird noch ein Resourcen-Script erstellt, welches die Resource direkt enthält und nicht erst von einer externen Datei einbindet.

• Standardmäßig ist eine Englisch-Deutsche-Sprachdatei direkt integriert
• wird eine externe Sprachdatei "ManifestCreatorLang.xml" im Projektverzeichnis gefunden, so wird diese stattdessen beim Programmstart geladen
• es kann sich also jeder die angehängte ManifestCreatorLang.xml nehmen, um weitere Sprachen erweitern (zum Format in die ersten Kommentare der ManifestCreatorU.pas reinschauen oder einfach mal nach >>"eng"<< suchen, dieses direkt übersetzen
  und dann natürlich hier im Thread hochladen )
• es werden keinerlei Informationen gespeichert (weder in der Registry, noch in irgendeiner Datei ... abgesehn von den Dateien, welche ihr euch selber manuell speichert, dazu zählen auch die Optionen, welche im Programmverzeichnis gespeichert liegen)
• und falls wem noch die eine oder andere Section fehlt, dann möge er sich einfach melden
  (nachsehn kann man z.B. hier http://msdn.microsoft.com/en-us/library/aa375632.aspx )
• die ActiveX-Libraries werden standardmäßig nicht geladen,
  da es sonst etwas langsamer läd (bei mir so 2-5 Sekunden, statt fast sofort)
• das Laden der ActiveX-Libs läßt sich aber zuschalten
  > einfach als Parameter "-LoadActiveX" mit angeben
• es läßt sich via Parameter ein Projekt (*.ini) erstellen/laden
  gespeichert muß aber selber werden (sowas wie Autosave beim Beenden gibt's nicht)
  > das Projekt kann via Parameter geladen werden "-IniFile=..."
• dieses Programm läßt sich als Tool in die IDE integrieren
  
  Code:

  Titel:      Manifest-Creator
  Programm:   [color=gray]C:\ ... \[/color]ManifestCreator.exe
  Parameter:  -IniFile=$PROJECT -CreateIni

  oder
  Code:

  ...
  Parameter:  -IniFile=$PROJECT -CreateIni -LoadActiveX

  bis Delphi 2007 so
  Code:

  Parameter:  -IniFile== $PROJECT -CreateIni

  und bis Delphi 7 so
  Code:

  ...
  Parameter:  -IniFile== $EXENAME -CreateIni

• in die Resourcedatei (.rc) können nun auch ein Programmicon und Versionsinformationen integriert werden
• in dem Suchfeld kann man Einträge über ihren Namen suchen und es werden Teilweise auch untegeordnete Infos berücksichtigt, z.B. die CLSIDs und der DLL-Name im Bereich ActiveX
• die ComboBox mit dem * dahinter, ändert nix an dem Manifest, sondern zeigt nur rechts im InfoMemo passende Texte an, also in diesem Fall was mit der Anwendung unter verschiedenen Rechten passiert.

[initial] v1.2 2009-09-02
[update] v1.3 2009-10-24 19:05
...
[update] v1.4b 2009-12-18 22:45 - Fehler in Sprachdatei
[update] v1.4d 2010-05-25 18:30 - siehe Beitrag #59 (Vieles)
[update] v1.4f 2010-05-29 14:00 - siehe Beitrag #60-#72 (neue IDE-Integration)
[update] v1.4g 2010-05-31 22:00 - siehe Beitrag #74 (kleinere Fehler und neue Parameterbehandlung)
[update] v1.4g2 2010-06-01 09:00 - siehe Beitrag #75 (kleiner Fehler in Sprachverwaltung)
[update] v1.4h 2010-06-01 12:00 - siehe Beitrag #78 (Probleme mit der Projektverwaltung)
[update] v1.5 2010-06-03 00:30 - siehe Beitrag #80 (gewaltige Aufräumaktion)
[info] v1.5a 2010-08-04 08:06 - Neues Forum (URLs der Delphi-PRAXiS haben sich geändert)
[info] v1.5a 2010-08-27 12:45 - Anhänge neu hochgeladen (das Forenupdate hatte die Dateinamen geschrottet) und dabei gleich das UPX weggelassen (man darf nun eh keine EXE mehr hochladen )
[upload] beim Update gehen die Counter verloren > alt = 303x exe, 30x xml und 48x Sources (Memo an mich selbst, da ich garnicht neugierig bin)
[update] v1.5b 2010-08-27 15:33 - CMDs überarbeitet (UPX deaktiviert)
[update] v1.5c 2013-10-03 21:16 - siehe Beitrag #111 - Horst0815 (Support: XE-XE4 & Win8 / Archtektur: amd64)
[update] v1.5d 2013-11-09 20:38 - siehe Beitrag #109 & #112 - blablab & nru (Bugfix: $RESOURCE / Support: Win8.1)
[update] v1.6 2013-11-10 23:23 - siehe Beitrag #122 (Support: XE5 / Codeformatierung und einige Komponentennamen überarbeitet / Funktionen soriert (Regionen) / große Funktionen aufgeteilt / XML als Resource eingebunden)
[update] v1.6a 2013-11-11 01:44 - assemblyIdentity:language berichtigt und kleiner Bugfiges
[update] v1.6b 2013-11-11 23:43 - siehe Beitrag #125 (Bugfix: Ressource-Typ / weitere Komponenten benannt / Windows Server-Namen aufgenommen / Systemsprache laden )
[upload] beim Update gehen die Counter verloren > alt = 557x exe, 248x xml und 279x Sources (860x 278x 327x)
[update] v1.x 2013-12-15 - Sprachbehandlung überarbeitet / angefangen alle Komponenten zu übersetzen / neue XML-Behandlung angefangen (siehe __TestButton)
[update] v2.0 2015-02-08 23:23 - siehe Beitrag #137 (XE6-XE8 / Windows 10 / IdentityType win32 / alle Komponenten fertig übersetzt
[update] v2.0a 2015-02-13 04:05 - siehe Beitrag #140 (DPI-Aware / Hilfe-URLs / Sprachenladefunktion überarbeitet / Suche für fehlende Hilfetexte )
[upload] beim Update gehen die Counter verloren > alt = 176x exe, 84x xml und 104x Sources (1036x 362x 431x)
[update] v2.0b 2015-02-14 12:38 - siehe Beitrag #147 (Bugfix: DPI-Aware / Bugfix: File-Version / Übersetzungen)


Online: http://svn.geheimniswelten.de:8080/!/#ManifestCreator
Checkout: http://svn.geheimniswelten.de:8080/s...reator/Develop
Login, falls nötig: Gast (gast)

Es wird nur die EXE benötigt.
Die Sprach-XML kann man nutzen, um die Übersetzng oder bestimmte Optionen zu erweitern. (z.B. neue Sprache oder OperatingSystemIDs)
Und wofür der Quelltext (inkl. XML) ist, sollte wohl klar sein.

[CodeX]

Zitat von himitsu:

Die aktuelle Version ist oben.

Vielen Dank für Deine Arbeit!
Ich wollte die DPI-Einstellung gleich mal testen, finde oben aber nur die 2.0 Version vom 2015-02-08!?

[Insider2004]

Soll das jetzt heißen, WinXP wird nicht mehr unterstützt?

[sh17]

Zitat von Insider2004:

Soll das jetzt heißen, WinXP wird nicht mehr unterstützt?

Dann nimm doch die alte Version, man muss den alten Mist ja nicht ewig unterstützen.

[himitsu]

Sehr eigenartig, wenn ich mir die Dateien hier anseh, welche ich hochgeladen hatte, dann ist da noch das Richtige drin.
Nja, alles nochmal neu und DPI-Aware versteckt sich in Design.
Aber schonmal praktisch, daß die Dateiversion (Compilier-Datum) automatisch aktuell angezeigt wird.

Wenn alles klappt, dann ist es bis XP (Windows 5.1) kompatibel. Noch weiter zurück, hab ich mir aber erspart.

[CodeX]

Ah, jetzt stimmt die Version. Sieht doch gleich besser aus.
Bzgl. dpiAware: Wäre hier nicht eine Combobox mit den 4 Möglichkeiten sinnvoll? Laut MSDN gibt es diese Werte: False, True, Per-monitor, True/PM
Und ich weiß nicht, ob es irgendeinen echten Unterschied macht, aber dort beginnen die Werte mit einem Großbuchstaben (aktuell wird "true" gesetzt).

[himitsu]

Hab auch lange gesucht, aber so wie es aussah, gibt es im Manifest quasi nur "true".
https://msdn.microsoft.com/de-de/lib.../dn469266.aspx zeigt die 4 Werte doch nur für den Aufruf der API SetProcessDpiAwareness.

Aber wenn ich das richtig verstanden hab, wird die API scheinbar ignoriert, wenn man es vorher nicht im Manifest aktiviert hatte.
https://msdn.microsoft.com/en-us/library/aa374191.aspx
Hab nochmal nachgesehn ... falsch geguckt.
Gib mir ein paar Minütchen.

[himitsu]

Jetzt sag blos, das stimmt nun immernoch nicht.

• Bugfix: DPI-Aware
• Bugfix: File-Version wurde nicht übernommen
• Übersetzungen überarbeitet

[CodeX]

Ehrlich gesagt, weiß ich gar nicht wie praxis-relevant die anderen Werte aktuell wirklich sind.

• Statt False zu verwenden, kann man den Block und den xmlns:asmv3 Eintrag auch gleich weglassen.
• Ein sinnvolles Szenario für den Per-monitor -Wert erschließt sich mir überhaupt nicht (ab 8.1 Per-monitor-DPI-aware, davor überhaupt nicht).
• True/PM ist sicherlich eine tolle Erweiterung, wenn man bedenkt wie unterschiedlich die Bildschirm-Auflösungen mittlerweile werden. Hat man nun einen 4K-Monitor an einem normalen Laptop angeschlossen, passt sonst die Skalierung der Programmoberfläche entweder auf dem einen oder anderen Bildschirm nicht. Aber wenn ich das richtig verstanden habe, kann Delphi (immer noch?) nichts damit anfangen, weil die Skallierung aller Elemente nur ein Mal geschehen kann. Zumindest ist dieser QC-Eintrag immer noch offen.

Edit: Der rote Kasten verrät mir, dass Du zwischenzeitlich schon fleißig warst. Ich schaus mir gleich an.
Edit 2: Ich finde Deine Umsetzung mit dem ersten leeren Feld ideal gelöst. Damit sind einfach alle Varianten abgedeckt. Soll jeder selbst entscheiden, was er braucht.

[himitsu]

Zitat von CodeX:

[*]Statt False zu verwenden, kann man den Block und den xmlns:asmv3 Eintrag auch gleich weglassen.

Das kann man auch anders sehn.

• False = Meine Anwendung ist definitiv nicht high-DPI-tauglich ... bitte liebes Windows, skalliere das immer
• Nichts = Ich weiß garnicht was das ist oder ich hab keine Ahnung, ob meine Anwendung das kann ... also Windows, mach was du willst und versuche eventuell mit einer Heuristik zu entscheiden was du machst

Der Vorteil von Per-monitor ist, daß das Programm überall gleich groß ist.
z.B. wenn ich ein Programm vom Schlepptop-Bildschirm auf den großen Monitor rüberziehe, dann wird das Programm plötzlich ganz groß.

Zitat von CodeX:

Zumindest ist dieser QC-Eintrag immer noch offen.

Wenn die es rpariert bekommen, dann kann es hier sofort eingestellt/genutzt werden.

Wie das nun genau ist, wenn ein Fenster halb-halb auf zwei Monitoren hängt ... k.A.
Aber für den Anfang könnte man zumindestens die Fensterskalierung anpassen, sobald das Fenster zu über 50% auf dem anderen Monitor geschoben wird.

[Bernhard Geyer]

Zitat von CodeX:

ist sicherlich eine tolle Erweiterung, wenn man bedenkt wie unterschiedlich die Bildschirm-Auflösungen mittlerweile werden. Hat man nun einen 4K-Monitor an einem normalen Laptop angeschlossen, passt sonst die Skalierung der Programmoberfläche entweder auf dem einen oder anderen Bildschirm nicht. Aber wenn ich das richtig verstanden habe, kann Delphi (immer noch?) nichts damit anfangen, weil die Skallierung aller Elemente nur ein Mal geschehen kann. Zumindest ist dieser QC-Eintrag immer noch offen.

Es gibt auch einen Eintrag im neuen QC-System: https://quality.embarcadero.com/browse/RSP-9679
Für VCL würde ich hier nicht (mehr) eine Lösung Erwartung. Die VCL arbeitet mit Integer und hier dürfte das permente Runden zu komischen Effekten führen. Hierzu müssten alle Integerwerte nochmals intern gespeichert werden um immer von diesen zu Wandeln. Bei FMX dürfte das einfacher sein da hier AFAIK mit Floats gearbeitet wird.