Beiträge von BugFix

Zitat von Moombas

BugFix würde das hier: https://docs.microsoft.com/en-us/windows/…-passport-login deiner Aussage nicht widersprechen?

Ich hatte das jetzt auf mein Notebook bezogen, und da ist das Betriebssystem nicht aktiv wenn der Scanner benutzt wird. Und diese Ebene ist m.W. für AutoIt unerreichbar.

Was dieses Hello-Gedöns angeht, das ist Win10, da bin ich außen vor.

Zitat von igillan

Hallo, gibt es eigentlich in Auto-IT die Möglichkeit den Status (erkannt oder nicht erkannt) des Fingerabdruckscanners, welcher bei der Anmeldung mit Windows

Ich habe ein Notebook, bei dem ich statt Start-Button drücken, den Finger über den Scanner ziehe. Dann fährt das Notebook hoch und der LogIn erfolgt. Also alles jenseits von der Betriebssystem-Ebene und somit für AutoIt unerreichbar.

Mit Sicherheit ein Werbetroll. Absolut identische Fake-Profile. Unsere Admins können ja die LogIn-IP sehen, da wird das sicher klar.

Also mit dem Entsorgen nicht zu lange warten.

Zitat von Floooooo24

es müsste doch ausreichen, wenn ich das selbst in meinem Code mache richtig?

Ja, vor dem Aufruf der UDF-Funktion und danach zurück. Ob der Fehler darin begründet liegt ist nur eine Vermutung, aber du kannst zumindest weiter eingrenzen.

Was natürlich auch sein kann:

Du verwendest für deine Ctrl x und y und für Breite u. Höhe nimmst du die Default-Werte. DAS ist immer eine schlechte Idee, da du dann keine Ahnung hast, welche Dimensionen deine Ctrl verwenden und ob sie nicht auch über den Fensterrand hinausragen.

Zitat von Floooooo24

_Metro_CreateButton

Ich kenne die Funktion nicht, vermute aber mal in der Richtung den Fehler.

Wenn das Erstellen von Control in eine Funktion ausgelagert wird, die selbst das Handle des Fensters anfordert, für das sie aktiv werden soll (ist ja sinnvoll), muss gewährleistet werden dass in der Funktion Folgendes zu finden ist:

Func _CreateCtrl($hGui,.....)
    Local $hOld = GuiSwitch($hGui)
    ...
    ...
    GuiSwitch($hOld)
EndFunc

Nur so ist gewährleistet, dass die Control auch sicher auf dem gewünschten Fenster erstellt werden.

Ich möchte für mein Backup zukünftig auf Fremdsoftware verzichten und das lieber mit systemeigener Software realisieren.

Da robocopy an Bord ist, möchte ich dieses nutzen.

Verstehe ich folgenden Parameter richtig:

/mon:<n>    Überwacht die Quelle und wird erneut ausgeführt, wenn mehr als n Änderungen erkannt werden.

Also:

robocopy wird einmalig gestartet (z.B. händisch, aber als Admin) und dümpelt dann immer im Hintergrund bis n Änderungen vorhanden sind, um sich dann selbst neu zu starten? Ich kann dann den User abmelden (PC bleibt an) und brauch dafür keinen Task anlegen?

/mir    Spiegelt eine Verzeichnisstruktur (entspricht /e plus /purge). Mit dieser Option mit der Option /e und einem Zielverzeichnis überschreibt die Zielverzeichnissicherheitseinstellungen.

Während ohne /mir neue Dateien hinzugefügt oder geänderte überschrieben werden, werden jetzt an der Quelle nicht mehr vorhandene Dateien auch auf dem Ziel gelöscht. - Korrekt?

Eine weitere Frage.

Gibt es eine Möglichkeit, störungs- und verlustfrei eine in Betrieb befindliche SQL-Datenbank (Firebird) mit robocopy zu sichern? Die Sicherung erfolgt zwar täglich, aber sollte im Tagesverlauf mal ein Crash passieren, sind halt die Daten dieses Tages noch nicht gesichert. Und solange z.B. Aufträge noch nicht erledigt und als Lieferscheine in Papierform vorliegen, wäre eine Rekonstruktion schwierig bis unmöglich. Ist zwar in den letzten 20 Jahren nie passiert, aber man kennt ja die Pferde vor der Apotheke.

Ein reines Kopieren über den Explorer klappt nur, wenn nicht gerade ein Nutzerzugriff erfolgt. Die Quelle wird nicht kompromittiert, aber die Sicherung ist unter Umständen fehlerhaft. Das zugehörige Backuptool stoppt erst die Dienste ("Firebird Guardian" und "Firebird Server") und führt dann das Backup durch. - Kann ich natürlich im laufenden Betrieb nicht tun.

Danke schon mal für die Mühe, die ich euch gemacht habe.

Öffne ein AutoIt Skript und drücke STRG +1

Da findest du einen Punkt "Other Tools".

Und dort den Abbrev Manager.

Edit:

Voraussetzung ist die Installation von "SciTE4AutoIt"

[Kann ich mir nicht entgehen lassen]

Zitat von Alina

Sogar die Folie die extra für den Transport noch mal um die Bücher gebunden wurde war zum Teil geöffnet und mit Zollaufkleber wieder zugeklebt.

Mit E-Books wäre das nicht passiert.

Mal etwas außen vor:

Welchen Sinn hat es, sich den Wert nach dem Verschlüsseln in die Konsole oder MsgBox auszugeben?

Und wenn ich den Wert speichere, dann doch sinnvollerweise unverändert und niemals als String.

Zitat von Andy

du bist einer der wenigen "Programmierer" (aka Menschen überhaupt) die ich kenne, die ihren Arbeitsablauf rekapitulieren, analysieren, nach Verbesserungen suchen und diese umzusetzen versuchen.

Vielen Dank für die   .

Ich kann nicht mal erklären, warum das so ist, aber irgendwie bin ich (mit wenigen Ausnahmen, z.B. QRCodeCreator) nie wirklich zufrieden mit dem Ergebnis. Dadurch gucke ich ab und an mal über alte Skripte drüber und prüfe, ob mit dem Wissen, das man ja immer weiter ansammelt, noch Verbesserungen drin sind. Ist vielleicht auch ein wenig meiner Arbeit geschuldet. Im Qualitätsmanagement gibt es eine Validierungspflicht für Software, d.h. alle 3 Jahre nehme ich mir für alle genutzte Software deren Einsatzbeschreibung vor (Was soll gemacht werden? Welcher Aufwand ist erforderlich? Wird das Ziel erreicht? Sind Verbesserungen möglich/erforderlich?). Das prüfe ich und wenn alles OK ist kommt ein Haken dran und 'Validierung unverändert gültig'. Werden Änderungen im Prozess notwendig, wird entsprechend neu validiert.

Das ist wirklich sinnvoll, denn im Abstand von 3 Jahren blickt man aus einem anderen Winkel auf die Prozesse und u.U. haben sich ja auch Randbedingungen geändert, die man berücksichtigen muss.

Zitat von Velted

besteht der 'Stumpfsinn' für mich eher in der Tatsache, dass man nach wie vor 'Workarounds' braucht

Das ist nicht von der Hand zu weisen. Da wir es aber nicht beeinflussen können, ist das ein Punkt, der mich nicht mehr zur Weißglut treibt.

In meinen eigenen Skripten packe ich diese Workarounds manchmal in "Pseudo-Makro"-Funktionen, ist aber ein rein optisches Kaschieren der dafür genutzten Funktion, programmiertechnisch nicht zwingend ein Mehrwert. Für o.a. Bsp. sieht das dann so aus:

Global $GUIHWND = _GuiHwnd   ; mein "Pseudo-Makro"

GUICreate('Test')
_NeedParentHwnd()
GUISetState()
; ...
; ...
; ...

Func _NeedParentHwnd()
    ConsoleWrite('Parent: ' & $GUIHWND() & @CRLF)
    ; ...
    ; ...
EndFunc

Func _GuiHwnd()
    Local $idDummy = GUICtrlCreateLabel('',0, 0, 1, 1)
    Local $hGui = _WinAPI_GetParent(GUICtrlGetHandle($idDummy))
    GUICtrlDelete($idDummy)
    Return $hGui
EndFunc

Was Änderungswünsche im nativen AutoIt angeht - da könnten wir sicher ganze Bände mit füllen - aber: Es is, wie es is!

Zitat von hpb

und beginne noch mal von vorne.

Ein Tipp:

Schildere NICHT wie DU es machen möchtest - das ist die Ursache des oft zitierten XY-Problems.

Gehe absolut neutral, gewissermaßen als Außenstehender, an die Sache heran und liste auf

- Ausgangssituation (Datenlage etc.)

- Zielsituation

- zu beachtende Randbedingungen

Dann sind Lösungsvorschläge möglich, die u.U. überhaupt nichts mit deinen Gedankengängen zu tun haben, aber effektiv zur Lösung führen.

hpb

Also hier zeigt sich ein Kommunikationsproblem. Du kommst mit immer neuen Bedingungen um die Ecke. Das lässt eine saubere Lösung gar nicht zu.

Definiere bitte bis zum Ende deiner geplanten Arbeitskette alle Operationen. Nicht das wieder nach Lösung eines Problems das Problem erweitert wird.

Und nochmal in der Hoffnung das du es verinnerlichst: Wenn du FileGetAttrib verwendest ist FileExists sinnlos!!

DARUM:

Func _Bla($_path)
    Local $sAttrib = FileGetAttrib($_path)
    If @error Then Return ; --> Ordner existiert nicht !!!
    ; ...

Zitat von hpb

And Ergebnis von $sNewDate Then

????

Du solltest dich mal entscheiden, wie deine Ordner nun tatsächlich heißen, "E:\Test" oder "...\2022-02-06".

Ich vermute, dass du die Attributprüfung auf den Ordner "Datum" durchführen möchtest, dann brauchst du doch das Geschwurbel davor nicht.

1. Mit _DateAdd den gewünschten Ordnernamen generieren

2. Mit FileGetAttrib diesen Ordner auf die gewünschten Attribute prüfen, was automatisch die Prüfung auf dessen Existenz beinhaltet! FileExists ist überflüssig!

Zitat von hpb

Das ist die Lösung, die mir auch bei weiteren Abfragen helfen wird.

Wie allerdings Bitnugger völlig richtig bemerkte, ist FileExists hier überflüssig, da FileGetAttrib nur dann ein Ergebnis liefert, wenn der Pfad existiert. Die Abfrage ist also doppelt gemoppelt.

Als ich gerade ein altes Skript von mir aktualisiert habe, ist mir aufgefallen, wie man doch ohne Nachzudenken "übliche Verfahrensweisen" ohne diese zu hinterfragen einfach übernimmt.

Wenn wir uns die UDF für nicht-native Control ansehen fällt auf, dass ausnahmslos alle UDF, die intern das parent or owner window benötigen, dieses als Parameter in der _Create-Funktion anfordern.

Da ich das in den UDF so gesehen habe, habe ich das auch für meine Skripte ohne zu hinterfragen übernommen.

Jedenfalls bis ich das o.a. Skript überarbeitet habe. Ellenlange Parameterangaben in Funktionen sind dem Handling nicht gerade zuträglich. Deshalb habe ich nach Optimierung gesucht und dieses war das Parent-Handle: Es ist sinnfrei dieses anzufordern!

Warum? - Es gibt nur 2 Situationen der Control-Erstellung:

1. GuiCreate() wurde aufgerufen und ich erstelle nachfolgend Controls

2. GuiSwitch() wurde aufgerufen und ich erstelle nachfolgend Controls

In beiden Fällen befinde ich mich im Kontext des Parent/Owner-Window. Somit kann ich es bei meiner Control-Erstellung in einer UDF doch auch einfach erfragen:

Local $idDummy = GUICtrlCreateLabel('',0, 0, 1, 1) ; dummy control creation to get the current gui handle
Local $hGui = _WinAPI_GetParent(GUICtrlGetHandle($idDummy))
GUICtrlDelete($idDummy)

Das sind 3 Zeilen mehr Code, die aber einen Parameter überflüssig machen. Das sollte es doch wert sein.

Das echte Dummy-Ctrl (GUICtrlCreateDummy) kann dafür nicht verwendet werden, da es ein Fake-Ctrl ist, das kein Handle besitzt. War mir nicht bewusst, wurde aber beim Testen klar.

Falls also die Übergabe des Parameters einen tieferen Sinn haben sollte, erschließt sich dieser mir nicht. Vielleicht haben alle Autoren nach den 3 Lebensleitlinien gehandelt:

• Das haben wir schon immer so gemacht!
• Das haben wir noch nie so gemacht!
• Da könnte ja jeder kommen!

Zitat von Musashi

Du meinst sicher SCRIPT BREAKING CHANGE

Na klar - aber eine Chance ist es doch auch?

Neu v 0.14

Für den Titel können Fontname und -größe bestimmt werden.

SCRIPT BREAKING CHANGE: Parameter für Parent-Gui nicht mehr erforderlich.

Oder um es mit Otto zu sagen:

Zitat von Aus Songtext "Dänen lügen nicht"

Du hast geglaubt, du gehörst zu denen
Denen Dänen alles durchgehen lassen, hä?.
Nein, Nein, mein Freund.
Ein Däne sagt: Ich krieg Geld von Dir.
Du lachst ihn aus, fragst: wieso von mir?
Doch sein Ballermann überzeugt Dich schlicht. Und Du siehst ein Dänen Lügen nicht!

So gehts auch und passt für jeden beliebigen Pfad:

$sFolder = "E:\2022-02-06"

_DeleteLastYear($sFolder)

Func _DeleteLastYear($_sFolder)
    Local $aPath = StringRegExp($_sFolder, '(.+)\\(\d{4})(-\d{2}-\d{2})$', 3)
    Local $RemoveDir = StringFormat('%s\%s%s', $aPath[0], $aPath[1]-1, $aPath[2])
    Return DirRemove($RemoveDir)
EndFunc

Zitat von BugFix

Auch wenn es erst mal dämlich klingt: Rufst du die Funktion copy auch auf? - Ist mir schonmal passiert: Funktion erstellt aber nicht aufgerufen.

Zitat von hpb

Danke für den Hinweis

Kleiner Tipp: Lies immer alle Posts, wie du siehst hatte ich dich auch schon darauf hingewiesen.