Manifest-Creator

[himitsu]

Zitat:

Zitat von nru (Beitrag 1235299)

Zitat:

Zitat von himitsu (Beitrag 1235233)

Wie lautet denn die Fehlermeldung vom Compiler?
[edit] Compilieren des Quellcodes dürfte vermutlich erst ab Delphi 2006 möglich sein.

jup, so siehts aus. Angefangen bei pngimage.pas, was ich aus jvcl nehmen müsste über das zu lange String-Literal in ManifestCreatorLang.pas ("String-Literale können maximal 255 Elemente besitzen")

Da hatte Horst0815 die eingebettete Sprach-XML etwas unglücklich bearbeitet.
(aber das hat ja nun eh ein Ende)

Aber du dürftest auch mindestens beim TEncoding und den kurzen Exit-Statements große Probleme bekommen, da es Diese im D7 noch nicht existierten.
Die neu eigefürgen Regionen (

Delphi-Quellcode:

{$REGION 'xx'}...{$ENDREGION}

) zicken rum, aber die könnte man einfach entfernen.
oder tut sie mit

Delphi-Quellcode:

{$IF CompilerVersion >= 20.0} ... {$IFEND}

umschließen.


Nja, notfalls gibt es ja die kompilierte Version und sind noch ein paar mehr Strings in die Sprach-XML ausgewandert. (vorallem die Delphi-Versionen)

[himitsu]

Zitat:

[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)

Delphi-Support: bis XE5
Windows-Support: bis Win 8.1
Archtektur: amd64

Hab ab auch noch den Code etwas aufgräumt und die eingebettete Sprach-XML wird nun als Resource eingebunden.
Die Komponenten bekommen nun vermutlich Stück für Stück ein paar nettere Namen.
Ein potentieller Stacküberlauf in TLanguage (Endlosrekursion) wurde behoben.


Download im ersten Beitrag.

[himitsu]

Irgendwie wurde die XML nicht mit einkompiliert.
Also am Einfachten auch die XML runterladen und danebenlegen, bis das behoben ist.

[nru]

Zitat:

Zitat von himitsu (Beitrag 1235390)

Irgendwie wurde die XML nicht mit einkompiliert.
Also am Einfachten auch die XML runterladen und danebenlegen, bis das behoben ist.

Schon passiert ;)
Schönen Dank Euch für den Job an Mainfest-Creator. :thumb:


PS: Compilieren unter XE5 hätt ich natürlich auch mal probieren können ... tue mich mit der IDE allerdings noch seeeeehr schwer ;)

[himitsu]

Zitat:

[update] v1.6b 2013-11-11 23:43 - siehe Beitrag #125 (Bugfix: Ressource-Typ / weitere Komponenten benannt / Windows Server-Namen aufgenommen / Systemsprache laden )

Bugfix des Ressource-Typ: Die Anwendung wird wieder geladen.
Das kommt davon, wenn man sich die Konstante RT_RCDATA aus'm Delphi ins RC-Script kopiert, es aber in der Ressource nur RCDATA heißen müsste. :oops:

Windows Server-Namen aufgenommen: Windows Server 2008, Windows Server 2008 R2, Windows Home Server 2011, Windows Server 2012 und Windows Server 2012 R2
Da fällt gleich auf, wie Vista und Win7 zueinander stehen. :stupid:
Hey, ich mag die vielen Win8.1- und iPhone-Werbungen, wo die Bugfixes und Selbstverständliches als die größten Erfindungen präsentieren. (der Start-Knopf ^^)

Wenn es klappt, dann dürfte jetzt automatisch die Systemsprache geladen werden. Also in einem englichen Windows sollte auch die englische Sprache verwendet.
Deutsch bleibt aber die Standardsprache. :angle2:

Der Quellcode läßt sich jetzt auch wieder mit Delphi XE kompilieren (bis wie weit runter, weil ich noch nicht)

Im Debugger werde ich jetzt gefragt, ob eine externe Sprachdatei geladen werden soll.
Damit ich nun ohne große Umstände hoffentlich mitbekomme, wenn mit der Ressource wieder mal etwas nicht stimmen sollte.

Weitere Komponenten wurden mit netten Namen benannt und die Sprach-XML wurde etwas aufgeräumt.

[generic]

Hab noch eine Kleinigkeit gefunden.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Bei der Identität/Type:

Zitat:

Specifies the application or assembly type. The value must be Win32 and all in lower case. Required.

Also Kleinbuchstaben "win32" - MC schreibt "Win32".
Alternativen wie "*" scheinen auch nicht zugelassen.

Siehe Schema:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

[himitsu]

Ohhh, dann hatte ich damals wohl das falsche "Win32" gecopyundpastet. :oops:

Joar, mir selber wurden schon paar Mal von Windows 'ne Anwendung blockiert, wo "*" drin stand.
Aber das große "Win32" wurde zumindestens noch nicht abgewiesen, werd' es aber anpassen. :)



Ach ja, das "*" ist eigentlich drin, weil es anfangs noch alleine drin stand (bevor ich dann auf das "Win32" gestolpert bin.
Komischer Weise war das "*" in unzähligen "Beispielen" für XP-Style-Manifeste drin (damals, als es noch nur um den XP-Style ging), aber inzwischen glaub ich fast, daß es Mal einer falsch machte und dann fast alle Andere einfach nur die "Beispiele" auf ihre Webseiten raubkopiert hatten. (fast nirgendwo stand eine Quellenangabe, von wo man das Beispiel, bzw. das "Wissen" über dieses XP-Manifest, her hatte, aber es ist schon eigenartig, daß nahezu überall die selben Fehler drin waren :roll: )

[Horst0815]

Windows 10

Code:

<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>

Edit: Update für Windows 10 / Server 2015
Appmethod(keine Ahnung ob da benötigt) und Xe6 - Xe7

[CodeX]

Habe dieses Schmuckstück von Tool soeben erst gefunden, nachdem ich recherchieren wollte, welche Änderungen am Manifest für Windows 10 notwendig sein könnten. Klasse!

[Insider2004]

Leider fehlt noch die DPI-Aware Unterstützung, die bei 4k wichtig wird.

[Insider2004]

Ein Fehler: "Win32" muss klein geschrieben werden, sonst ist das Manifest defekt.

[himitsu]

Wollte erst sagen, daß man das "Win32" einfach in der XML anpassen kann, aber das hab ich noch garnicht in die Sprachdatei ausgelagert. :oops:

OK, das Win32 werd ich heute aben gleich austauschen (dachte aber das schonmal kleingemacht zu haben :shock:)
Und die Checkbox für https://msdn.microsoft.com/en-us/lib.../dn469266.aspx wird auch gleich ihren Platz bekommen.


@CodeX: :oops: :D



Ich brauch unbedingt mehr Zeit, um endlich mal V2 fertig zusammenzubauen. (fehlen nur noch zwei andere Projekte, die leider erstmal gestoppt wurden, auf Grund von zwei/drei blöden IDE-Bugs, wovon bisher nur Einer behoben würde, mit dem Kauf eines neuen Delphis)

[CodeX]

Zitat:

Zitat von himitsu (Beitrag 1288063)

OK, das Win32 werd ich heute aben gleich austauschen (dachte aber das schonmal kleingemacht zu haben :shock:)
Und die Checkbox für https://msdn.microsoft.com/en-us/lib.../dn469266.aspx wird auch gleich ihren Platz bekommen.

Vielleicht übersehe ich das gerade, aber hast Du diese beiden Änderungen irgendwo schon offiziell eingepflegt?

Achja, wenn Du schon dabei bist:

Code:

@PROMPT PROMPT$G
@ECHO DIR = %0
IF EXIST datei.res  DEL datei.res
BRCC32.exe -m -fodatei.res datei.rc
IF ERRORLEVEL 1   PAUSE
EXIT

Ich glaube da fehlt ein Leerzeichen bei "-fodatei.res".

[himitsu]

Lauf Hilfe ist es ohne Leerzeichen richtig.
Weiß jetzt aber nicht, ob der BRCC nicht eventuell auch die andere Variante kennt.
(der DCC32 kennt teilweise Beides, also als ein Parameter oder als zwei folgende Paramerter)

[CodeX]

Zitat:

Zitat von himitsu (Beitrag 1288941)

Lauf Hilfe ist es ohne Leerzeichen richtig.
Weiß jetzt aber nicht, ob der BRCC nicht eventuell auch die andere Variante kennt.
(der DCC32 kennt teilweise Beides, also als ein Parameter oder als zwei folgende Paramerter)

Du hast recht. So eine Parameterübergabe habe ich (bewusst) ja noch nie gesehen. :shock:
Ich hatte das zuvor auf jeden Fall auch schon mit Leerzeichen verwendet. Geht also scheinbar beides. Lass natürlich die Version aus der Hilfe drin.

Öhm, und bzgl. meiner anderen Frage? Ich will nicht drängen, sondern es eigentlich nur wissen. :angel:

[himitsu]

Hatte mal angefangen das Programm "bissl" zu überarbeiten und den Code etwas aufzuräumen.

Nja, jetzt sind die alten Versionen (einzelne Zips der dieser Versionen) erstmal sortiert und in eine Versionsverwaltung überführt und nun seh ich so weit schonmal besser, was alles inzwischen verändert wurde und muß jetzt nur noch rausfinden, wie der Stand eigentlich ist und was noch zu machen ist.

[himitsu]

Achtung, auch wenn es noch nicht so sehr große Änderungen gibt, hab ich die Version dennoch jetzt schon auf Version 2.0 hochgesetzt, denn die alte ManifestCreatorLang.xml ist nicht mehr mit der aktuellen Version kompatibel.

Hier erstmal eine aktuelle TestVersion.
Vom Anfang der Umbauarbeiten (Ende 2013 / Anfang 2014), bis zur jetzigen Fertigstellung, war doch schon bissl Zeit vergangen und ich hoffe ich hab nichts übersehn. :oops:

• Das ganze Projekt ist in eine Revisionsverwaltung gewandert und der Server wird vermutlich die nächsten 1-2 Wochen online geschaltet.
• Unterstützung bis XE8
• Unterstützung für Windows 10 und Windows Server 2015
• IdentityType-Bugfix für's "win32"
• alle Komponenten fertig übersetzt und die Sprachbehandlung überarbeitet
  Daher auch die inkompatibilität der ManifestCreatorLang.xml.

Das DPI-Aware kommt doch erst Anfang nächste diese Woche.

[Insider2004]

Morgen! Das Ding läuft nicht auf XP. GetUserdefaultLocationname gibts nicht.

[himitsu]

Ach XP, wer nutzt das schon. :stupid:

Ok, GetUserDefaultLocaleName existiert erst ab Vista.
Und davor gibt es scheinbar auch keine Alternative, welche einem z.B. "de-DE" für Windows mit deutschem Deutsch liefert.
Muß mir mal überlegen was ich da mach.

https://www.spieleprogrammierer.de/1...Cr-windows-xp/
http://stackoverflow.com/questions/2...ge-using-c-api

Eine eigene Sprachübersetzungstabelle werde ich mir garantiert nicht anlegen, aber da es nur um die Sprachauswahl geht und das auch die einzige neue API ist, würde ich es wohl einfach deaktivieren und beim Programmstart dann englisch laden.
Eine Abwärtskompatibilität für ältere Delphis ist diesbezüglich eh schon drin, da jene diese API noch nicht kannten.

[himitsu]

Die aktuelle Version ist oben.

• Die Option für DPI-Aware ist drin, aber mir ist noch nicht eingefallen, was ich dort als Hilfetext hinterlege.
• Die Links unter dem Hilfe-Text funktionieren nun. Muß sie nur noch nach und nach hinzufügen.
  DPI-Aware ist das erste Versuchskind, aber ich weiß noch nicht, ob mir der Style so gefällt, oder ob ich die anderen Links auch so ersetzte.
• Für mich hab ich die Suchfunktion erweitert und wenn man nun nach "?" sucht, dann werden alle Einträge ohne Hilfe-Text angezeigt.

Wie bereits erwähnt, sind die alten SprachXML nicht mehr kompatibel und ich hoffe, daß ich alles übernommen hab, was die lieben Helfer hier gepostet hatten.

[CodeX]

Zitat:

Zitat von himitsu (Beitrag 1289701)

Die aktuelle Version ist oben.

Vielen Dank für Deine Arbeit! :thumb:
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:

Zitat von Insider2004 (Beitrag 1289763)

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. :shock:
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. :gruebel:
https://msdn.microsoft.com/en-us/library/aa374191.aspx
Hab nochmal nachgesehn ... falsch geguckt. :oops:
Gib mir ein paar Minütchen.

[himitsu]

Jetzt sag blos, das stimmt nun immernoch nicht. :stupid:

• 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
  Delphi-Quellcode:

  False

  zu verwenden, kann man den Block und den
  Delphi-Quellcode:

  xmlns:asmv3

  Eintrag auch gleich weglassen.
• Ein sinnvolles Szenario für den
  Delphi-Quellcode:

  Per-monitor

  -Wert erschließt sich mir überhaupt nicht (ab 8.1 Per-monitor-DPI-aware, davor überhaupt nicht).
• Delphi-Quellcode:

  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:

Zitat von CodeX (Beitrag 1289857)

[*]Statt

Delphi-Quellcode:

False

zu verwenden, kann man den Block und den

Delphi-Quellcode:

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:

Zitat von CodeX (Beitrag 1289857)

Zumindest ist dieser QC-Eintrag immer noch offen.

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

Wie das nun genau ist, wenn ein Fenster halb-halb auf zwei Monitoren hängt ... k.A. :gruebel:
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:

Zitat von CodeX (Beitrag 1289857)

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.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1289863)

False = Meine Anwendung ist definitiv nicht high-DPI-tauglich ... bitte liebes Windows, skalliere das immer

Aber nur wenn entsprechender Wert > 150%. Davor wirkt der "normale" Ich kann Skalieren-Wert

Zitat:

Zitat von himitsu (Beitrag 1289863)

Wie das nun genau ist, wenn ein Fenster halb-halb auf zwei Monitoren hängt ... k.A. :gruebel:

Es wird mit Sicherheit nicht auf dem einen Monitor anders skaliert als auf dem anderen. Glaube nicht das es hierfür eine sinnvolle/funktionierende Lösung gibt.
Maximal wäre das der eine Teil des Fensters als Bitmap skaliert wird.

[himitsu]

Zitat:

Zitat von RSP-9679

Priorität: Unwesentlich

Ob es in FMX schnell gehen wird?

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1289873)

Zitat:

Zitat von RSP-9679

Priorität: Unwesentlich Unwesentlich

Ob es in FMX schnell gehen wird?

Aktuell unwesentlich. Wenn die "nicht so unwesentlichen Baustellen" wie Android5, iOS8, ... gelöst sind kann man ja diesen Punkt angehen.

[himitsu]

Wenn man das Andere auf "Hoch" stellt, dann hätte man das doch auch auf "Normal" stehen lassen können ... so klingt es so, wie "wenn wir mal keine anderen Bugs mehr finden, dann sehn wir mal danach".

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1289881)

Wenn man das Andere auf "Hoch" stellt, dann hätte man das doch auch auf "Normal" stehen lassen können ... so klingt es so, wie "wenn wir mal keine anderen Bugs mehr finden, dann sehn wir mal danach".

Eigentlich ist der Typ=Bug falsch. Es müsste eigentlich Features Request oder Problem sein.
Leider ist das nicht vorgesehen. Und im Bereich Feature Request/Problem müssten die Prioritäten anders benannt sein (ähnlich wie hier Diskutiert: http://stackoverflow.com/questions/3...s-and-policies)

[CodeX]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1289864)

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.

Das klingt für mich nach keinem Showstopper. Zumindest klingt das für mich nach "mit etwas Aufwand lösbar". Wäre das nicht sogar als eine Art Komponente lösbar, die sich da irgendwo zwischenreinklinkt und diese Aufgabe übernimmt? Dann hätten auch Nutzer älterer Delphi-Versionen etwas davon. Könnte ein gefragtes Projekt werden. ;)

[Insider2004]

Sieht doch schonmal sehr gut aus. Läuft auch auf XP. Nur die "Supported OS" sind noch leer.

[Bernhard Geyer]

Zitat:

Zitat von CodeX (Beitrag 1289894)

Das klingt für mich nach keinem Showstopper.

Es machts halt aufwändiger

Zitat:

Zitat von CodeX (Beitrag 1289894)

.... die sich da irgendwo zwischenreinklinkt und diese Aufgabe übernimmt?...

Es ist ja schon so das die normale Event das beim Formular erzeugen kommt nicht alle Umwandlungen korekt vornimmt. So eine Komponenten wirds auch nicht 100%ig lösen

Zitat:

Zitat von CodeX (Beitrag 1289894)

Dann hätten auch Nutzer älterer Delphi-Versionen etwas davon. Könnte ein gefragtes Projekt werden. ;)

Na dann fang mal an. Emba wird sowas sicherlich nur für die dann aktuelle Version machen. Und Extended RTTI könnte sich auch hilfreich erweisen. Damit fallen aber alte Delphiversionen raus.

[himitsu]

Probleme mit der MS-XML-Lib? :gruebel:

Hier läuft es.
Jetzt muß sich nur noch wer finden, der

Delphi-Quellcode:

// load operating systems

debuggt. :stupid:

[Insider2004]

Zur Info: Hab gerade das hier ausprobiert. Da bekommt man die gröbsten Schnitzer heraus. Man muss aber vorher das Windows 7 SDK installieren.


call "C:\Programme\Microsoft SDKs\Windows\v7.1\Bin\mt.exe" -validate_manifest -canonicalize -check_for_duplicates -manifest ein.xml -out:aus.xml