Beiträge von misterspeed

autoBert

https://answers.microsoft.com/de-de/msoffice…77-a8cc09f5e6d9

https://answers.microsoft.com/de-de/msoffice…08-71435482b8d2

Lizenzschlüssel und / oder Microsoft Konto mit dem ursprünglich mal aktiviert wurde sollte ja vorhanden sein.

Normalerweise bietet solche Software selbst eine Option um nach Abschluß der Aufgabe Aktionen wie "Programm beenden" oder "Computer herunterfahren" durchzuführen. Eine feste Uhrzeit ist jedenfalls wenig sinnvoll, da wie bereits erwähnt wurde für Windows oder Autoit nicht bekannt ist ob zu diesem Zeitpunkt bereits alle Aufgaben abgeschlossen wurden. Würde dir daher die Dokumentation deiner Rendering Anwendung empfehlen, denn das ist mit Sicherheit zuverlässiger als über externe Software herauszufinden ob alles erledigt ist.

Bzgl. Schritt 2 (Ausdruck der PDF):

Dafür brauchst du normalerweise auch keine GUI Automatisierung eines PDF Viewers. Siehe z.B. hier https://www.autoitscript.com/forum/topic/16…ntly-print-pdf/

Allerdings landet der Shellexecute Aufruf standardmässig beim Default Drucker des Benutzers. Daher wird im obigen Thread Sumatra erwähnt (portabler PDF Viewer, der scheinbar mit commandline Befehlen auch auf beliebigen anderen Druckern drucken kann).

Alternativ könnte man mit Autoit aber sicher auch den aktuellen Standard Drucker ermitteln, auf einen anderen wechseln und danach wieder zurückstellen.

Und welche Webapplikation ist das? Handelt es sich um die Webseite eines Logistikunternehmens wie DHL, UPS, TNT usw. oder ist das ein anderes Produkt?

Hintergrund der Frage:

Sicher kann man Webseiten automatisieren indem man Benutzeraktionen wie Mausklicks simuliert. Sehr viel einfacher, zuverlässiger und performanter geht das aber, wenn die Webseite eine API für genau solche Zwecke bereitstellt. Dann reichen im Idealfall wenige Zeilen Text direkt an den Webserver ohne lahmen Browser dazwischen, damit er dir das gewünschte Dokument bereitstellt.

Zwar etwas OffTopic, aber wer schonmal den Acrobat Reader genutzt hat hat sicher schon den sehr ungewöhnlichen Workaround von Adobe gesehen um den Acrobat Reader zum Standardprogramm für PDF Dateien zu machen. Hab mich schon sehr lange gefragt wieso eine große Firma wie Adobe auf solche Tricks zurückgreifen muss und die notwendigen Registry Schlüssel nicht einfach selbst setzt.

Adobe umgeht das Problem durch Anzeigen des Dateieigenschaftenn Dialogs einer mitgelieferten PDF Datei und fordert den User dann zum anklicken des "Ändern" Buttons bei "Öffnen mit" über eine Overlay GUI auf. Scheinbar ist das die einzigste zuverlässige Methode für PDF Dateien, andernfalls hätte man das sicher nicht so primitiv bei Adobe gelöst.

Aber auch das Setzen des Standard Browsers scheint nicht ganz so simpel zu sein. Firefox öffnet dafür einfach den Dialog von Windows in dem die Standard Apps festgelegt werden können.

Microsoft hat hier definitiv Hürden eingebaut, die es so in früheren Windows Versionen nicht gab.

Nunja, aber Schwachpunkt daran ist doch, dass du so auf jedem Gerät die Termine pflegen müsstest oder wie ist dein Plan für die Synchronisierung zwischen den Geräten? Deswegen bietet sich hier eben eine cloudbasierte Lösung an, z.B. über dein sicher bereits vorhandenes Smartphone.

Klar mit Autoit hat das dann nix mehr zutun und hilft dir nicht wirklich bzgl. Erfahrung im Programmieren sammeln. Dennoch ist es eben die bessere Lösung. Wenn du mit Autoit vergleichbares erreichen willst wird das ein sehr aufwendiges Projekt, welches dich vermutlich überfordert.

Aber zurück zum Standby Problem... schonmal getestet ob das Script auch dann den Betrieb einstellt, wenn du auf sleep verzichtest?

Eine Möglichkeit wäre z.B. timerinit() / timerdiff() oder AdlibRegister() und das Makro @hour zu verwenden.

Wenn das Script nur 2x am Tag eine Erinnerung anzeigen soll macht es kaum Sinn dieses permanent laufen zu lassen. Stattdessen würde ich einfach die Windows Aufgabenplanung nutzen und das Script zu den gewünschten Uhrzeiten aufrufen lassen. Vorteil is hier auch, dass die Windows Aufgabenplanung verpasste Programmstarts nachholen kann wenn der Rechner zur fraglichen Zeit gerade im Standby oder gar aus war. Dein Script müsste beim Start dann nur noch ermitteln ob es "morgens" oder "abends" ist und die entsprechende Meldung anzeigen, danach wird es beendet und Thema erledigt.

Aber davon mal ab wurden für sowas Kalender Serientermine erfunden, sowohl auf dem Smartphone, als auch in Email Clients am PC.

Zitat von SEuBo

Oder statt mit StringFormat, was ich immer etwas kryptisch finde, einfach mit StringRight.

StringRight("00000" & $iZahl, 5)

Stringformat ist in der Tat schrecklich... nie wirklich selbst abseits von fertigen "Pattern" benutzt und neulich zum ersten mal mit der doch etwas umfangreicheren Doku beschäftigt. Per Stringright gehts natürlich auch.

Da geb ich @Musashi recht.

Dennoch zu deinen Fragen:

1. Um einen String zum Beispiel mit 0 aufzufüllen verwendet man die Funktion stringformat()

Beispiel:

$sData = "2"
$sDataFormated = StringFormat("%+03s",$sData)

ConsoleWrite($sDataFormated & @CRLF)

Exit

2. Das Problem mit der Dateiendung könntest du komplett umgehen, wenn du statt irgendwelchen Edits und Usereingaben einfach einen FileOpenDialog() verwenden würdest. Hier kann der User dann einfach die gewünschte Datei auswählen.

3. Falls du das weiterhin so tun möchtest verwende einfach if Bedingungen für beide Dateiformate

Func Dateioeffnen()
$gem = GuiCtrlRead($idgem)
$fl = GuiCtrlRead($idfl)
$rnr = GuiCtrlRead($idrnr)
$sImageFileName = "D:\TESTUMGEBUNG\Archiv\" & $gem & "\" & $fl & "\" & $gem & "_N_" & $fl &"_" & $rnr ; nur der Name!
If FileExists($sImageFileName & ".tif") Then
    ShellExecute($sImageFileName & ".tif")
    If @error Then Exit MsgBox(BitOR(4096, 16), "Fehler : ", "ShellExecute fehlgeschlagen !" & @CRLF)
Else
    If FileExists($sImageFileName & ".jpg") Then
       ShellExecute($sImageFileName & ".jpg")
       If @error Then Exit MsgBox(BitOR(4096, 16), "Fehler : ", "ShellExecute fehlgeschlagen !" & @CRLF)
    else
       MsgBox(BitOR(4096, 16), "Fehler : Datei nicht gefunden", $sImageFileName & @CRLF)
    endif
EndIf
endfunc

Obiger Code ist natürlich grausam und kann auch massivst verkürzt werden, insbesondere wenn du noch mehr Dateiendungen abdecken willst macht das auf diese Art wenig Sinn.

Sagen wir mal besser.

1. Es bringt dir nichts ein Edit Feld direkt nach der Erstellung auszulesen, denn da ist es ja noch leer. Du musst es schon auslesen nachdem der Benutzer etwas reingeschrieben hat (z.B. wenn er den "öffnen" Button drückt).

2. Die Variable $idEditProjekt ist ebenfalls leer und ungenutzt, deine Zeilen zum Ändern der Schrift bringen also rein garnichts

1. Du verwendest die Variable $rnr garnicht, sondern deklarierst sie nur, vermutlich willst du den Inhalt des Editfeldes $flst

2. In den Variablen $gem, $fl und $flst sind nicht die Werte gespeichert, welche du in das Edit einträgst, sondern die ControlID, also eine eindeutige ID mit der du das GUI Control auslesen, bearbeiten oder auch verschieben kannst.

3. Um den Inhalt eines Controls auszulesen verwendet man die Funktion guictrlread()

Nun lass mich mal eben zusammenfassen welche Dinge du hast:

1. Du hast einen funktionierenden Keylogger und kannst für jeden Tastendruck den vKey ermitteln

2. Du hast eine Funktion um das gesetzte Keyboard Layout auszulesen und vermutlich wäre es auch simpel das Keyboard Layout auf beliebige andere Sprachen in einer Testumgebung festzulegen

3. Du kannst prinzipiell die geloggten vKeys in ein eigenes Textfenster umleiten oder ggf. auch automatisiert alle 255 vKeys senden um diese mit dem gesuchten Zeichen "(" abzugleichen

Daraus ergibt sich, dass du eine vKeyMap und Zuordnung zum Keyboardlayout automatisiert für hunderte Sprachen vorab erstellen und für spätere Wiederverwendung in deinem oder weiteren Scripten speichern könntest.

Der einmalige Aufwand und Dauer solch eine Tabelle zu generieren dürfte sich in Grenzen halten und wäre dafür dann auch zuverlässig in der Zukunft einsetzbar.

Ich frag mich immernoch aus welchem Grund man systemweit mitschneiden sollte wann das Zeichen "(" gedrückt wurde. Was ist an diesem Zeichen so besonders und wozu brauchst du diese Erkennung?

Ich verstehe, wenn man diese Erkennung in einem eigenen Textfenster benötigt, um z.B. eine Autovervollständigung in einer IDE zu ermöglichen. Aber das begrenzt sich dann ja auf (d)eine Anwendung und erfordert kein systemweites Keylogging bzw. allgemein kein Keylogging, da du einfach den Inhalt des Textfeldes überwachen und abgleichen könntest.

Versteh das nicht falsch, ich bin einfach neugierig wozu man genau sowas braucht.

Zitat von Xenon

Alternativ könnte man auch das Admin-Skript nur einmal starten und dann über Interprozesskommunikation die auszuführenden Aktionen übermitteln.

Genau so würd ich das machen.

User Programm ohne Privilegien startet automatisch einen Admin Prozess, welcher unsichtbar im Hintergrund auf Befehle des User Programms wartet. Eine UAC Abfrage und fertig.

Naja da dort Linux läuft und das "terminal" vermutlich nix anderes ist als eine webbasierte SSH Verbindung würde ich die Webautomatisierung komplett weglassen und direkt per SSH zugreifen. Putty sollte entsprechend automatisierbar sein um sowohl login, als auch reboot zu bewerkstelligen, ganz ohne fehleranfällige Tastatur Emulation oder Webseitenautomatisierung.

EDIT:

Plink aus dem Putty Paket sollte das können was du brauchst

https://www.thegeekstuff.com/2017/05/putty-plink-examples/ (siehe Punkt 3)

https://the.earth.li/~sgtatham/putt…c/Chapter7.html (siehe Parameter zur PW Übergabe)

Nein da fehlt einfach nur ein

; Display the GUI.
    GUISetState(@SW_SHOW, $hGUI)

Bzw. wenn du noch was sehen willst musst du natürlich auch das guidelete und Programmende verhindern.

Zitat von AspirinJunkie

Edit: Ach du scheiße - was hab ich denn hier für ne Threadleiche ausgegraben? - der Thread ist ja zwei Jahre alt - wie kam der denn auf meine Startseite?

Vielleicht kam die Sortierfunktion des Forums mit dem Threaddatum durcheinander *hust*

Oder du lebst einfach in der Vergangenheit und hattest im Moment des Antwortens eine "Schalt-mich-in-die-Gegenwart" Sekunde.

Ich schlage vor wir suchen die Antwort in 400 Jahren und lassen den Thread bis dahin in der Vergangenheit.

"psexec" mag normalerweise vielleicht möglich sein, wenn sich Quell und Ziel PC im selben Netzwerk befinden und andere Vorraussetzungen (Gruppenrichtlinien, Firewall, Virenschutz) dafür erfüllt sind. Hier ist das aufgrund von Home Office und mangelnder VPN Verbindung aber nicht gegeben.

Da wir auch schon ein ähnliches Problem hatten und dem Benutzer das lokale Administrator Passwort nicht einfach so mitteilen konnten:

Du könntest per Teamviewer im Usercontext zugreifen.

Danach lädst du ein kleines Autoitscript hoch, welches hardcodierte Daten des lokalen Administrators enthält und via runas dort einen temporären Adminuser anlegt, dessen Daten du dann bedenkenlos dem User mitteilen kannst. Dein Script löscht sich nach getaner Arbeit am besten selbst, so dass keine Spuren davon auf dem Rechner zurückbleiben.

Den temporären Adminuser kannst du nach der VPN Installation über selbige Methode auch wieder löschen.

Es ist unwahrscheinlich, dass der User unter deiner Beaufsichtigung Unsinn mit dem temporären Adminaccount anstellt.

Alternativ kannst du natürlich auch versuchen die komplette Installation via runas Aufruf zu automatisieren. Aufwand ist aber deulich höher als einem User ein temporäres Admin Passwort mitzuteilen und ihn durch die Installation zu leiten.

Weitere Alternative... statt mit einem temporären Admin Account zu arbeiten kannst du auch den Benutzeraccount temporär zu den Administratoren hinzufügen.

Und zu guter letzt... wir nutzen Teamviewer zwar eher selten, aber ich erinner mich daran schonmal die Windowsanmeldemaske in einer Teamviewersitzung gesehen zu haben. Theoretisch sollte es dir so auch möglich sein dich mit deinem lokalen Administrator anzumelden und die Installation darüber durchzuführen. Zumindestens bei uns erscheint auf dem Superadministrator Account keine UAC Abfrage.

Dein Ziel ist es jederzeit das zur Uhrzeit passenden Desktophintergrundbild zu setzen. Dich stört, dass es bei der Nutzeranmeldung zu lange dauert bis das Script startet.

Daher würde ich das Script bzw. eine modifizierte Instanz davon bereits vor Windowsameldung als System ausführen. So ist gewährleistet, dass bei allen (bekannten / von dir gewählten) Usern schon vor der Anmeldung das passende Hintergrundbild gesetzt wird.

Das sollte grundsätzlich möglich sein, da der Wert dafür scheinbar nur in den Registryzweig des "current users" geschrieben werden muss. Der DLL Call deines Scriptes ist vermutlich nur zur Aktualisierung des gerade angezeigten Desktops notwendig, was bei Useranmeldung dann ohnehin erfolgt.

Für das Systemscript muss denke ich auch der Registrywert "Wallpaper" im Zweig "HKEY_USERS\S-1-5-21-xxxxxxx-xxxxxxx-xxxx\Control Panel\Desktop" geändert werden. Welche ID dein(e) User haben musst du vorher ermitteln.

Den Start des Systemscripts machst du über die Windows Aufgabenplanung mit der Option "unabhängig von der Benutzeranmeldung" ausführen, falls nötig mit dem User "SYSTEM" und "höchsten Privilegien".

So sollte bei Anmeldung bereits das korrekte Bild gesetzt sein und du kannst alle weiteren Änderungen dann über das Script des Nutzers machen, oder aber du lässt das Systemscript die eigentliche Arbeit weiterhin machen und führst im Userkontext nur periodisch den DLL Call aus, damit das Bild gemäß des aktuellen Registrywerts regelmäßig aktualisiert wird.