Beiträge von mumpel

Damit funktioniert es garnicht, weder in AutoIt noch kompiliert. Ich sehe nur dass da kurz ein kleines Fenster (das wird die Kommandokonsole, cmd, sein) aufgeht und gleich wieder verschwindet.

Gerade mal schnell auf dem Surface (Windows 10 Insider Preview) getestet. Da läuft der Code. Es muss aber einen Grund geben weshalb es unter "Windows 10 Creator" nicht läuft?!

Ich habe den Code gepostet der den Fehler verursacht.

Am Pfad dürfte es nicht liegen.

So:

$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
ShellExecute($sAnleitung, "", @ScriptDir, "open")

Oder einfach:

$sAnleitung = @ScriptDir & "\Anleitung\Deutsch.pdf"
ShellExecute($sAnleitung)

Beides funktioniert kompiliert nicht.

Hallo!

Ich lasse per ShellExecute eine PDF-Datei öffnen. Solange ich das Script in AutoIt laufen lasse funktioniert alles. Aber sobald ich das Script kompiliere und die EXE aufrufe wird die PDF-Datei nicht geöffnet. Adobe ist aber im Hintergrund geöffnet, aber dafür zwei Reader-Hintergrundprozesse. Dieses Problem scheint aber nur den Adobe-Reader zu betreffen. Lasse ich die PDF-Datei in Edge öffnen (Edge ist dabei als Standardprogramm zugeordnet) funktioniert es korrekt. In VBA funktioniert es mit ShellExecute dagegen. Lässt sich das Problem lösen? PDF-Datei soll mit dem Standard-PDF-Programm geöffnet werden. Danke!

Gruß, René

Windows 10 (1703, Build 15063.483)

Zitat von Kanashius

(...) Ist ziemlich komplex (...)

Du sagst es. In AutoIt muss ich gewaltig umdenken. Allgemeine Module, Klassenmodule und Userformen gibt es ja in AutoIt nicht. Wenn man seit 19 Jahren nur in VBA arbeitet verlangt einem AutoIt schon viel ab. Aber ich lasse mich davon nicht abschrecken. Was ihr so alles in AutoIt auf die Beine stellt ist schon ein großes Lob wert. So weit bringe ich es nie, aber zum "Hausgebrauch" wird es reichen.

Naja, wenn man VBA gewohnt ist tut man sich schwer im Kopf zu zeichnen. Leicht ist das manuelle Anpassen der Koordinaten nicht. Gemacht habe ich das aber schon bei meinem derzeitigen Projekt (das sind aber nur 3 Elemente).

Zitat von BLinz

Trotzdem lässt sich vieles aus VBA gut umsetzen

Aber leider keine Dialoge (Userformen). Der Kode Form Designer ist schlecht. Koda merkt sich die Einstellungen nicht. Wenn man die Form testen möchte muss man Koda beenden. Und wenn man Koda wieder startet und seine Form öffnet sind alle Einstellungen aller Elemente zurückgesetzt, man fängt also ganz von vorn an. Wirklich Spaß macht das so nicht. In "ISN AutoIt Studio" fehlt der Form-Designer, zumindest finde ich nirgens etwas womit ich zum Form-Designer komme.

Da konzetriere ich mich lieber auf AutoIt. Da bin ich dann unabhängig von anderen Programmen. Ich habe aber noch nicht herausgefunden wie ich mit den ADM*-Files arbeite (so wie GPEDT, nur in verbesserter Version).

Ich habe bei solchen Zertifikaten festgestellt dass sie auf fremden Rechnern nicht zum Laufen zu bringen sind. Ich hatte auch mal von einem Anwender eine Datei mit Zertifikat, war nicht zum Laufen zu bewegen. Und selbsterstellte Zertifikate kann auch jeder nachmachen. Nur Zertifikate von Trustcentern sind wirklich nachvollziehbar.

Die Mehrarbeit scheue ich nicht. Einfacher wäre es da vielleicht direkt die ADMX/ADML-Files abzugreifen. Da müsste man aber erstmal wissen wie genau das funktioniert, und ob da so funktioniert wie es soll (siehe meine Anfrage unter: ADMX/ADML auslesen). Alles in AutoIt wäre natürlich optimal.

"Selfcert" kann man in die Tonne treten. Und externe Zertifikate kosten viel Geld. Aber ich verdiene mit meinen Freizeitprojekten kein Geld, die Zertifikate werden somit nicht refinanziert.

Zitat von misterspeed

(...) Vermutlich im Quellcode deines Autoit Scriptes (...)

Nein. Nicht im Klartext, sondern verschlüsselt (AES256). Da müsste sich der Anwender schon auskennen, also wissen wie man esw entschlüsselt. Und der Anwender müsste wissen wie man die EXE dekompiliert. Ich liefere logischerweise nicht deas AutoIt-Script, sondern eine kompilierte Exe (AutoIt hat auch nicht jeder).

Zitat von autoiter

(...) und dir eine GUI zu bauen (...)

Daran habe ich natürlich auch schon gedacht. Nur ist es nicht so leicht das extern nachzubauen. In Excel ist es viel leichter die Datensätze in den Exceltabellen anzusteuern, ohne ein zusätzliches Datenbankprogramm im Hintergrund laufen lassen zu müssen. Würde ich das komplett in AutoIt nachbauen wollen bräuchte ich ja ein Datenbankprogramm, welches aber nicht jeder Anwender hat.

Zitat von misterspeed

(...) Warum soll überhaupt eine geheime, passwortgeschützte Excel Tabelle auf einem "Fremdrechner" automatisiert gelesen/bearbeitet werden? (...)

Da ist nichts Geheimes dran. Die Datei wird über mein AutIt-Scrip geöffnet. Die Userform darin ist ein "alternativer Richtlinien-Editor" Kennwörter werden automatisch übergeben. Die Datei soll nur noch besser geschützt sein, vor allem das VBA-Projekt (das erreiche ich schon mit dem geheimen Kennwort, das verhindert das Öffnen der Datei mit z.B. Hex-Editoren), damit niemand Schadcode einschleusen kann...

Zitat von autoiter

(...) Muss die Excel Instanz denn überhaupt sichtbar sein? (...)

Natürlich. Da läuft ja eine Userform drin.

Zitat von autoiter

(...) Was willst du genau verhindern? (...)

Das schrieb ich schon in #10 und in #3

Zitat von misterspeed

(...) in der Registry (...)

Soetwas sollte man nicht machen. Alles was der Sicherheit zuwiderläuft lasse ich.

Danke für die Tipps. Aber dann muss es so bleiben wie es jetzt ist. Im Vertrauen darauf dass niemand weiss wie man fremde Instanzen manipulieren kann.

Zitat von alpines

(...) Warum willst du mehrere Instanzen denn verhindern? (...)

Wie ich schon schrieb möchte ich verhindern dass ein Anwender aus ein er anderen Instanz heraus in die durch AutoIt erzeugte Instanz "eindringt". Der Standardanwender wird das zwar nicht können, aber sicher sein kann man nie.

Zitat von alpines

(...) Präventiv wirst du da nicht viel machen können (...)

Also einfach ausgedrückt, "No Way"!?

Zitat von misterspeed

(...) aufgrund schlampiger Programmierung (...)

Das hab ich überhört.

Fremde Registrierungsdatenbanken gehen mich nichts an, da pfusche ich nicht drin rum. Ich würde nie auf die Idee kommen fremde Registrierungsdatenbanken ungefragt anzufassen.

Zitat von misterspeed

(...) sollte es eigentlich keine Komplikationen mit anderen Instanzen geben (...)

Da bin ich mir nicht so sicher. Es soll ja möglich sein, Daten zwischen zwei Instanzen auszutauschen. Und genau das möchte ich verhindern. Und verhindern kann man das nur wenn nur eine einzige Instanz zulässig ist. Ich kann zwar in der durch AutoIt erzeugten Instanz verhindern dass andere Dateien geöffnet werden können. Hierzu lenke ich die Menübefehle und Tastenkombinationen auf eine Fehlermeldung um, und die Einträge im Dateimenü und Menüband werden über die RibbonX-Definition umgelenkt bzw. deaktiviert (da die Datei mit Kennwort geschützt ist kann die Datei bzw. die RibbonX-Definition auch nicht manipuliert werden). Die Tastenkombinationen lenke ich über VBA um (Application.OnKey). Der Schutz ist also schon sehr hoch (94%). Da fehlen noch ein paar Prozenzpunkte, auch wenn 100% unmöglich ist.