Problem mit #AutoIt3Wrapper_Res_ProductVersion=

  • mir ist dennoch nicht klar, warum du den Eintrag "Produktversion" in den Dateieigenschaften der kompilierten EXE-Datei nicht haben willst.

    Dazu ist mir noch ein weiterer Grund eingefallen:

    Der Logik für die Nutzung des ProductVersion-Eintrages folgend müsste dann auch immer ein ProductName oder sogar alle anderen "Standard"-Einträge wie z. B. Firma und Marke mit in die Versionsinformationen eingetragen werden!

    Gruß, fee

    Einmal editiert, zuletzt von fee (30. November 2019 um 06:23)

  • Offen gesagt, einen Nutzen sehe ich nicht, den Eintrag für die Produktversion komplett aus den Versionsinformationen zu entfernen. Was ich sehe ist, dass du das unheimlich gerne haben willst und sehr vehement deutlich machst. Ganz ehrlich, ich sehe mir Versionsangaben in den Dateieigenschaften äußerst selten an, und ich glaube, dass es niemand anderen stört, wenn dort leere Felder für Produktname und -Version stehen. ;)

    Hat jemand eine (recht) einfache nervenschonende Lösung, um die Produktversion aus den Versionsinformationen herauszuhalten?

    Ich denke, deine Frage ist beantwortet: So leid es mir tut, eine einfache und nervenschonende Lösung scheint es nicht zu geben. :( Sieh es positiv: Es wurde wirklich versucht, dir zu helfen. Allein die Zeit, die ich dafür investiert habe, ist meiner Meinung nach den Nutzen nicht wert, aber das muss jeder selbst wissen. Ich möchte gar nicht wissen, wie viel Zeit BugFix da rein gesteckt hat. 8o

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Was ich sehe ist, dass du das unheimlich gerne haben willst und sehr vehement deutlich machst.

    Jepp, ich kann schon ein rechter Sturkopf sein, vor allem, wenn ich weiß, dass etwas mal funktioniert hat. ;)

    Es wurde wirklich versucht, dir zu helfen.

    Da gebe ich dir vollkommen Recht und deshalb danke ich euch allen nochmal recht herzlich für eure Mühe und Geduld mit mir! :)

    Gruß, fee

  • Hilft Dir zwar nicht fee aber erklärt (ein ganz klein wenig) die Sichtweise des Programmierers .

    Interessanter Link (Hintergrundinfos sind immer nützlich) !

    Kurzfassung :

    Im Thread von 2009 beklagte Melba23, dass ab AutoIt 3.3.0.0 die Direktive :
    #AutoIt3Wrapper_Res_Field=ProductVersion

    nur noch die jeweilige Versionsnummer von AutoIt ausweist. Selbstdefinierte Nummern wie z.B. 2.21 werden in den Detaileigenschaften des Explorers nicht (mehr) angezeigt.

    Das hat sich aber (zumindest bei mir - Win7, AutoIt 3.3.14.0) mittlerweile erledigt, siehe :

    AutoIt
    #AutoIt3Wrapper_Res_Description=Beschreibungstext
    #AutoIt3Wrapper_Res_Fileversion=5.0.4.0
    #AutoIt3Wrapper_Res_LegalCopyright=(c) 2019 Fantasy GmbH
    #AutoIt3Wrapper_Res_Language=1033
    #AutoIt3Wrapper_Res_Field=ProductName|Fantasy-Produktname
    #AutoIt3Wrapper_Res_Field=CompanyName|Fantasy GmbH
    #AutoIt3Wrapper_Res_ProductVersion=2.21
    #AutoIt3Wrapper_AU3Check_Parameters=-q -d -w 1 -w 2 -w 3 -w 4 -w 6 -w 7

    ==>

    (die AutoIt-Version wird nur noch als Default verwendet, falls keine Angaben gemacht wurden)

    Das ist aber nicht der Punkt, auf den fee so bemerkenswert hartnäckig hinaus will ;).

    Ihm geht es darum, dass die gesamte Zeile [Produktversion] unterdrückt wird, egal ob mit oder ohne Nummer.

    Dass Aufwand und Nutzen nicht mehr im Verhältnis stehen, hat fee bereits selbst festgestellt.

    Andererseits darf jeder mit seiner Freizeit machen, was er möchte ^^.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • As there is a specific #AutoIt3Wrapper_Res_Field=AutoIt Version|%AutoItVer% directive available, I do wonder why the Product Version property has to be set to that value as well.

    Guugl-Übersetzung:

    Da es eine spezielle Direktive #AutoIt3Wrapper_Res_Field=AutoIt Version|%AutoItVer% gibt, frage ich mich, warum die Eigenschaft Produktversion ebenfalls auf diesen Wert festgelegt werden muss.

    Das ist noch ein weiterer Grund, warum ich so hartnäckig war – und eigentlich noch etwas bin, denn @bazii, du hast das "Feuer" bezüglich des Themas hier in mir wieder etwas entfacht, das fast erloschen war, also möglicherweise das Gegenteil dessen bezweckt, was du vielleicht damit erreichen wolltest (dass ich mich zufrieden gebe und es akzeptiere, wie es ist). :)

    … but what is the issue with setting the ProductVersion to the Version of the AutoIt3 Bin File?

    Guugl-Übersetzung:

    … aber was ist das Problem beim Festlegen der ProductVersion auf die Version der AutoIt3-Bin-Datei?

    Perhaps because the compiled exe is actually the work of the coder? I know the EULA states that it is only licensed, but the fact it also forbids disassembly suggest that a certain level of intellectual property rights is given to the coder. As a mere hobbyist coder, I have no real problem, but I can imagine someone who produces compiled AutoIt code commercially might prefer to have the version number of their application. If they also wish to store the AutoIt version there is the AutoIt Version directive specifically for that purpose.

    Korrigierte Guugl-Übersetzung:

    Vielleicht, weil die kompilierte exe tatsächlich die Arbeit des Programmierers ist? Ich weiß, dass die EULA angibt, dass sie nur lizenziert ist, aber die Tatsache, dass sie auch die Disassemblierung verbietet, legt nahe, dass dem Programmierer ein gewisses Maß an Rechten an geistigem Eigentum gewährt wird. Als reiner Bastler-Programmierer habe ich kein wirkliches Problem, aber ich kann mir vorstellen, dass jemand, der kompilierten AutoIt-Code kommerziell produziert, die Versionsnummer seiner Anwendung vorziehen könnte. Wenn sie auch die AutoIt-Version speichern möchten, gibt es die AutoIt-Version-Direktive speziell für diesen Zweck.

    Das ist zwar ein etwas anderer Fall, jedoch mit demselben zugrunde liegenden "Problem" und die etwas bessere Ausdrucksweise dessen, was ich mit

    … wenn man etwas bewusst weglässt, dann will man es nicht haben und auch nicht aufgezwungen bzw. automatisch mitgeliefert bekommen.

    eigentlich sagen wollte, denn das Recht auf Selbstbestimmung (oder wie das heißt) hat uns @Jos bezüglich den Versionsinformationen ja schon einmal gewährt und dann leider wieder entzogen, wozu er seiner EULA entsprechend wohl das Recht hat:

    All title and copyrights in and to the SOFTWARE PRODUCT … are owned by the Author of this Software.

    Guugl-Übersetzung:

    Alle Titel und Urheberrechte an und für das SOFTWAREPRODUKT … sind Eigentum des Autors dieser Software.

    Darf ich dann überhaupt am AutoIt3Wrapper "herumprogrammieren" und das mögliche Ergebnis hier veröffentlichen?

    Da @Jos seine Meinung klar vertritt und seinen Vorschlag

    auch erfolgreich umgesetzt hat, kann ich (und ihr) meinen Wunsch:

    Daher wäre es schön und nett, wenn jemand … den (Chef-)Programmierer von AutoIt darauf aufmerksam machen könnte …

    genauso wie eine Meldung im Ticketsystem wohl endgültig vergessen. :|

    Abgesehen von obiger Frage will ich euch nicht mehr weiter in dieser Sache nerven, sondern lieber versuchen, Ergebnisse/Erkenntnisse/Informationen zu liefern, soweit/sofern ich das kann/darf. :)

    Übrigens: Ich hatte @BugFix ja meine AutoIt3Wrapper-Version mitgeteilt, aber weil er nicht darauf einging, dachte ich, es sei die neueste Version, was sich aber als Irrtum erwies. Ich lud mir damals mit der AutoIt-Version 3.3.14.5 auch SciTE4AutoIt herunter, was die AutoIt3Wrapper-Version Global Const $VERSION = "19.102.1901.0" enthält, vergaß aber wohl, das neue SciTE4AutoIt zu installieren – keine Ahnung, wieso. Jedenfalls ist mein "Problem" sowohl mit der originalen neuen AutoIt3Wrapper-Version als auch mit den Auskommentierungs-Vorschlägen von @BugFix leider nicht behoben.

    Vor eines möchte ich noch warnen, falls jemand unbedingt den Test von @BugFix durchführen möchte: die mit AutoIt 3.3.14.5 direkt kompilierte EXE-Datei auf Windows XP SP3 bitte nicht ausführen und wirklich nur die Eigenschaften ansehen, denn sie ruft sich in einer Endlosschleife immer wieder selbst auf und kann nur mit dem (mehrfach nacheinander aufgerufenen) Konsolenbefehl

    Bash
    taskkill /f /im "Dateiname steht hier.exe"

    und etwas Glück beendet werden. Nichts für ungut @BugFix, "Fehler" passieren halt und ich hätte die Test-EXE ja nicht ausführen müssen. :)

    So, ich hör jetzt erstmal auf zu schreiben, denn meine Beiträge hier werden ja immer länger! 8|

    Gruß, fee

    5 Mal editiert, zuletzt von fee (29. November 2019 um 22:55)

    • Offizieller Beitrag
    Zitat

    Nichts für ungut @BugFix, "Fehler" passieren halt und ich hätte die Test-EXE ja nicht ausführen müssen. :)

    LOL, die angeführte msgbox.au3 war eine Musterdatei auf meinem PC mit

    Exit Msgbox(0, "Test", "Test").

    Dass es tatsächlich eine Datei mit diesem Namen gibt hatte ich nicht auf der Uhr. :Face:;)

  • Vielleicht ist da dem Programmierer des AutoIt3Wrappers ein Fehler unterlaufen

    Nichts für ungut BugFix , "Fehler" passieren halt

    Fehlt da ein wenig selbstkritisches Denken? Wie sieht denn deine sich selbst aufrufende Testdatei aus, vor der du warnst? Ich lehne mich mal weit aus dem Fenster und sage dir meine Vermutung.

    zum Testen ein beliebiges Skript (hier "msgbox.au3") direkt kompilieren:

    Da steht "direkt kompilieren". Wegen deinem Hinweis zum "Kompilieren ... aus der Registry heraus" hatte ich allerdings den Eindruck, dass du stattdessen das Explorer Kontextmenü benutzt hast. Was zuerst als "Na und, ist doch das Gleiche!?" aussieht, wird in der Verkettung doch ein wenig mehr. Denn ich vermute weiterhin, dass du den Codeschnipsel von BugFix nicht zum Kompilieren für die msgbox.au3 benutzt hast, sondern als msgbox.au3 gespeichert und mit einem Rechtsklick darauf kompiliert hast. Wenn du diese Exe dann ausführst, ruft sie sich natürlich endlos selbst auf.

    Liege ich damit halbwegs richtig? 8o

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    3 Mal editiert, zuletzt von Professor Bernd (29. November 2019 um 18:12)

  • Dass es tatsächlich eine Datei mit diesem Namen gibt hatte ich nicht auf der Uhr.

    Gab/Gibt es auch nicht. Nicht mal den Pfad! ^^ Deshalb habe ich nicht schlecht gestaunt, als der Traysymbolbereich das Zappeln anfing und ich das Programm weder über den Task-Manager noch über den Process Hacker abschießen konnte. :huh: Glücklicherweise blieb Windows gerade noch so steuerbar, was mir das Abwürgen mit taskkill ermöglichte.

    Aus Neugier änderte ich den kompletten Pfad der Variable $sInFile des Tests auf die Quellcodedatei selbst und startete sie nochmals. Die Endlosschleife blieb erhalten, aber taskkill musste ich nur noch einmal absetzen. ;)

    Einmal editiert, zuletzt von fee (29. November 2019 um 23:11)

  • Fehlt da ein wenig selbstkritisches Denken?

    Nein, denn was haben die beiden Zitate darüber miteinander zu tun? Nichts, weil sich das erste Zitat auf den AutoIt3Wrapper von Jos bezieht und das zweite auf den Test von BugFix! Letzteres hast du mit deinem letzten Absatz richtig erkannt.

    … beim direkten Kompilieren wird bei aus der Registry heraus …

    Verflixt, da hat sich der Fehlerteufel eingeschlichen. Nach dem "bei" fehlt ein "mir". Passiert, wenn man im Kopf schon weiter als beim Schreiben ist und es beim Korrekturlesen immer noch nicht auffällt. X/ Habe ich korrigiert.

    … die mit AutoIt 3.3.14.5 kompilierte EXE-Datei …

    Hier war ich nachlässig und hätte vor "kompilierte" ein "direkt" oder "ohne AutoIt3Wrapper" einbauen sollen, da hast du halbwegs Recht, aber für die Endlosschleife ist es vollkommen egal, ob nur mit Aut2Exe oder mit AutoIt3Wrapper kompiliert wurde. Habe ich trotzdem ebenfalls korrigiert.

    … stattdessen das Explorer Kontextmenü benutzt hast.

    Was ist so falsch daran? Dort gibt es bei mir die von mir eingedeutschten Menüpunkte "Kompilieren" und "Kompilieren mit Optionen...". Ersterer entspricht "direktem Kompilieren", nicht wahr?

    … sondern als msgbox.au3 gespeichert und mit einem Rechtsklick darauf kompiliert hast.

    Das war doch auch die Anweisung von BugFix, oder etwa nicht? Außerdem ging es um die Eigenschaften, nicht um das ausgeführte Programm! Ich bin selbst schuld, wenn ich es starte, was BugFix ja nicht wollte. Weil es nur einen Doppelklick erfordert, hat es mich wohl wider besseren Wissens in den Fingern gejuckt, obwohl BugFix

    … ein beliebiges Skript …

    schrieb. Den Hinweis gab ich nur für Leute, die mitlesen, ausprobieren und auch ein Jucken in den Finger verspüren. :)

    Denn ich vermute weiterhin … Liege ich damit halbwegs richtig?

    Nein, ab Zitatanfang vollkommen richtig! :P Mangels msgbox.au3 kann ich sie auch nicht kompilieren! ;)

    Gruß, fee

    7 Mal editiert, zuletzt von fee (29. November 2019 um 23:12)

  • LIebe(r) fee, würdest du bitte meine Frage beantworten, wie dein Testscript genau aussieht, das du kompiliert hast?

    Nachtrag: Damit meine ich, bitte den Quellcode hier posten. ;)

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • … wie dein Testscript genau aussieht …

    Na, beim ersten Mal genau (!) wie das von BugFix. :) Damit sollte deine Frage beantwortet sein oder brauchst du's redundant? ;)

    Für den zweiten Start hatte ich nur den Pfad der Variable $sInFile auf den des Testquellcodes gesetzt. Das brauchst du hoffentlich nicht schriftlich, oder? Der Pfad darf für ein identisches Ergebnis (Endlosschleife) nämlich auf eine beliebige nicht vorhandene .au3-Datei oder eben auf die Testdatei selbst zeigen!

    Außerdem habe ich den Test schon komplett gelöscht, weil es sich erledigt hat. ;)

    Könntest du dann bitte vielleicht auch diese meine Frage beantworten:

    Darf ich dann überhaupt am AutoIt3Wrapper "herumprogrammieren" und das mögliche Ergebnis hier veröffentlichen?

    Natürlich nur, wenn du dir sicher bist bzw. es sicher weißt oder noch besser: es belegen kannst!

    Gruß, fee

  • fee

    Ich bin nicht interessiert daran, mit dir zu streiten. Eigentlich wollte ich dir helfen, aber das geht nur, wenn du das auch willst. ;) Ein letzter Versuch.

    Bezogen auf den Tipp von BugFix gibt es 2 Scripts:

    - 1 beliebiges Script, nennen wir es "msgbox.au3"

    - 1 Script, das den Kompilierbefehl aufruft, nennen wir es "CodeSnippet.au3"

    "CodeSnippet.au3" sollte "msgbox.au3" kompilieren. Meine Vermutung war, dass du nur 1 Script erstellt hast, das sich selbst kompiliert. Das endet natürlich in einer Endlosschleife.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Könntest du dann bitte vielleicht auch diese meine Frage beantworten :

    "Darf ich dann überhaupt am AutoIt3Wrapper "herumprogrammieren" und das mögliche Ergebnis hier veröffentlichen? "

    Natürlich nur, wenn du dir sicher bist bzw. es sicher weißt oder noch besser: es belegen kannst!

    Auch wenn dies nicht an mich gerichtet war ;):

    Der Einzige, der diese Frage final beantworten kann ist @Jos aus dem engl. Forum !

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • @Professor Bernd

    Ich habe genauso kein Interesse an Streit, auch wenn meine Antwortfragen vielleicht etwas spitzfindig gestellt waren. :)

    Meine Vermutung war, dass du nur 1 Script erstellt hast, das sich selbst kompiliert.

    Genau! Ich habe nur ein Skript erstellt, aber selbst kompilieren können hat es sich erst nach dem zweiten Mal kompilieren.

    Du willst mir also sagen, dass meine Testergebnisse möglicherweise falsch waren, weil ich die Anleitung/Absicht von BugFix nicht verstanden und nur ein Skript erstellt habe? Hättest du ja gleich so sagen können. ;) Da haben wir ganz schön heftig aneinander vorbei gedacht/geredet/geschrieben! Hmm, dann hast du mit

    Fehlt da ein wenig selbstkritisches Denken?

    zumindest halbwegs recht, auch wenn die Zitatbezüge darüber nichts gemein haben. Oder zählst du das auch dazu, wenn man eine Anleitung/Absicht nicht verstanden hat? Falls ja, dann hast natürlich vollkommen recht damit, dass ich nicht selbstkritisch genug war. Oder ich war schlicht und einfach doch etwas zu müde.

    Also gut, mach ich es halt nochmal, denn doppelt gemoppelt hält anscheinend doch besser. 8o

    Und bevor du wieder fragst, ich ändere im Test-Skript von BugFix nur den Pfad der Variable $sInFile auf ein existierendes Skript von mir, das dann vom Test-Skript kompiliert wird und liefere das richtige Test-Ergebnis der dadurch entstehenden EXE-Datei.

    Ich danke dir @Professor Bernd für deine Geduld und Hartnäckigkeit, mir das richtige Verständnis zu vermitteln. Meine Warnung lasse ich trotzdem bestehen, falls jemand den gleichen (Verständnis-)Fehler wie ich begeht.

    Gruß, fee

    2 Mal editiert, zuletzt von fee (30. November 2019 um 05:57)

  • Weil ich sooo schwer von Begriff war, hier noch einmal das "schöne Lied": ;)

    Test Eins
    AutoIt: Kompilator.au3
    Local $sInFile = "X:\Zielskript.au3"
    Local $Aut2Exe = StringReplace(@AutoItExe, "AutoIt3.exe", "Aut2Exe\Aut2exe.exe")
    
    ; "Aut2exe.exe / In < infile.au3 >[/out < outfile.exe >][/icon < iconfile.ico >][/comp 0 - 4][/nopack][/x64][/bin < binfile.bin >] "
    Local $sCmd = StringFormat("%s /in %s", $Aut2Exe, $sInFile)
    
    Run($sCmd)

    Ergebnis:

    Keinerlei Eintragungen. Eigentlich eine gute Grundlage. Das gleiche leere Eigenschaften-Fenster entsteht, wenn in der Zielskript.au3 beliebige #AutoIt3Wrapper-Direktiven angegeben sind. Damit komme ich also nicht weiter. Sind dafür etwa nur die #pragma-Direktiven zuständig/nutzbar, wenn ich es auf diese Weise kompiliere?

    Test Zwei

    Ergebnis:

    Das sieht schon fast so aus, wie ich will, nur die Sprache ist noch Englisch und eigene Freiformateinträge fehlen noch. Also stimmt dies – mit obigen Schaltern zumindest bei mir unter Windows XP SP3 – nicht:

    Wenn man selbst kompiliert ist das Feld "Produktversion" enthalten. Das wird beim Kompilieren über die "Aut2exe.exe" erstellt.

    Wie der Eigenschaften-ScreenShot von @BugFix's Testergebnis zeigt, unter Windows 7 (?) hingegen schon. Vielleicht zeigen Windows-Versionen nach XP solche "Standard"-Versionsinformationen-Einträge wie Produktversion anders als XP immer an, unabhängig von deren Existenz in einer EXE-Datei?

    Gibt es wenigstens für die Sprache einen Schalter für Aut2Exe, von dem ich nichts weiß bzw. den ich übersehen habe? Ist der Schalter /ignoredirectives nur für die #pragma-Direktiven gedacht?

    Nebenbei: Der Schalter /compatibility führt bei der Aut2Exe, unabhängig vom Zusatz  vista, win7 oder win8, zum Abbruch der Schalter-Verarbeitung und es öffnet sich die Aut2Exe-GUI, als hätte ich keinen einzigen Schalter angegeben.

    Test Drei
    AutoIt: Kompilator.au3
    Local $sInFile = "X:\Zielskript.au3"
    Local $Aut2Exe = StringReplace(@AutoItExe, "AutoIt3.exe", "Aut2Exe\Aut2exe.exe")
    
    Local $sCmd = StringFormat('%s /in %s', $Aut2Exe, $sInFile)
    
    Run($sCmd)
    Kompilator.au3

    und die Direktiven in

    führen zum gleichen Eigenschaften-Ergebnis wie Test Zwei:

    Die verfügbaren #pragma-Direktiven bieten auch keine Sprachumstellung für die Versionsinformationen an, vergrößern aber das kompilierte Skript (EXE) mal eben um etwa 30 KiB! Warum das denn?

    Gruß, fee

    Edit: In Test Zwei Frage unter BugFix-Zitat geändert.

    5 Mal editiert, zuletzt von fee (30. November 2019 um 13:23)