1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. misterspeed

Beiträge von misterspeed

  • FileOpenDialog zeigt Dateiname nicht vollständig an

    • misterspeed
    • 23. September 2018 um 09:00

    https://social.msdn.microsoft.com/Forums/en-US/d…forum=vbgeneral

    https://social.msdn.microsoft.com/Forums/vstudio…ified?forum=wpf

    Anscheinend wirklich ein Windows Bug, der nachwievor nicht behoben wurde. Autoiter hat geschummelt und nicht den vorausgefüllten Dialog geöffnet.

    Workaround:

    Evtl. kann man mit den input / edit ctrl UDF Funktionen die Anzeige des Inputs manipulieren (zum Textanfang "scrollen" oder den Text neusetzen). Ich erinnere mich noch ganz schwach daran sowas selbst schonmal gehabt und entsprechend behoben zu haben.

  • FileOpenDialog zeigt Dateiname nicht vollständig an

    • misterspeed
    • 23. September 2018 um 08:43

    Hat aber wohl eher nichts mit Autoit zu tun, da der FileOpenDialog ein Windowsbestandteil ist.

    Um die Ursache zu finden sollten diejenigen mit und ohne diesen Fehler mal mehr Details zur genutzten Umgebung posten.

    Genaue Windows Version? -> CMD: "winver" (1703 / 1709 / 1803 / 1809 ???)

    Standard Theme? (Bitnugger nutzt jedenfalls nicht den Standard)

    DPI verändert? (wahrscheinlichste Ursache für Anzeigefehler)

  • Windows 10 Lizenz vorhanden?

    • misterspeed
    • 17. September 2018 um 18:06
    Zitat von alpines

    Aber wer hat im BIOS ein 10 Key und dann niedrigeres OS?

    Gibt genügend Firmen die nachwievor aus diversen Gründen Windows 7 einsetzen und sich kein Zwangsupdate durch Microsoft vorschreiben lassen.

    Die Notebooks oder Rechner stammen in der Regel von großen OEM Herstellern wie DELL, HP, LENOVO usw. und werden normalerweise mit Lizenzschlüsseln im BIOS/UEFI für das jeweils aktuellste Windows Betriebssystem geliefert.

    Wir haben hier zum Beispiel auch einige Notebooks, welche ursprünglich für W8 vorgesehen waren bzw. damit ausgeliefert wurden. Teilweise werden die Geräte mit Up- oder Downgraderechten verkauft, es bleibt also letzlich dem Unternehmen überlassen welches Betriebssystem nun real zum Einsatz kommt. Damit dies möglich ist werden normalerweise Keys für mehrere Windows Editionen hinterlegt.

    Aus Erfahrung kann ich sogar bestätigen, dass selbst Notebooks von DELL, die mit W8 geliefert wurden, ohne weiteres auch mit W10 installiert werden können und sich dann auch automatisch aktivieren obwohl eine Prüfung bei DELL ergibt, dass das Notebook nicht entsprechend lizenziert sein sollte und dementsprechend auch kein W10 Installationsmedium downloadbar ist.

    Rechtlich natürlich problematisch solch ein Notebook dann tatsächlich mit W10 zu betreiben.

    Den realen Lizenzschlüssel bekommt man als Kunde jedenfalls schon lange nicht mehr zu sehen. Bei Windows 7 waren noch Aufkleber auf den Rechnern, heute versteckt sich das ganze rein Digital auf dem Mainboard. Es ist für mich als Kunde also nichtmal mehr ohne weiteres nachvollziehbar welche Windows Edition nun lizenziert ist und welche nicht.

    DELL gibt einem bei Reparaturen (Mainboardtausch) im übrigen einen Ersatzschlüssel in Papierform. Die Ersatzmainborads haben angeblich keine Keys integriert. War bei uns trotzdem ohne Keyeingabe aktiviert.

  • User ermitteln der Zugriff auf geöffnete Datei hat

    • misterspeed
    • 7. September 2018 um 18:26

    Prinzipiell kann man das von Hand nachschauen:

    Computerverwaltung -> Freigegebene Ordner -> Geöffnete Dateien

    Sehr wahrscheinlich lassen sich die dort angezeigten Informationen auch per WMI abfragen.

    Beim kurzen Googlen hab ich erstmal nur den Verweis auf das hier gefunden:

    https://docs.microsoft.com/en-us/windows-…mands/openfiles

    Code
    C:\Users\MaxMuster>Openfiles.exe /query /s localhost
    
    Kennung  Zugriff durch        Typ        Open File (Pfad\ausführbare Datei)
    ======== ==================== ========== =====================================
    33554442 MaxMuster             Windows    C:\Users\MaxMuster\Desktop
    231      MaxMuster             Windows    C:\Users\
    26843584 MaxMuster             Windows    C:\Users\MaxMuster
    40265369 MaxMuster             Windows    C:\Users\MaxMuster\Desktop
    40265374 MaxMuster             Windows    C:\..\AutoIt v3 Script (neu) (4).exe
    40265374 MaxMuster             Windows    \srvsvc

    Damit lassen sich remote geöffnete Dateien auch gleich schließen.

  • Windows 7 Lockscreen

    • misterspeed
    • 30. August 2018 um 19:24

    :thumbup:

  • Windows 7 Lockscreen

    • misterspeed
    • 29. August 2018 um 19:25

    Naja bei einer Standortanzahl im 4-Stelligen Bereich sollte eine professionelle Lösung doch finanziell kein Problem darstellen. Ein selbstgestrickter Sperrbildschirm der viel einfachher umgehbar wäre als das Original kommt bei so einer Unternehmensgröße ja wohl eher nicht in Frage.

    Würde da eher eine serverbasierte Lösung wählen. Irgendwo kommen die "Reservierungen" ja her... vermutlich zentral von einer Webanwendung oder einem darunter liegenden Emailsystem. Deine Anwendung könnte also theoretisch an zentraler Stelle alle "Reservierungen" einsehen und dann weitere Aktionen damit durchführen. z.B. ein Displayterminal in jedem Standort aktualisieren, vergleichbar mit den Displays in McDonalds Fillialen. Das würde zwar immernoch ein zusätzliches Gerät je Standort bedeuten, aber umsonst ist nunmal nichts und ein kleines Tablet irgendwo an der Wand hinter dem Tresen kostet wirklich nicht die Welt.

    Alternativ könnte dein Script auch die zuständigen Mitarbeiter direkt kontaktieren. Heute hat jeder ein Smartphone... sei es privat oder dienstlich. Kleine geschäftliche App die sich durch vibrieren bemerkbar macht und damit signalisiert... "schau auf deinen Rechner" sollte ja langen.

    Weiterer Vorschlag... es gibt USB leuchten, die farblich signalisieren könnten wenn der Nutzer neue Nachrichten am Rechner hat. Wäre deutlich günstiger als ein Tablet oder Display. Alternativ dazu gibt es auch simple und billige LCD Laufbänder ohne viel Grafik Schnickschnack, die via USB angesteuert werden können. Was da für euch in Frage kommt und am besten automatisierbar ist müsstet ihr selbst evaluieren. Das Bild unten ist nur zur Verdeutlichung und vermutlich eher nicht ganz das was ihr nutzen würdet. Sowas gibts sicher auch in größer und mit anständigem Gehäuse.

    Grundsätzlich ist das aber alles eigentlich unnötiger Schnickschnack. Wenn es wichtig ist, dass "Reservierungen" in Zeitfenster x bearbeitet werden, dann muss man den Mitarbeitern eben Zeitfenster x als festes Prüfintervall vorschreiben. Wer danach immernoch nur einmal am Tag auf den Rechner schaut bekommt eben einen netten Hinweis auf die aufgestellten Regeln.

    784-07.jpg6010-2.jpg

  • Windows 7 Lockscreen

    • misterspeed
    • 28. August 2018 um 22:05

    Ahja... Windows spielt übrigens Ton des angemeldeten Benutzeraccounts auch dann ab wenn der Account gesperrt ist. Eine Audio Benachrichtigung wäre also jederzeit möglich, sofern das System über aktive Lautsprecher verfügt.

    Beispiel:

    Code
    Run("rundll32.exe user32.dll,LockWorkStation")
    
    While 1
        Sleep(2000)
        SoundPlay(@WindowsDir & "\media\tada.wav",1)
        SoundPlay("")
    WEnd

    EDIT: Falls das Script keinen Ton abspielt prüfe ob die verwendete Tondatei auf deinem Betriebssystem existiert und falls nicht ersetze den Aufruf durch eine vorhandene Datei. Unter Windows 7 existiert dieser Systemton jedenfalls.

  • Windows 7 Lockscreen

    • misterspeed
    • 28. August 2018 um 21:47

    Die GUI des Sperrbildschirms läuft nicht auf deinem Benutzeraccount. Schon alleine deswegen kann ein Script, das im Kontext deines Benutzers läuft diese GUI aus gutem Grund nicht manipulieren. Desweiteren ist es nicht möglich die GUI zu überlagern, da der Sperrbildschirm ja genau das unterbindet... alle GUI Elemente deines Benutzeraccounts werden ausgebelendet. Wenn man den Sperrbildschirm manipulieren möchte muss dein Script im Kontext des Users SYSTEM laufen.

    Anstatt so tief in Windows interna Einzugreifen und ggf. sogar eine Massive Sicherheitslücke zu öffnen würde ich mir an deiner Stelle eher Gedanken machen was du eigentlich warum erreichen willst. Wozu muss irgendjemand informiert werden wenn doch garniemand am Rechner ist? Der Rechner ist gesperrt, also arbeitet da auch niemand, der deine Meldung lesen könnte. Davon ab werden Änderungen an Systemdateien früher oder später zu Problemen führen, spätestens dann wenn Windows den Eingriff erkennt und versucht dein System wieder in Originalzustand zu versetzen.

    Wenn die aktive Useranmeldung stört schreib dir lieber ein Script, dass den Benutzer sauber nach x Minuten Inaktivität abmeldet. Das kann auch problemlos passieren solange der Account angemeldet und gesperrt ist, bzw. evtl. sogar ganz ohne Script über die Computer- / Benutzer- / Gruppenrichtlinien festgelegt werden.

  • Softwareinventarisierung

    • misterspeed
    • 30. Juli 2018 um 17:18
    Zitat von Lashandan

    Ich bastel jetzt mal noch an der Funktion mittels 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall' und werde mich hier wieder melden

    Denk dabei auch an unterschiedliche Speicherorte für 32 und 64bit Software. Je nach System und installierter Software muss zusätzlich auch der SysWOW Zweig geprüft werden.

  • Softwareinventarisierung

    • misterspeed
    • 20. Juli 2018 um 18:52

    Da dein Webservice POST Daten entgegennimmt ohne vorherige Authentifizierung (hab jedenfalls beim Überfliegen nichts davon gesehn) ließe sich das ganze massiv paralelisieren.

    Anstatt das Script zentral von einer Adminstation auszuführen könnte auch jeder Clientrechner im Netzwerk seine eigenen Scriptinstanz ausführen und seine Daten selbsständig an den Webservice melden. So machen das auch verbreitete "professionelle" Lösungen wie z.B. OCS Inventory und GLPI

    Vorteil:

    - Alle Clients melden paralell, somit extreme Zeitersparnis

    - Alle Clients könnten periodisch Updates über ihre derzeitige Konfiguration versenden (z.B. über täglichen Windows Task), somit hast du stets aktuelle Daten über die Softwarekonfiguration

    Nachteil bzw. Mehraufwand:

    - Das Script muss einmalig auf dem Clientrechner platziert und entsprechend als Task eingerichtet werden

    - Der Webservice bzw. dessen API muss im kompletten Netzwerk verfügbar sein (evtl. Probleme mit Clients die mobil und nicht immer im lokalen Netzwerk angemeldet sind)

    - Missbrauchspotential, da Webservice ohne Authentifizierung ansprechbar ist -> evtl. richtige API mit Authentifizierung einsetzen

    - Client Script sollte über Selbstupdate Funktion verfügen, damit du einfach und schnell alle Clients austauschen kannst wenn du eine Änderung des Clients benötigst

    - Fehlermeldungen vielleicht besser unsichtbar per Email versenden anstatt per msgbox ausgeben, um Benutzer nicht zu verwirren

  • Firefox sauber schließen

    • misterspeed
    • 13. Mai 2018 um 19:49

    Verwende doch einfach inetget() und öffne die damit heruntergeladene Exceltabelle dann mit shellexecute().

    Ahja und ich würd die Firma für die ich tätig bin nicht öffentlich im Internet bekanntgeben, insbesondere wenn du hier Details über interne Dienste/Webseiten und eure Arbeitsabläufe Preis gibst.

    Für die Lösung des Problems ist die exakte URL irrelevant, also einfach teilweise zensieren ;)

  • Vorhandene! bcdedit.exe kann NiCHT vom Script ausgeführt werden weil es diese exe nicht findet

    • misterspeed
    • 5. Mai 2018 um 09:07

    Hab ich zwar nie getestet / benutzt, aber wozu so umständlich / unschön? Ich würde grundsätzlich niemals mit Windows Systemdateien / Verzeichnissen rumspielen wenn das nicht zwingend notwendig ist. Dafür benötigt man im Übrigen normalerweise auch erhöhte Rechte.

    Selbst wenn "sysnative" in 64bit Scripten nicht verfügbar ist kann man doch trotzdem bei Bedarf (32bit Script) damit arbeiten. Wenn man ein 64bit Script hat nutzt man eben die ganz normalen "SYSTEM32" Pfade und braucht garnichts weiter tun. Wenn du aus 64bit Scripten auf die 32bit CMD console zugreifen willst ersetzt du System32 eben mit "SysWOW64"

    Könnte dann so ausschaun:

    AutoIt
    ;#AutoIt3Wrapper_UseX64=n
    #AutoIt3Wrapper_UseX64=y
    
    If @AutoItX64 <> 1 And @OSArch = "X64" Then
        $sCMD32console = @ComSpec
        $sCMD64console = StringReplace(@ComSpec,"system32","Sysnative")
        $debug = "64bit OS + 32bit Script:" & @CRLF
    Else
        If @OSArch = "X86" Then
            $sCMD32console = @ComSpec
            $sCMD64console = -1 ; nicht verfügbar, da 32bit OS
            $debug = "32bit OS + 32bit Script:" & @CRLF
        Else
            $sCMD32console = StringReplace(@ComSpec,"system32","SysWOW64")
            $sCMD64console = @ComSpec
            $debug = "64bit OS + 64bit Script:" & @CRLF
        EndIf
    EndIf
    
    ConsoleWrite($debug & "32bit Console: " & $sCMD32console & @CRLF & "64bit Console: " & $sCMD64console & @CRLF)
    
    Exit
    Alles anzeigen
  • Vorhandene! bcdedit.exe kann NiCHT vom Script ausgeführt werden weil es diese exe nicht findet

    • misterspeed
    • 4. Mai 2018 um 22:15

    Da das Problem mit der Windows FS Redirection zu tun hat (System32 / SysWOW64) wäre es durchaus denkbar, dass die "Redirections" oder evtl. das bereits umgeleitete "Workingdir" an Unterprozesse vererbt werden, genauso wie das mit "Admin-Rechten" geschieht. Ist aber nur eine Vermutung. Alternativ zu einem 64bit Autoit Script könntest du im Übrigen auch den virtuellen "Sysnative" Ordner nutzen um von einer 32bit Anwendung auf 64bit Systemdateien zuzugreifen.

    http://www.samlogic.net/articles/sysna…bit-windows.htm

  • Programm als Admin ausführen mit eingeschränkten Rechten

    • misterspeed
    • 3. Mai 2018 um 22:24
    Zitat von NO1 :-)

    Edit: Setze das Thema dann bitte noch auf erledigt, wenn alles klar ist.

    Er war nichtmal der Threadstarter und hat den Thread nur entführt :P

  • Programm als Admin ausführen mit eingeschränkten Rechten

    • misterspeed
    • 3. Mai 2018 um 21:40
    Zitat von NO1 :-)

    Da war wohl jemand schneller ... hab wahrscheinlich zu viel geschrieben... UPS

    Selber Schuld, Anleitungen für diese Variante gibts ja schon etliche im Netz, also warum nochmal detailiert beschreiben... :P

  • Programm als Admin ausführen mit eingeschränkten Rechten

    • misterspeed
    • 3. Mai 2018 um 21:20

    Man kann die Benutzerkontensteuerung für ausgewählte Anwendungen über die Windows Aufgabenplanung umgehen.

    Das Prinzip ist unter anderem hier beschrieben:

    https://www.petri.com/bypass-uac-using-desktop-shortcut

    Eine Verknüpfung ist dafür nicht notwendig, der geplannte "Task" kann auch aus einer beliebigen Anwendung heraus gestartet werden.

    Wenn man damit ein wenig spielt kann man sich vermutlich auch ein Konstrukt basteln, welches beliebige dynmaisch definierbare Anwendungen über einen einzigen "Geb mir Rechte Task" mit erhöhten Rechten startet.

    Adminrechte werden allerdings einmalig für die Installation des "Tasks" benötigt, danach sollte das auch als einfacher Benutzer ausführbar sein.

  • Wie verknüpfe ich die LocalAppData-Variable mi einem Pfad unterhalb davon?

    • misterspeed
    • 2. Mai 2018 um 19:19
    Zitat von ibicis

    Ich fand dieses Bsp. bei meiner Suche nach dem Löschen von Ordnern und Sub-Ordnern hier (Vorschlag vom User "/dev/null"): https://www.autoitscript.com/f…b=comments#comment-113788

    Einen Fehler gibt es bei der Ausführung nicht, der Befehl funktioniert wie erwünscht. Ich interpretiere den Punkt als Wildcard für "alles darunter", weiß aber nicht wirklich, wofür er steht.

    Oh sorry wusste nicht, dass Wildcards bei dirremove möglich sind und im konkreten Fall "nur" alle Unterordner gelöscht werden (sollen). Sah für mich wie ein Flüchtigkeitsfehler aus.

  • Wie verknüpfe ich die LocalAppData-Variable mi einem Pfad unterhalb davon?

    • misterspeed
    • 2. Mai 2018 um 18:00

    Der Fehler hier ist doch recht offensichtlich. Da ist ein "Punkt" am Ende des Pfades, welcher wohl auch die Ursache dafür sein wird, dass der Aufruf scheitert.

  • Programm als Admin ausführen mit eingeschränkten Rechten

    • misterspeed
    • 2. Mai 2018 um 06:25

    Da die Software selbst geschrieben ist würde ich erstmal prüfen ob die Administratorrechte wirklich notwendig sind, bzw. wofür.

    Da der Sinn der Software nicht wirklich ein administrativer ist sollte das doch auch ohne zu bewerkstelligen sein.

    Sofern die Rechte nur für eine Selbstupdate Routine benötigt werden würde ich dir empfehlen die Updateroutine als Systemdienst auszulagern (vergleiche z.B. Firefox). Alternativ könnte man das im Unternehmen auch passiv lösen, d.h. du rollst das Update serverseitig auf alle Clients aus und benötigst dann nur auf Serverseite administrative Rechte auf den Clients (z.B. Domänenadministrator Account ).

  • Quelltext auslesen

    • misterspeed
    • 6. April 2018 um 21:51

    Ganz interessant, was die API alles anbietet...

    https://www.asus.com/support/api/product.asmx

    https://www.asus.com/OfficialSiteAPI.asmx

    Nur scheinbar nicht so wirklich dokumentiert.

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™