 |
AutoHotkey Community
Wir helfen uns gegenseitig aus der Patsche
|
| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
 Verfasst am: Mi Apr 16, 2008 1:22 pm Titel: |
 |
|
Update vom 16.04.2008 v2+ Neu: Hinweis auf Begriffe im gewählten Programmnamen, die unter Vista Admin-Rechte erzwingen
im moment kommt der hinweis allerdings nur beim kompilieren unter vista. ist es sinnvoll, wenn der hinweis auch unter xp usw. kommt? |
|
| Nach oben |
|
 |
Ripp3r]D3[
Anmeldedatum: 11.11.2007
Beiträge: 481
Wohnort: Altenburg\Kernel32.dll
|
| Verfasst am: Mi Apr 16, 2008 3:36 pm Titel: |
|
|
Ja währe am besten wenn das nur einmal beim ersten ausführen kommt oder so das man es mit haken ausblenden kann...
_________________
ResistantX:
"...In deren Köpfen läuft das selbe Programm welches auch bei den früheren Jahrgängen lief! Ich bin der Virus der diese Programme zerstören will..." |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Mi Apr 16, 2008 6:13 pm Titel: |
|
|
microsoft schreibt dazu unter http://msdn2.microsoft.com/en-us/library/bb756960.aspx folgendes:
| Microsoft hat Folgendes geschrieben: | Installer Detection only applies to:
* 32 bit executables
* Applications without a requestedExecutionLevel
* Interactive processes running as a Standard User with UAC enabled
Before a 32 bit process is created, the following attributes are checked to determine whether it is an installer:
* Filename includes keywords like "install," "setup," "update," etc.
* Keywords in the following Versioning Resource fields: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name
* Keywords in the side-by-side application manifest embedded in the executable
* Keywords in specific StringTable entries linked in the executable
* Key attributes in the resource file data linked in the executable
* Targeted sequences of bytes within the executable |
von daher habe ich mir was anderes überlegt. erklärung erfolgt bei vö. |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Mi Apr 16, 2008 6:30 pm Titel: |
|
|
Ich hab´s jetzt mal getestet, und Du hast vollkommen Recht, ladiko - wenn ich bloß den Dateinamen ändere, geht´s schon! Und ich hatte wohl mit den Original-Compiler deswegen keine Probleme, weil ich den Namen auf pkb.exe gelassen hatte...
Wunderbar, Problem gelöst, vielen Dank!
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Mi Apr 16, 2008 11:13 pm Titel: |
|
|
Update vom 17.04.2008
+ Änderung: Alle Vista Execution Levels zur Auswahl verfügbar
der hinweis bzgl. des dateinames kommt jetzt immer und unter jedem betriebssystem, wenn man kein vista execution level ausgewählt hat und der dateiname einen der geblacklisteten begriffe enthält. dafür kann man jetzt aber alle execution levels auswählen.
wenn sich jemand von dem dateinamen-hinweis genervt fühlt, muss er halt ein execution level wählen. was die einzelnen levels bewirken erfährt man, wenn man auf den neuen hilfe-button klickt.
@RobOtter
wenn du deine PatchKeyboard.exe mit "asInvoker" kompilierst, kommt keine UAC-Abfrage mehr (siehe help-button) |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Mi Apr 16, 2008 11:49 pm Titel: |
|
|
| RobOtter hat Folgendes geschrieben: | Moin,
ich komme nicht so ganz klar mit relativen Pfadangaben:
Nachdem ich die irre vielen Posts überflogen habe, dachte ich, dass inzwischen rel. Pfade möglich wären (habe die aktuelle v2 vom 14.4.08 ).
Zwar kann ich für das Kompilat einfach einen Namen ohne Pfad angeben, es landet aber nicht im gleichen Verzeichnis wie das Source-Skript (das hätte ich erwartet). Statt dessen blitzt kurz die Erfolgsmeldung auf, in der steht, dass die Exe in mein lokales Temp-Verzeichnis+AutoHotkey\Compiler geschrieben wurde (das konnte ich nur erkennen, weil ich schnell einen Screenshot der Meldung gemacht habe). Warum dort?
Relative Pfade für Icons gehen leider gar nicht. Auch hier wäre mein Wunsch, dass bei einer relativen Pfad/Dateiangabe vom aktuellen Verzeichnis des Source-Skripts ausgegangen wird und das ermittelte Verzeichnis auch nicht in der INI gespeichert wird (ich compile mein Skript auf mehreren Rechnern, da sind natürlich die Pfade nicht immer identisch).
Reine Kosmetik, wahrscheinlich leicht umzusetzen:
In den Dateieigenschaften des Kompilats steht im Tab "Version" als Sprache "Englisch (USA)". Wäre schön, wenn man das auch über die GUI ändern könnte.
Ein letzter Wunsch: Es wäre ein echtes Bonbon, wenn man Bilder etc. gleich mit in die Exe kompilieren könnte - dies wurde, wie ich eben mal gesucht habe, im englischen Forum schon mehrmals besprochen und läuft eigentlich immer wieder darauf hinaus, dass die AutoHotkeySC.bin für das jeweilige Kompilat angepasst werden müsste - eine thematische Punktlandung für Compile_AHK, oder? Passender Thread: http://www.autohotkey.com/forum/viewtopic.php?t=9980
Wenn einige meiner Fragen / Wünsche jetzt schon funktionieren, wäre ich dankbar wenn mir jemand erklären könnte WIE ich sie umsetzen kann.
Grüße,
Rob |
den beitrag hab ich voll übersehen oO
relative pfade ... in compile_ahk müssen im moment noch volle pfade zu sehen sein bzw. eingetragen werden. in der ini-datei werden diese dann allerdings ersetzt durch %IN_DIR% - was soviel heißen soll wie das verzeichnis der input.ahk-datei. beim starten von compile_ahk wird diese variable wieder durch den aktuellen pfad des ordners ersetzt indem die input.ahk-datei gerade liegt. wenn man aber nur den dateinamen in das feld einträgt, wird %A_workingDir% als ordner verwendet und das ist in dem falle %Temp%\AutoHotkey\Compiler\ - das ist der windows mechanismus... muss ich mal drüber nachdenken.
zu den anderen themen überlege ich mir was. zu den bildern muss ich mich überhaupt erstmal belesen. bzgl. des eintrags English (USA) -> grundsätzlich möglich, allerdings steht das nicht als klartext in der versioninfo sondern:
0x0409 = English (USA)
0x0407 = German
usw. siehe --> http://msdn2.microsoft.com/en-us/library/aa381057(VS.85).aspx muss wohl die komplette liste in compile_ahk eingepflegt werden ... |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Do Apr 17, 2008 10:26 am Titel: |
|
|
| ladiko hat Folgendes geschrieben: | | relative pfade ... in compile_ahk müssen im moment noch volle pfade zu sehen sein bzw. eingetragen werden. in der ini-datei werden diese dann allerdings ersetzt durch %IN_DIR% - was soviel heißen soll wie das verzeichnis der input.ahk-datei. |
Ja, das ist schon mal gut und funzt auch prima. Es ist für den Benutzer allerdings ziemlich verwirrend und missdeutig, wenn er (per Hand, nicht über den Auswahl-Dialog) einfach einen Namen, evtl. mit relativer Pfadangabe, tippt und dann das Icon nicht gefunden wird. Für ihn ist ja das aktuelle Verzeichnis das seines eigenen Skripts, nicht das von Compile_AHK.
| ladiko hat Folgendes geschrieben: | bzgl. des eintrags English (USA) -> grundsätzlich möglich, allerdings steht das nicht als klartext in der versioninfo sondern:
0x0409 = English (USA)
0x0407 = German
usw. siehe --> http://msdn2.microsoft.com/en-us/library/aa381057(VS.85).aspx muss wohl die komplette liste in compile_ahk eingepflegt werden ... |
Ja, ich hatte das gesehen, als ich mir die generierten res-Dateien mal angeschaut hatte.
Die Liste von MS ist zwar nur mittelmäßig lang und das ganze macht nur Fleißarbeit, keine Denkarbeit, aber es ist wirklich zu überlegen, ob es den Aufwand lohnt. Übrigens habe ich in einer Windows-Datei auch schon die Angabe "Sprach-Neutral" (oder so ähnlich) gesehen, das ist in der MS-Liste gar nicht aufgeführt.
Mal abgesehen davon, dass die Sprachangabe eh keine Relevanz hat, schaut sich wahrscheinlich sowieso kaum einer die VersionInfos an. Und wenn, dann wird ihn die Angabe "Englisch (USA)" bei einem deutschen Programm auch nicht umbringen 
Wie ich schon sagte: Kosmetik halt. Und die sollte man nicht überbewerten, auch wenn viele Frauen da anderer Meinung sind
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Do Apr 17, 2008 10:47 am Titel: |
|
|
| RobOtter hat Folgendes geschrieben: | | Für ihn ist ja das aktuelle Verzeichnis das seines eigenen Skripts, nicht das von Compile_AHK. |
ist ja nicht das von compile_ahk sondern %TEMP%\Autohotkey\Compiler
wäre doch sehr abwegig ein programm unter %TEMP% zu installieren
| RobOtter hat Folgendes geschrieben: | | Es ist für den Benutzer allerdings ziemlich verwirrend und missdeutig, wenn er (per Hand, nicht über den Auswahl-Dialog) einfach einen Namen, evtl. mit relativer Pfadangabe, tippt und dann das Icon nicht gefunden wird. |
wenn es nur darum geht, kann ich auch einfach alle textfelder disabled setzen, dann muss man den auswahl-dialog benutzen - friss oder stirb 
| RobOtter hat Folgendes geschrieben: | Ja, ich hatte das gesehen, als ich mir die generierten res-Dateien mal angeschaut hatte.
Die Liste von MS ist zwar nur mittelmäßig lang und das ganze macht nur Fleißarbeit, keine Denkarbeit, aber es ist wirklich zu überlegen, ob es den Aufwand lohnt.
Übrigens habe ich in einer Windows-Datei auch schon die Angabe "Sprach-Neutral" (oder so ähnlich) gesehen, das ist in der MS-Liste gar nicht aufgeführt. |
in der rc-datei müsste das besser lesbar sein als in der res-datei. eine halbwegs vollständige liste: http://www.autohotkey.com/docs/misc/Languages.htm
sprachneutral wäre wahrscheinlich, wenn man den eintrag einfach weg lässt - wäre zu testen. und ohne fleiß kein preis, soviel arbeit is das nicht, macht nur den compiler wegen der liste der sprachnamen nen paar byte größer.
| RobOtter hat Folgendes geschrieben: | | Mal abgesehen davon, dass die Sprachangabe eh keine Relevanz hat, schaut sich wahrscheinlich sowieso kaum einer die VersionInfos an. |
ich schon hin und wieder mal bei manchem programmen, aber wenn man das so sieht, kann ich das ändern der VersionInfo ja auch ganz entfernen, guckt sich ja eh keiner an 
| RobOtter hat Folgendes geschrieben: | | Und wenn, dann wird ihn die Angabe "Englisch (USA)" bei einem deutschen Programm auch nicht umbringen |
keine versioninfo bringt mich auch nicht um, aber ist hin und wieder doch ganz nett um zu sehen wer das programm entwickelt hat. wenn z.b. mal wieder irgend ne exe im windows-ordner rumliegt und kein icon hat und der name einem auch nichts sagt. hab noch keinen virus gesehen, der als produzent "microsoft" ausweist - komisch eigentlich ... und nein, ntoskrnl.exe und iexplore.exe seh ich nicht als virus an.
| RobOtter hat Folgendes geschrieben: | | Wie ich schon sagte: Kosmetik halt. Und die sollte man nicht überbewerten, auch wenn viele Frauen da anderer Meinung sind |
ein bisschen oberflächlichkeit steckt doch in jedem von uns. zitat: "ey boah, kiek ma die kirsche da, die hat bestimmt nen total geilen charakter!!!" 
ich bau's einfach ein, wer's braucht, benutzt's, wer nich, der nich.
bzgl. der relativen pfade: müsste sowas wie ./bigicon.ico oder ./bigicon.ico auch abgedeckt werden? denn dann müsst ich die verwendete ordnerstruktur nochmals überdenken. |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Do Apr 17, 2008 1:34 pm Titel: |
|
|
| ladiko hat Folgendes geschrieben: | | RobOtter hat Folgendes geschrieben: | | Für ihn ist ja das aktuelle Verzeichnis das seines eigenen Skripts, nicht das von Compile_AHK. |
ist ja nicht das von compile_ahk sondern %TEMP%\Autohotkey\Compiler
wäre doch sehr abwegig ein programm unter %TEMP% zu installieren |
Jaja, hast ja recht...
| ladiko hat Folgendes geschrieben: | | RobOtter hat Folgendes geschrieben: | | Es ist für den Benutzer allerdings ziemlich verwirrend und missdeutig, wenn er (per Hand, nicht über den Auswahl-Dialog) einfach einen Namen, evtl. mit relativer Pfadangabe, tippt und dann das Icon nicht gefunden wird. |
wenn es nur darum geht, kann ich auch einfach alle textfelder disabled setzen, dann muss man den auswahl-dialog benutzen - friss oder stirb |
Och menno... Das nimmt Dir natürlich die Möglichkeit zu erkennen, ob der User nun wirklich einen absoluten Pfad angeben wollte oder doch nur einen relativen - denn FileSelectFile gibt immer den absoluten Pfad zurück. Du müsstest also immer von einem relativen Pfad ausgehen - was in den meisten Fällen auch sicherlich sinnvoll ist. Aber damit hätten wir dann bloß "immer absolute Pfade" gegen "immer relative Pfade" eingetauscht.
| ladiko hat Folgendes geschrieben: | ich schon hin und wieder mal bei manchem programmen, aber wenn man das so sieht, kann ich das ändern der VersionInfo ja auch ganz entfernen, guckt sich ja eh keiner an
...
ich bau's einfach ein, wer's braucht, benutzt's, wer nich, der nich. |
Wunderbar! Wenn schon, denn schon! - Das wollte ich von Anfang an, aber ich konnte Dir diese Haltung natürlich nicht aufzwingen. Schließlich können wir alle dankbar sein, dass Du das Teilchen überhaupt weiterbaust.
| ladiko hat Folgendes geschrieben: | | ein bisschen oberflächlichkeit steckt doch in jedem von uns. zitat: "ey boah, kiek ma die kirsche da, die hat bestimmt nen total geilen charakter!!!" |
ROFLMAO
Ich geb´s ja auch zu: Tief in meinem Innern bin ich ziemlich oberflächlich...
| ladiko hat Folgendes geschrieben: | | bzgl. der relativen pfade: müsste sowas wie ./bigicon.ico oder ./bigicon.ico auch abgedeckt werden? |
Wo ist denn jetzt der Unterschied? Oder meintest Du ./bigicon.ico und ../bigicon.ico? Die Angabe des Elternverzeichnisses sollte natürlich auch funktionieren, klar. Ich halte das aber nur für ein bisschen Parsing-Aufwand.
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Do Apr 17, 2008 6:08 pm Titel: |
|
|
| RobOtter hat Folgendes geschrieben: | | Och menno... Das nimmt Dir natürlich die Möglichkeit zu erkennen, ob der User nun wirklich einen absoluten Pfad angeben wollte oder doch nur einen relativen - denn FileSelectFile gibt immer den absoluten Pfad zurück. Du müsstest also immer von einem relativen Pfad ausgehen - was in den meisten Fällen auch sicherlich sinnvoll ist. Aber damit hätten wir dann bloß "immer absolute Pfade" gegen "immer relative Pfade" eingetauscht. |
ich versteh dich so, dass jemand einen kompletten pfad einträgt, weil er keinen relativen pfad will und das script kompiliert und die exe-datei somit erstmal im selben ordner liegt (in der ini-datei wird jetzt aber %IN_DIR% eingetragen). danach kommt er auf die idee dass script in einen anderen ordner zu packen, wobei die kompilierte exe-datei aber weiterhin im alten ordner entstehen soll, was natürlich jetzt nicht mehr passiert, da der neue skript-ordner der output-ordner ist. kannst du dir so ein szenario wirklich vorstellen? macht jemand sowas? das ist nämlich der einzige fall, den ich mir jetzt ausmalen könnte, wo das probleme bringt. wird von vorn herein ein output-pfad gewählt, der nicht innerhalb des skript-ordners liegt, wird eh der feste pfad gespeichert.
| RobOtter hat Folgendes geschrieben: | | Wo ist denn jetzt der Unterschied? Oder meintest Du ./bigicon.ico und ../bigicon.ico? Die Angabe des Elternverzeichnisses sollte natürlich auch funktionieren, klar. Ich halte das aber nur für ein bisschen Parsing-Aufwand. |
ja sorry ich meinte beim 2. mal natürlich ..\bigicon.ico
könnte man natürlich parsen, sicher sicher, und dann bei ..\..\..\..\..\..\..\bigicon.ico einfach entsprechend oft durch-loopen.
einfacher wäre es in dann allerdings %A_WorkingDir% auf %IN_DIR% zu setzen. dann sollten alle relative pfade gefressen werden, die windows / ahk sonst auch akzeptieren würde.
einziger nachteil der mir momentan einfällt:
alle dateien die momentan in %temp%\AutoHotkey\Compiler liegen bleiben, liegen dort absichtlich für eventuelle debugging-zwecke und auf grund von expliziten pfaden. das würde auch alles funktionieren, wenn dieses verzeichnis nicht mehr gleichzeitig durch %A_WorkingDir% angesprochen würde. ABER:
wenn beim compilieren unvorhersehbarer datenmüll anfällt, landet der dann nicht mehr unbedingt unter %temp%\AutoHotkey\Compiler, sondern in %IN_DIR%. sollte grundsätzlich nicht passieren, aber wir wissen ja wie das mit den grundsätzen ist ... wäre das ein akzeptables risiko?
Update vom 17.04.2008 v2
+ Änderung: VersionInfo Language und Codepage / Charset können ausgewählt werden
zu codepage / charset: ich habe keine ahnung wo man das einsehen kann oder was windows damit veranstaltet oder welche nebenwirkungen das haben kann. default ist "unicode". wenn jemand mehr darüber weiß, immer her damit
die gui wird später an die letzte änderung angepasst. |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Mi Apr 23, 2008 10:33 am Titel: |
|
|
Sorry, ich war ein paar Tage verhindert...
Also, ich beschreibe mal die Situation, durch die mir die Thematik "abs. / rel. Pfade" aufgefallen ist:
Ich arbeite an einem Skript, welches sich im Ordner X:\y\z\MeinProjekt befindet und das weitere Resourcen (z.B. Bilder, aber auch Programm-Icons) aus dem darunter liegenden Ordner .\res\img einbinden soll.
Nun nehme ich häufiger das aktuelle Projekt mit auf einen anderen Rechner, wo ich es im Verzeichnis A:\b\c\MeinProjekt (natürlich mit den o.g. Unterordnern) ablege und eben auch immer wieder mal compiliere. Später nehme ich es - nach ein paar Änderungen - wieder mit auf den alten Rechner, dann liegt es also wieder in X:\y\z\MeinProjekt.
Die Compiler-Einstellungen will ich in der Oberfläche nun so angeben, dass meine compilierte Zieldatei im gleichen Ordner wie das Skript liegt, also gebe ich dort (per Hand) nur den Dateinamen ein - ohne Pfad. Ähnlich ist es mit den Icons. Hier möchte ich nur res\img\meinIcon.ico angeben müssen - Ausgangsbasis für alle diese relativen Pfadangaben müsste immer das Verzeichnis sein, in dem mein zu compilierendes Skript liegt, also egal, ob es sich dabei um X:\y\z\MeinProjekt oder A:\b\c\MeinProjekt handelt.
Ich habe die letzten zwei oder drei Versionen diesbezüglich nicht getestet, kann also nicht sagen, ob das schon so funktioniert. Zum Zeitpunkt meines damaligen Postings ging es aber nicht (logisch ).
Ich hoffe, das hat mein Anliegen jetzt deutlich gemacht. In den meisten (allen?) Fällen dürfte es richtig sein, wenn man von Pfadangaben relativ zum Ordner der Skriptdatei ausgeht. Ausnahmen könnten Pfade zu Icons sein, die in System-Dateien (.dll, .exe, .ico) liegen - wobei ich gerade gar nicht weiß, ob Compile_AHK DLLs mit Icon-Nummer überhaupt unterstützt.
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Mi Apr 23, 2008 11:36 am Titel: |
|
|
also icons die unter .\res\img liegen, klappen definitiv solange man den kompletten pfad einträgt, weil:
1.:
in der Ini-Datei von X:\y\z\MeinProjekt\MeinScript.ahk wird der String
X:\y\z\MeinProjekt durch %IN_DIR% ersetzt. haben wir nun also ein Icon mit dem Pfad X:\y\z\MeinProjekt\Res\Img\MainIcon.ico so wird daraus in der Ini-Datei Icon_1=%IN_DIR%\Res\Img\MainIcon.ico.
IN_DIR bezieht sich immer auf den ordner in dem das script und die dazugehörige Ini-Datei liegt. Kopiert man das Skript nun auf einen USB-Stick nach Z:\a\b\MeinProjekt\MeinScript.ahk so ist die neue IN_DIR also Z:\a\b\MeinProjekt. Somit wird aus Icon_1=%IN_DIR%\Res\Img\MainIcon.ico diesmal Z:\a\b\MeinProjekt\Res\Img\MainIcon.ico. genauso geschieht dies mit allen anderen pfaden. gibt ja im moment nur den pfad für die kompilierte exe und die pfade für die icons.
2. Fall: liegt das icon aber nicht unter
X:\y\z\MeinProjekt\Res\Img\MainIcon.ico
sondern unter
X:\y\z\Res\Img\MainIcon.ico
so kann der string X:\y\z\MeinProjekt nicht mehr ersetzt werden. der relative pfad dazu wäre ja ..\Res\Img\MainIcon.ico statt .\Res\Img\MainIcon.ico |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Mi Apr 23, 2008 11:57 am Titel: |
|
|
| ladiko hat Folgendes geschrieben: | 2. Fall: liegt das icon aber nicht unter
X:\y\z\MeinProjekt\Res\Img\MainIcon.ico
sondern unter
X:\y\z\Res\Img\MainIcon.ico
so kann der string X:\y\z\MeinProjekt nicht mehr ersetzt werden. der relative pfad dazu wäre ja ..\Res\Img\MainIcon.ico statt .\Res\Img\MainIcon.ico |
Ja, aber dann hätte ich ja auch ..\Res\Img\MainIcon.ico eingegeben, weil ich dann ja weiß, dass mein Icon nicht im Ordner MeinProjekt liegt, sondern parallel dazu.
Wäre es denn problematisch? Wenn %IN_DIR% einfach durch das aktuelle Skript-Verzeichnis ersetzt und dann die relative Pfadangabe angehängt wird, erhalten wir X:\y\z\MeinProjekt\..\Res\Img\MainIcon.ico - was eine valide Pfadangabe ist. Vielleicht nicht für AHK (dann müsste man per Parsing den tatsächlichen Pfad bauen), aber nach Windows-Konvention schon.
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
ladiko
Anmeldedatum: 08.02.2007
Beiträge: 68
Wohnort: Naher Osten
|
| Verfasst am: Mi Apr 23, 2008 12:30 pm Titel: |
|
|
| RobOtter hat Folgendes geschrieben: | | Wäre es denn problematisch? Wenn %IN_DIR% einfach durch das aktuelle Skript-Verzeichnis ersetzt und dann die relative Pfadangabe angehängt wird, erhalten wir X:\y\z\MeinProjekt\..\Res\Img\MainIcon.ico - was eine valide Pfadangabe ist. |
ohh tatsache, C:\Windows\System32\..\System funktioniert ja wirklich, habe ich nicht gewusst! wieder was gelernt, danke! Dann mache ich es auf diese Weise. Mal schauen ob AHK das genauso mag wie Windows. an sich beruht ahk ja auf windows APIs, müsste also gehen.
%IN_DIR% durch das Skript-Verzeichnis zu ersetzen, ist kein Problem, das wird so oder so gemacht. Das Problem ist eher, dass %IN_DIR% erstmal in der ini-Datei stehen muss. Es wird ja überhaupt erst in die Ini-Datei geschrieben, wenn sich das Icon auch in diesem Verzeichnis befindet. Ist das Icon schon einen Ordner höher im Pfad als das Skript, kann der Pfad bis zum Skript ja nicht ersetzt werden, der letzte Ordner fehlt ja. Ich werde es einfach so ändern, dass das Skript-Verzeichnis davorgesetzt wird, wenn im Pfad kein Doppelpunkt angegeben ist (also kein Laufwerksbuchste angegeben ist) und auch nicht mit \\ beginnt. Gibts noch andere möglichkeiten als <Laufwerksbuchstabe>:\ und \\<server> ? |
|
| Nach oben |
|
|
RobOtter
Anmeldedatum: 21.03.2006
Beiträge: 42
Wohnort: Darmstadt
|
| Verfasst am: Mi Apr 23, 2008 1:22 pm Titel: |
|
|
| ladiko hat Folgendes geschrieben: | | Ich werde es einfach so ändern, dass das Skript-Verzeichnis davorgesetzt wird, wenn im Pfad kein Doppelpunkt angegeben ist (also kein Laufwerksbuchste angegeben ist) und auch nicht mit \\ beginnt. Gibts noch andere möglichkeiten als <Laufwerksbuchstabe>:\ und \\<server> ? |
Mehr fällt mir auch nicht ein. Ein Stolperstein könnte allerdings noch die quasi-absolute Pfadangabe "\res\img\mainIcon.ico" sein. Hierbei wird nur das aktuelle Laufwerk als Ausgangspunkt berücksichtigt, nicht aber das aktuelle Verzeichnis.
Wenn die Eingabe also nur mit einem Backslash (statt zweien) beginnt, kannst Du nicht einfach %IN_DIR% voranstellen sondern darfst nur den LW-Buchstaben (inkl. Doppelpunkt) nehmen.
Achja: Sind eigentlich Variablen in der Verzeichnisangabe möglich? Also sowas wie %windir%\System32\moricons.dll,12 ?
Wenn ja, dann müsstest Du auch noch % als erstes Zeichen abfangen.
Interessant wird das aber wohl nur, wenn man ein Icon aus einer Datei (z.B. moricons.dll oder shell32.dll) referenzieren könnte.
_________________
Ich sag doch gar nichts, ich red ja nur... |
|
| Nach oben |
|
|
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
|
Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de |
FAQ
Suchen
Mitgliederliste
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
