Beiträge von Runa

Mars: Meine Erfahrung hierzu: Wenn man nicht mit Handles arbeitet wird der Speicher nicht wieder frei gegeben. Das Problem hatte ich mal bei einem Dienst den ich zuerst via svrany laufen hatte und anschließend mit AlwaysUp. Letzteres schickte mir pro Tag 19 Mails dass das Programm über 150MB Arbeitsspeicher reserviert hatte. Und das, obwohl ich keine Maps verwendet habe nur einen Array zu dem keine Daten hinzugefügt werden und sonst fast ausschließlich Dateibefehle. Ansonsten nur noch einen Ping und das herunterladen einer XML-Datei die dann via FileFunktionen wieder eingelesen wurde. Kaum sind alle Dateioperationen (auch der Ini-Scheiss) auf Handles umgestellt worden habe ich das Problem nicht mehr beobachten können.

Wenn du den Speicher vollknallst, hast du wohl irgendwo ein memleak produziert. Prüfe am besten Mal, ob du jeden Speicher, den du anforderst auch wieder freigibst.

Übliche Kandidaten hierfür sind IniWrites, IniReads, FileWrites, FileReads, ... wenn dein Programm länger läuft, sollte all dies über Handles geschehen, da der Speicher sonst nicht freigegeben wird. Dies kann schnell zu einem memleak führen:

Nehmen wir an, du hast eine Ini-Datei. Diese Ini-Datei ist - der Einfachheit halber 1MB groß. Jetzt stößt du einmal pro Sekunde 5 IniWrites an und gehst dabei über den FileNamen.

Das bedeutet, dass AutoIt die Ini-Datei 5x pro Sekunde in den Speicher läd - kurz 5 MB/s. Ausgehend von - wieder der Einfachheit halber - 5 GB Arbeitsspeicher bedeutet dies, dass dein Speicher in 1000 Sekunden (also etwa 15 Minuten) aufgebraucht wäre, und es nicht möglich wäre, weiteren Speicher zu beziehen.

EDIT: Unnützen kram rausgeworfen.

Eigentlich ist {BREAK} und {PAUSE} exakt die selbe Taste. Break funktioniert - Pause nicht.

^BREAK = STRG + pause / untbr
^PAUSE = STRG + SHIFT + pause / untbr

Daran liegt dies.

Ich empfehle ein "ConsoleWrite" in beiden Funktionen, damit du prüfen kannst, ob die Tastenkombination das Problem ist, oder die Funktion an sich. Hättest du dies getan, hättest du gemerkt, dass die Tastenkombination problemlos funktioniert.

#include <File.au3>


;ESC-Taste um alles sofort abzubrechen
HotKeySet("{ESC}","_AllesAbbrechen") ;Killt Project Excel und Excel selbst und beendet sich


Func _AllesAbbrechen ()
   ConsoleWrite('ProcessClose("Alles.")')
   Return
EndFunc


HotKeySet("+{ESC}", "ProjectExcelAbbrechen")


Func ProjectExcelAbbrechen () ;Stoppt das laufende Modul und killt NUR Project Excel!


	;Projekt Excel killen
	ConsoleWrite('ProcessClose("Projekt Excel.exe")')
	Return


   ;Excel-Fenster auswaehlen
    Opt("WinTitleMatchMode", 2)
    WinActivate("Microsoft Excel")
    WinWaitActive("Microsoft Excel")


	;Laufendes Excel-Modul stoppen
	Sleep(500)
	Send("^{PAUSE}")


   Exit
EndFunc


$a = 1


While $a = 1
   Sleep(1000)
WEnd

https://msdn.microsoft.com/en-us/library/…bedded.70).aspx

"Long value from -10,000 to 10,000"

Windoof ist wieder mal sehr verwirrend:

https://msdn.microsoft.com/en-us/library/…6(v=vs.85).aspx

Nach der Seite sind es -100 bis 100... Aber der Artikel davor ist genau für das Objekt, dass du zu verwenden gedenkst.

#include <Array.au3>


Dim $sHTML, $aRows, $aCells[1] = ["PLACEHOLDER"]					; Wir brauchen ein Element im Array, damit es ein Array ist


$sHTML = FileRead("Neues Textdokument.html")						; Hier eben schnell dein HTML gepasted... ;)
$sHTML = StringReplace($sHTML, '<td align="center">', "<td>")		; Das unnötige HTML aus der Tabelle wegwerfen...
$aRows = StringRegExp($sHTML, "(?s)<tr>(.+?)</tr>", 3)				; Alle Reihen suchen => (?s)Lass den RegEx auch über mehrere Zeilen laufen


For $i = 0 To UBound($aRows) - 1									; Für jede Reihe...
	If StringInStr($aRows[$i], "MonObj") Then						; Nur die Zeilen übernehmen, die MonObj enthalten - das scheinen die Datensätze zu sein, die du brauchst?
		$aTemp = StringRegExp($aRows[$i], "(?s)<td>(.+?)</td>", 3)  ; Alle Daten aus der Reihe lesen
		_ArrayConcatenate($aCells, $aTemp)							; Beide Arrays zusammenführen
	EndIf
Next


_ArrayDelete($aCells, 0)											; Erstes Element - also den Placeholder - löschen
$aCells = _2D(5, Round((UBound($aCells)-1)/5, 0), $aCells)			; 5 Spalten hattest du - und (Anzahl der Datensätze/Anzahl der Spalten) Reihen...
_ArrayDisplay($aCells)												; Zeige an, was du gefunden hast...


Func _2D($iX, $iY, $aSource)										; Wandelt den 1D-Array in einen 2D-Array um - verlangt wird hierfür der 1D-Array, die Anzahl der X-Stellen und der Y-Stellen (wie im Koordinatensystem)
	Local $aReturn[$iY][$iX]
	$i = 0
	For $iY_2 = 0 To $iY - 1
		For $iX_2 = 0 To $iX - 1
			$aReturn[$iY_2][$iX_2] = $aSource[$i]
			$i += 1
			If $i = UBound($aSource) Then ExitLoop
		Next
		If $i = UBound($aSource) Then ExitLoop
	Next
	Return $aReturn
EndFunc

Die gelöschte Lösung von oben - voll kommentiert Vielleicht hilft dir das ja weiter.

Zitat von AspirinJunkie

Du meinst If StringInStr(FileGetAttrib($sMyFolder & $sFileName), "D") Then ist verständlicher als If @extended Then?

Erfahrungsgemäß: Definitiv. Das eine versteht praktisch jeder, weil es was zu verstehen hat, das andere nicht, weil es immer was anderes bedeuten kann (nämlich bei jeder Funktion), direkt nach der Funktion abgefragt werden muss, und zudem noch nicht mal ersichtlich ist, was es eigentlich tut.

Könnte man. Es macht aber kaum einen Unterschied, außer, dass diese Makros - genau wie binäre Flags - für Neulinge deutlich schwieriger verständlich sind.

Er sucht prinzipiell Dateien in einem Ordner. Das wird einmal Initialisiert "FileFindFirstFile" und dann die Dateien nach und nach ausgegeben "FileFindNextFile" bis er keine Datei mehr findet "@error".

Auch Ordner sind für Windows erst einmal Dateien. Unterscheiden tun die sich eigentlich nur durch ein File-Attribut: Directory. Directory ist das, was in Foren häufig einfach Folder genannt wird. AutoIt liest über die Funktion "FileGetAttrib" die Attribute einer Datei ein. Besitzt es dabei das Attribut "D" (=Directory) ist es ein Ordner. Das Beispiel oben hat genau zwei Variablen: Eine für Ordner eine für Dateien, und prüft: Ist das nach Attributen ein Ordner? Wenn ja, zähle bei Ordnern um eins hoch, ansonsten bei Dateien.

Wenn du das nicht willst:

#include <MsgBoxConstants.au3>


Example("C:\Users\laurien\Documents\")


Func Example($sMyFolder)
    Local $hSearch = FileFindFirstFile($sMyFolder & "*.*")


    If $hSearch = -1 Then
        MsgBox($MB_SYSTEMMODAL, "", "Error: No files/directories matched the search pattern.")
        Return False
    EndIf


    Local $sFileName = "", $iDir, $iFile


    While 1
        $sFileName = FileFindNextFile($hSearch)
        If @error Then ExitLoop


		If StringInStr(FileGetAttrib($sMyFolder & $sFileName), "D") Then
			$iDir += 1
		Else
			$iFile += 1
		EndIf


    WEnd
	$AnzahlBeides = $iFile + $iDir
	MsgBox(0,"Anzahl", $iFile & " Dateien und " & $iDir & " Ordner. Also insgesamt " & $AnzahlBeides & " Elemente.")


    FileClose($hSearch)
EndFunc   ;==>Example

Angepasst aus der Hilfe-Datei.

Aus eigener Erfahrung kann ich dir sagen, dass die Fenster schnell einfrieren, wenn sie sehr oft angesteuert werden. Zum Beispiel, wenn du ein Label via ControlSetText in jedem Schleifen-Durchgang setzen lässt. Ich könnte mir vorstellen, dass du hier das selbe Problem hast:

If IniRead(@ScriptDir & "\CODE\TMPDATA\STATES\userdata.cw1", $readlogin1, "ActiveProfile", "") = "---" Then
			WinSetTitle($main_form, "", $Titlename & " | Benutzer: " & $readshowname & " | Schulungsprofil: ---")
		Else
			WinSetTitle($main_form, "", $Titlename & " | Benutzer: " & $readshowname & " | " & _
					"Schulungsprofil: " & $READPROFILE & " (" & IniRead(@ScriptDir & "\DATA\USERS\" & $readlogin1 & "\PROFILES\" & $READPROFILE, "GlobalInfo", "Date", "") & "-" & _
					IniRead(@ScriptDir & "\DATA\USERS\" & $readlogin1 & "\PROFILES\" & $READPROFILE, "GlobalInfo", "DateEnd", "") & ")")
		EndIf

In diesem Teil deiner Schleife versuchst du den Titel des Fensters zu ändern - und das jede Sekunde. Und vollkommen unabhängig davon, ob sich der Titel eigentlich ändern würde oder nicht.

Sorry - gestern größeres Projekt gehabt.

i7-4790 @ x86:
               _Crypt_HashData:    0.069 ms
             crypt-api manuell:    0.034 ms
                          _MD5:    0.020 ms
           advapi inkrementell:    0.014 ms


i7-4790 @ x64:
               _Crypt_HashData:    0.053 ms
             crypt-api manuell:    0.025 ms
                          _MD5:    0.015 ms
           advapi inkrementell:    0.010 ms

Global $sPath, $oWMI, $sDir = "O:\"


_GetFilesRec($sDir)


Func _GetFilesRec($sDir, $fRec = False)
	If Not $fRec Then
		$sPath = $sDir
		$sOwner = _FileOwner($sPath, $oWMI)
		ConsoleWrite($sPath & " = " & $sOwner & @LF)
	EndIf
	$hFileSearch = FileFindFirstFile($sDir & "\*.*")
	While 1
		$sPath = $sDir & FileFindNextFile($hFileSearch)
		If @error Then ExitLoop


		If StringInStr(FileGetAttrib($sPath), "D") Then
			$sOwner = _FileOwner($sPath, $oWMI)
			ConsoleWrite($sPath & " = " & $sOwner & @LF)
			_GetFilesRec($sPath & "\", True)
		EndIf


	WEnd
EndFunc


Func _FileOwner($varName, ByRef $oWMIService)
    Dim $objSD
    If Not IsObj($oWMIService) Then $oWMIService = ObjGet("winmgmts:")
    Local $oFolderSecuritySettings = $oWMIService.Get("Win32_LogicalFileSecuritySetting='" & $varName & "'")
	If Not IsObj($oFolderSecuritySettings) Then Return
    Local $intRetVal = $oFolderSecuritySettings.GetSecurityDescriptor($objSD)
	Dim $arrACEs = $objSD.DACL


    If $intRetVal = 0 Then
		$sReturn = ""
		For $objACE In $arrACEs
			$sReturn &= $objACE.Trustee.Domain & "/" & $objACE.Trustee.Name & "|"
		Next
		Return StringTrimRight($sReturn, 1)
    Else
        Return "Couldn't retrieve security descriptor."
    EndIf
EndFunc   ;==>_FileOwner

Weiß zwar nicht, was dir dein Script (was hier bereits in erweiterter Form ausgeführt wird, indem es noch die Domain mit angibt) bringen soll, da es nicht einen Hauch von "Berechtigungen" widergibt, sondern einfach bloß "ähm... ja, auf dem Ordner existieren Berechtigungen für den Nutzer... oder auch nicht. Keine Ahnung. Jedenfalls gibt es den da. Und es ist für ihn etwas spezifischer." - aber das wirst du wohl wissen.

Zitat von name22

Ich vermute, dass das Problem bei der Sicherheitsfunktion der Browser liegt (z.B. Firefox). Bei einer gesicherten Verbindung zu einem Server werden Inhalte blockiert die über eine nicht gesicherte Verbindung bereitgestellt werden.
Bei Firefox zum Beispiel ändert sich nur das kleine Statussymbol links in der Adressleiste wenn man auf einen der genannten Links klickt. Beim Klick auf das Symbol wird man informiert, dass unsichere Inhalte blockiert wurden.
Das Problem sollte sich relativ einfach lösen lassen, sobald ein Admin darauf aumerksam wird.
Eventuell kannst du ja noch eine PN an GunFood schreiben, falls er davon noch nichts weiß.

Naja, selbst ohne den Schutz, den der normale User kaum wahrnimmt, sind die Links nicht zwangsläufig okay - hier am Beispiel SciTE:

Es liegt die Webseite dahinter, die leider so gar nicht responsive ist und sich demnach nicht auf die Größe des Frames einstellt...

Hallo liebe Admins,

wir haben weiterhin drei scheinbar "tote" Links auf der Startseite, die weder in einem logischen Fehler enden, noch das tun, was sie eigentlich sollten. Alle davon in der Downloadbox:

SciTE: Beim Klick wird die Downloadbox einfach nur optisch leer.
How to Fix: Direkter Downloadlink
Alternative: Den Link den jeder Depp anklicken würde auf das selbe Ziel zeigen lassen wie die Quelle, kurz: Den Link in einem neuen Tab öffnen

Deutsche Hilfe:
How to Fix: Neuer Tab ... dann funktioniert das mit dem Download auch wieder.

OrganizeIncludes:
How to Fix: Neu Hochladen und zur neuen Quelle verlinken
Alternative: Es auf autoitscript.com suchen und wieder dort hin verweisen

Liebe Grüße
Bio

!Testing...
made Notepad Window screenshot
! $result=True
+recognised notepad! moved mouse to center of notepad!
! $result=False
+notepad dissapeared!
!Test finished

Nach der Rückmeldung und dem was du beschreibst klingt es für mich als wäre dies durchaus erfolgreich...

Er testet, macht einen Screenshot vom NotepadFenster, sucht nach diesem Screenshot (ein Bild), findet es, setzt den Mauszeiger in die Mitte des Bildes, findet es dann nicht mehr, weil es minimiert ist, gibt also "False" zurück und stellt fest, dass Notepad "verschwunden" ist.

Gute Arbeit. Ist sowohl auf dem Arbeitsrechner als auch auf dem zu Hause (über 500.000 Durchläufe) deutlich schneller und momentan die Schnellste (die für mich auch verständlich funktioniert) auf beiden Systemen. Nach dem angepassten Benchmark-Script (Anzahl der Läufe erhöht) von AspirinJunkie:

_Crypt_HashData:    0.105 ms
             crypt-api manuell:    0.058 ms
                          _MD5:    0.023 ms
           advapi inkrementell:    0.022 ms

Es ergibt sich demnach - auf diesen Systemen (i5 und i7) kein nennenswerter Unterschied zwischen der Methode _MD5 und advapi inkrementell. Benchmark von zu Hause (über 2.500.000.000 Läufe) reiche ich nach, wenn ich wieder zu Hause am Rechner bin.

Die Frage ist: zu welchem Zweck? Nur um zu belegen, dass das oben bereits beschriebene System tatsächlich schnell genug ist? Man würde nicht einmal die 30 Sekunden damit nachweisen. Nicht einmal 30 Minuten. Du hast eine grundsätzliche Verzögerung hier drin, alleine dadurch, dass der Beitrag von einer Person geschrieben werden muss, der neue Beitrag von der anderen Person wahrgenommen werden muss, anschließend von dieser Person gelesen werden muss, die nötigen Daten dem Programm zufüttern muss, das Ergebnis der Ausgabe möglichst zeitnah feststellen und schließlich auch noch das Ergebnis der posten. Dies kann von wenigen Minuten bis zu mehreren Stunden dauern. Und nichts davon hat auch nur im Ansatz genug Aussagekraft, dass es irgendetwas bringt, als Stunk zu machen. Das ist der springende Punkt - das hüpfende Komma. Es ist einfach nur eine sinnlose Zeitverschwendung, da es nicht das Geringste aussagt. Und dazu sind auch 30 Sekunden schon zu schade, wenn der Hash überhaupt mit zwei Worten der wordlist.txt gebildet werden kann.

AspirinJunkie:

Die bedeutendere Frage ist, ob ich diese Zeit für dich erübrigen würde. Und diese Frage beantworte ich schlicht mit einem nein. Gerne kannst du dich weiter mit der Funktionsweise von CPUs befassen, da es dir hier offensichtlich noch an Grundlagen fehlt - siehe oben. DeFakto hat dein Script gestern - auch in kompilierter Form - nicht auf dem i5 hier am Arbeitsplatz funktioniert - auch nicht an dem i7 5390K der bei mir verbaut ist. Meinst Du, dass ich dich mehr oder weniger respektiere, bloß weil Du in einem Forum, in dem die Ränge nicht demokratisch bestimmt werden, einen Sonderrang hast und Dich mit Dingen wie shared Memory auszukennen scheinst? Da glaubst Du falsch.

Ich behaupte: AutoIt ist dermaßen lahm, dass das von jedem CPU automatisierte "herumswappen" zwischen den Prozessen durch den Prozessor deutlich schneller ist, als die Schleife in AutoIt abzuarbeiten. Und ja: Der Prozessor schafft das. Ja, der Prozess selbst würde dadurch ausgebremst werden, wenn er wieder die Aufmerksamkeit des Threads benötigt, bevor der CPU mit seiner Rotation einmal durch gekommen ist. Das passiert allerdings sehr sehr sehr selten, da wir hier bereits im Nanosekundenbereich sind. Alleine zum durchlaufen eines einzelnen Elements in der For-Schleife - und das ohne dort irgendwas zu berechnen - benötigt AutoIt bereits 0.00000001 Sekunden - 0.00001 ms bzw. 0.01 µs. Oder: 10 ns.

Preisfrage Nummer 1: Was ist ein Thread? Wann wird er genutzt, Wie wird er genutzt?
Preisfrage Nummer 2: Prozential gesehen -> Wie viel Zeit blockiert ein Prozess einen Thread?
Preisfrage Nummer 3: Wie viel Zeit verbringt der Prozessor damit die Rechnung des Prozesses durchzuführen?
Preisfrage Nummer 4: Wie viele Prozesse kann der Prozessor demnach bearbeiten, bevor er anfängt die Prozesse auszubremsen?

Wenn Du diese Fragen recherchiert hast verstehst Du, warum deine Aussagen nicht korrekt sind.