Beiträge von veronesi

  • EDID / DDC Daten direkt vom Monitor lesen

    Nein, hatte ich noch nicht gesehen. Ist sicher auch interessant.
    Aber am interessantesten für mich wäre es, wenn der obenstehende Link in AutoIt übersetzt werden könnte. Dann bräuchte man kein externes Tool....

    Es geht ja nicht um die Kosten. Es geht ums Handling. Und in unserem Fall wäre es eben besser, es wäre alles in AutoIt.
    Wenn sich niemand findet, der Zeit und Lust hat, das C Programm in AutoIt umzusetzen, werde ich wohl das nehmen müssen.
    Ob's funktioniert kann ich nicht sagen, da ich es noch nicht testen konnte.

    Edit: es scheint auch so, als müsse das Programm lokal installiert werden. Das ist leider nicht gewünscht!

  • UDF um Verzeichnisse schnell zu synchronisieren - Schnellere Robocopy Alternative

    Hier ist mal ein Script, um Verzeichnisse zu synchronisieren. Ähnlich wie der Microsoft Befehl Robocopy Quelle Ziel /mir!
    Ihr könnt das Script gerne für Euch verwenden, aber bitte erwähnt meinen Namen im Quellcode, da ich sehr lange damit verbracht habe, die (in AutoIt) schnellste Möglichkeit zum synchronisieren zu finden.

    Vielleicht geht es noch ein kleines Stückchen schneller. Aber in meinen Test's war ich (mindestens bei grossen Verzeichnissen, bzw. vor allem über sehr langsame Netzwerke oder übers Internet) bis zu 4x schneller als Robocopy!

    UDF zum synchronisieren von Verzeichnissen
    [autoit]

    #cs
    ==================================================================================
    Function: _SyncDirectories($sSource, $sDestination, $bDeleteFiles = True)
    Description: Synchronize Source and Destination directory
    Parameter(s):
    $sSource Source-Path
    $sDestination Destination-Path
    $bDeleteFiles If True, then delete files and folders in destination which are not in the source
    Return: Success: 1
    Error: 0

    [/autoit] [autoit][/autoit] [autoit]

    Remark(s): Attention: Files which not exist in Source would be deleted in Destination!!
    Files which are newer in Destination would be overwrited with the "older" in Source!

    [/autoit] [autoit][/autoit] [autoit]

    Same sync as Robocopy.exe Source Destination /MIR
    BUT
    *********************
    Up to 4x faster (When Syncing large directories and syncing over slow network or slow Internet connection!)
    *********************
    Author(s): Veronesi
    Note(s):
    ==================================================================================
    #ce

    [/autoit] [autoit][/autoit] [autoit]

    #include-once

    [/autoit] [autoit][/autoit] [autoit]

    Func _SyncDirectories($sSource, $sDestination, $bDeleteFiles = True)
    ;This function searches recursively through all directories, but it don't use any recursion. It's iterativ!
    ;Iterativ is mostly faster then recursive. (Definitely on large directories!)
    ;AutoIt also has some limitations on recursive calls. (Max. 5100 levels; Probably we have sometimes more folder to sync....!)

    [/autoit] [autoit][/autoit] [autoit]

    ;Working with Scripting.Dictionary is much faster then _ArrayAdd
    ;And it's also MUCH faster then _ArraySearch for comparing directories
    ;It's also a bit faster then (_ArrayBinarySearch with _ArraySort) => _ArrayBinarySearch needs the _ArraySort!

    [/autoit] [autoit][/autoit] [autoit]

    Local Const $BinaryMode = 0 ;ASCII Mode => Uppercase and Lowercase are different! BinaryMode seams to be faster!
    Local Const $TextMode = 1 ;Uppercase and Lowercase are the same!
    Local Const $Database = 2 ;Only for Microsoft Access

    [/autoit] [autoit][/autoit] [autoit]

    Local $SyncSuccess = True, $SyncRet = 1, $TrimSourceForRelativePath, $TrimDestinationForRelativePath
    Local $oSourceFiles, $oSourceFolders, $oDestinationFiles, $oDestinationFolders, $oLocalFolders
    Local $Key, $Item, $aDFolders, $aSFolders, $iSF, $iDF, $bFound = False, $bOK = True
    Local $NumberOfFolders = 0, $iFolder = 0
    Local $hSearch, $sFile, $SearchPath

    [/autoit] [autoit][/autoit] [autoit]

    $oSourceFiles = ObjCreate('Scripting.Dictionary') ; Default = Binarymode
    $oSourceFolders = ObjCreate('Scripting.Dictionary') ; Default = Binarymode
    $oDestinationFiles = ObjCreate('Scripting.Dictionary') ; Default = Binarymode
    $oDestinationFolders = ObjCreate('Scripting.Dictionary') ; Default = Binarymode
    $oLocalFolders = ObjCreate('Scripting.Dictionary') ; Default = Binarymode
    If Not IsObj($oSourceFiles) Or Not IsObj($oSourceFolders) Or Not IsObj($oDestinationFiles) Or Not IsObj($oDestinationFolders) Or Not IsObj($oLocalFolders) Then Return SetError(1, 1, 0)

    [/autoit] [autoit][/autoit] [autoit]

    If StringRight($sSource, 1) = "\" Then $sSource = StringTrimRight($sSource, 1) ;Remove "\" at the end of the path (if found!)
    If StringRight($sDestination, 1) = "\" Then $sDestination = StringTrimRight($sDestination, 1) ;Remove "\" at the end of the path (if found!)

    [/autoit] [autoit][/autoit] [autoit]

    $TrimSourceForRelativePath = StringLen($sSource) + 1 ;Add 1 because the last Backslash is stripped!
    $TrimDestinationForRelativePath = StringLen($sDestination) + 1 ;Add 1 because the last Backslash is stripped!

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    $oLocalFolders.Add($NumberOfFolders, $sSource) ;Add initial folder

    [/autoit] [autoit][/autoit] [autoit]

    While 1
    If $oLocalFolders.Count = $iFolder Then ExitLoop
    $SearchPath = $oLocalFolders.Item($iFolder) ;Take next search path from the Dictionary object. Because we can't use the dictionary object with an Index, we use the Key as Index!
    $iFolder += 1

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    $hSearch = FileFindFirstFile($SearchPath & "\*") ;Create Search handle in Path and search for all files / folders!
    If Not @error Then ;@error is set when folder is empty! Then it's no error!
    While 1
    $sFile = FileFindNextFile($hSearch) ;Search for next file
    If @error Then ExitLoop ;No further files found => Exit Loop
    If @extended Then ;Folder found!
    $NumberOfFolders += 1
    $oLocalFolders.Add($NumberOfFolders, $SearchPath & "\" & $sFile) ;Add folder for local use. Folder with full path!/ Use a ongoing number as key! Because the dictionary object can't be used with an index!
    $oSourceFolders.Add(StringTrimLeft($SearchPath & "\" & $sFile, $TrimSourceForRelativePath), 1) ;Add folder for global use. Take only the relative path!
    Else
    $oSourceFiles.Add(StringTrimLeft($SearchPath & "\" & $sFile, $TrimSourceForRelativePath), FileGetTime($SearchPath & "\" & $sFile, 0, 1)) ;Add file, but only relative path
    EndIf
    WEnd
    EndIf
    FileClose($hSearch) ;Close search handle

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    If $SearchPath = $sSource Then
    $SearchPath = $sDestination
    Else
    $SearchPath = $sDestination & "\" & StringTrimLeft($SearchPath, $TrimSourceForRelativePath)
    EndIf
    $hSearch = FileFindFirstFile($SearchPath & "\*") ;Create Search handle in Path and search for all files / folders!
    If Not @error Then ;@error is set when folder is empty! Then it's no error!
    While 1
    $sFile = FileFindNextFile($hSearch) ;Search for next file
    If @error Then ExitLoop ;No further files found => Exit Loop
    If @extended Then ;Folder found!
    $oDestinationFolders.Add(StringTrimLeft($SearchPath & "\" & $sFile, $TrimDestinationForRelativePath), 1) ;Add folder for global use. Take only the relative path!
    Else
    $oDestinationFiles.Add(StringTrimLeft($SearchPath & "\" & $sFile, $TrimDestinationForRelativePath), FileGetTime($SearchPath & "\" & $sFile, 0, 1)) ;Add file, but only relative path
    EndIf
    WEnd
    EndIf
    FileClose($hSearch) ;Close search handle

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    ;Sync and Copy
    For $Key In $oSourceFiles ;For each file in source files...
    If Not $oDestinationFiles.Exists($Key) Then ;Don't exist => Copy it
    $SyncRet = FileCopy($sSource & "\" & $Key, $sDestination & "\" & $Key, 9)
    If $SyncRet = 0 Then $SyncSuccess = False
    Else ;Exist => Check Date
    If $oSourceFiles.Item($Key) <> $oDestinationFiles.Item($Key) Then
    $SyncRet = FileCopy($sSource & "\" & $Key, $sDestination & "\" & $Key, 9)
    If $SyncRet = 0 Then $SyncSuccess = False
    EndIf
    EndIf
    Next

    [/autoit] [autoit][/autoit] [autoit]

    ;Check for folders to be created
    For $Key In $oSourceFolders ;For each folder in source folders...
    If Not $oDestinationFolders.Exists($Key) Then DirCreate($sDestination & "\" & $Key) ;Create folder if it don't exist. (Only empty folders. Not empty folder would already be created by Filecopy!!)
    Next

    [/autoit] [autoit][/autoit] [autoit]

    ;Check for files and folders to be deleted!
    If $bDeleteFiles Then
    For $Key In $oDestinationFiles ;For each file in destination files...
    If Not $oSourceFiles.Exists($Key) Then $SyncRet = FileDelete($sDestination & "\" & $Key) ;Delete file if not found in source
    If $SyncRet = 0 Then $SyncSuccess = False
    Next

    [/autoit] [autoit][/autoit] [autoit]

    For $Key In $oDestinationFolders ;For each folder in destination folders...
    If Not $oSourceFolders.Exists($Key) Then $SyncRet = DirRemove($sDestination & "\" & $Key, 1) ;Delete folder if not found in source
    If $SyncRet = 0 Then $SyncSuccess = False
    Next
    EndIf

    [/autoit] [autoit][/autoit] [autoit]

    $oSourceFiles.RemoveAll
    $oSourceFolders.RemoveAll
    $oDestinationFiles.RemoveAll
    $oDestinationFolders.RemoveAll
    WEnd
    $oLocalFolders = 0 ;Destroy object
    $oSourceFiles = 0 ;Destroy objects
    $oSourceFolders = 0
    $oDestinationFiles = 0
    $oDestinationFolders = 0

    [/autoit] [autoit][/autoit] [autoit]

    If $SyncSuccess Then Return 1 ;DirGetSize($sSource) / 1024 / 1024
    Return 0
    EndFunc ;==>_SyncDirectories

    [/autoit]

    Gruss Veronesi

  • EDID / DDC Daten direkt vom Monitor lesen

    Ja, von den Jungs ist ja auch das Tool softMCCS, welches wir haben. Habe letzte Woche die neueste Version getestet. Bei einem Monitor hat es versagt, bei dem Anderen hatte es 3(!!!!!!!) Minuten, bis es die EDID Daten gelesen hatte. Zwar korrekt, aber lange.
    Zudem lässt es sich nicht wirklich automatisieren.

    Den Link, den ich vorher gepostet habe könnte wirklich eine Lösung sein. Soweit ich gesehen habe, sind alle Funktionen (auch I2C Schreiben / Lesen / Clock ...) im MSDN beschrieben.
    Nur bräuchte ich jemanden, der mir das von C in AutoIt übersetzt.
    Progandy hat zu viel Arbeit... Aber vielleicht findet sich jemand, der in C fitt ist und etwas Zeit hat?

  • EDID / DDC Daten direkt vom Monitor lesen

    Ich möchte das gerne wieder hervorholen!
    Um die EDID Daten zu lesen habe ich hier ein Script gefunden. Jedenfalls glaube ich, dass es die EDID Daten liesst, denn es ist in C geschrieben, was ich absolut nicht verstehe.

    Gibt es hier jemanden, der das in AutoIt umsetzen kann? *ZuProgandySchiel*
    Das wäre wirklich sehr nett!

    Vielen Dank an Alle, die sich hier beteiligen!
    Veronesi

  • FileFindFirstFile - schnellere Alternative?

    Ja, die Übertragung wird wohl so ca. 5 Stunden dauern. Die Internetleitung hat vermutlich nur kleine Schwankungen, da es eine Businessleitung ist und somit garantiert Bandbreiten. Aber wenn zwischendurch ein Server "nicht so mag..."
    Ich weiss einfach, dass der gesamte Prozess (Überprüfen, was geändert werden muss und kopieren) ca. 7h 15 Minuten dauert.

    Das kann in etwa sein, da für das Scripting.Dictionary der Quelle (4.1TB Daten) etwas mehr als 1h benötigt wird.
    Für das Scripting.Dictionary des Ziels wird auch etwas mehr als 1h benötigt.
    Und dann ca. 5h kopieren! (= 7h Total)

    Da Quelle und Ziel auf unterschiedlichen Datenträgern (und Servern) liegen, könnte man Quelle und Ziel gleichzeitig einlesen. Aber ich kann die Daten nicht in ein Array einlesen, da AutoIt maximal 16Millionen Einträge pro Array erlaubt. Und die könnten vielleicht schon bald erreicht sein.
    Auch ist das Durchsuchen der Arrays (auch mit ArrayBinarySearch) langsamer als das durchsuchen von Scripting.Dictionary!

    Aber dazu habe ich zwei Threads offen:
    Performance mit Scripting.Dictionary und
    Objekte übergeben

    Damit ich den Performanceverlust des Scripting.Dictionary nicht habe, lese ich jeweils nur eine Verzeichnisebene der Quelle und des Ziels ein. Danach wird diese Ebene synchronisiert.
    Danach werden die Objektinhalte (Scripting.Dictionary) gelöscht und es geht in die nächste Ebene.

    Gruss Veronesi

  • FileFindFirstFile - schnellere Alternative?

    Ich hab's wohl falsch geschrieben!
    Es sind ca 148GB Daten die täglich ändern. (Viele Mitarbeiter...)
    Das gesamte Datenvolumen beträgt rund 4.1TB. Und diese 4.1TB müssen durchsucht werden. (ca 12'000'000 Dateien in ca 100'000 Ordnern)

    Dies ist ein kleineres Entwicklungslaufwerk mit einer Menge Delphi Source Code und Microcontroller Source Code und Exe Dateien von etwa 45 Softwareentwicklern.

    Mit meinem Script läuft das bis jetzt einwandfrei. Wollte es halt etwas verbessern.

  • FileFindFirstFile - schnellere Alternative?

    Ja, mir ist klar, dass AutoIt langsamer als C++ ist!
    Und dass irgendwo eine technische Grenze ist (HDD) ist auch klar!
    Ich wollte einfach das Maximum bei der Synchronisierung herausholen.

    Deshalb habe ich mir auch mal kurz C++ angeschaut. Aber das scheint mir komplizierter zu sein......
    Und als ich eben den Link gesehen habe, und gelesen habe, dass er von 30 Sekunden auf 2-3 Sekunden heruntergekommen ist, tönte das für mich interessant! Nicht mehr und nicht weniger.


    RSync kenne ich nicht. Lässt sich das ähnlich wie Robocopy in AutoIt einbinden, oder muss dann jeder eine Software installieren? (Das wäre dann ungünstig)

    Ehrlicherweise lässt sich wohl mit AutoIt nicht mehr viel rausholen.
    Wieviel schneller ist wohl FileFindFirstFile in C++?
    Oder ist AutoIt da schon (fast) so schnell wie es die HDD überhaupt zulässt?

  • FileFindFirstFile - schnellere Alternative?

    Ich will nichts ausspionieren!!!
    Ich muss lediglich Daten zwischen verschiedenen Laufwerken synchronisieren. (Sind übrigens alles SSD!!!)

    Und Robocopy ist zu langsam.
    Meine Lösung basiert auf FileFindFirstFile, aber speichert nicht in einem Array, da das Durchsuchen des Arrays auf Unterschiede zu lange dauert. (Entweder mit _ArraySearch oder _ArraySort und dann _ArayBinarySearch => Beide zu langsam)

    Ich nutze dazu Scripting.Dictionary. Das ist beim Durchsuchen massiv schneller!

    Damit wir uns richtig verstehen: Meine Lösung funktioniert gut. Und ist auf langsamen Netzwerken (übers Internet) etwa 4x schneller als Robocopy. Einfach in einem Gigabit Netzwerk ist es nur wenig schneller (wenn überhaupt) als Robocopy!
    Deshalb wollte ich für FileFindFirstFile evtl. eine schnellere Alternative wie im beschriebenen Link!

  • FileFindFirstFile - schnellere Alternative?

    Hallio zusammen,

    Ich brauche fleißig den FileFindFirstFile (und -NextFile) Befehl.
    Er ist in AutoIt auch RELATIV schnell. (Ich benutze ihn Iterativ nicht Rekursiv, weil er dann bei mir ein wenig schneller ist.) Aber um noch ein bisschen Geschwindigkeit vor allem in Netzwerken herauszuholen, wollte ich nach Alternativen suchen. Die sollen quasi nur einen Befehl übers Netztwerk absenden und dann bekomme ich gleich nicht nur die nächste Datei, sondern die ganze Dateiliste von diesem Verzeichnis. Natürlich ohne Unterordner, aber vielleicht gleich mit dem jeweiligen Änderungsdatum der Dateien!!

    Dazu habe ich hier einen Ansatzpunkt einer Lösung gefunden. Aber kann man das in AutoIt überhaupt umsetzen??

    Veronesi

  • Performance mit Scripting.Dictionary oder ähnlichem

    Eine SQLite Datenbank wird wohl nicht die Lösung sein. Soweit bin ich nun schon mal!
    Mit diesem Script habe ich getestet. Und die Datenbank ist bei allen Werten für $i (von 1 bis 1'000'000) massiv langsamer.
    Gut, SQLite wurde nicht unbedingt wegen der Geschwindigkeit geschaffen... Eine Datenbank bietet andere Vorteile, die ich hier aber nicht benötige!

    Spoiler anzeigen
    [autoit]

    #include <SQLite.au3>
    #include <SQLite.dll.au3>

    [/autoit] [autoit][/autoit] [autoit]

    $Timer = TimerInit()
    _SQLite_Startup()
    $hDB = _SQLite_Open()
    _SQLite_Exec($hDB, "PRAGMA journal_mode = OFF;") ;No Journal = faster
    _SQLite_Exec($hDB, "PRAGMA synchronous = 0;") ;Don't wait for filesystem = faster
    _SQLite_Exec($hDB, "CREATE TABLE Source (Key, Item);") ; Create Table
    _SQLite_Exec($hDB, "BEGIN;") ;Begin of transactions => Faster!
    For $i = 0 to 100000
    _SQLite_Exec($hDB,"INSERT INTO Source VALUES ('" & $i & "', '" & $i & "');")
    Next
    _SQLite_Exec($hDB, "End;") ;End of transactions => Faster!
    _SQLite_Close($hDB)
    _SQLite_Shutdown()

    [/autoit] [autoit][/autoit] [autoit]

    $End = TimerDiff($Timer)
    MsgBox(0,"",Round($End, 2) & "ms")

    [/autoit] [autoit][/autoit] [autoit]

    $oDictionary = ObjCreate("Scripting.Dictionary")
    If @error Or Not IsObj($oDictionary) Then Exit MsgBox(0,"Fehler", "Objekt konnte nicht erstellt werden")

    [/autoit] [autoit][/autoit] [autoit]

    $Timer = TimerInit()
    For $i = 0 To 100000
    $oDictionary.Add($i, "Teststring")
    Next
    $End = TimerDiff($Timer)
    MsgBox(0,"Dauer", Round($End, 2) & "ms")

    [/autoit]

    Also sind weiterhin Ideen gesucht, um eine eine Liste mit Daten temporär zu speichern. Es muss nichts auf der HDD abgespeichert werden. Nur in Variablen, Arrays, Objekten "zwischengelagert"!
    Die Liste ist wie gesagt, zweidimensional. Also Immer Schlüssel und Daten!

    Gruss Veronesi

  • Performance mit Scripting.Dictionary oder ähnlichem

    Hallo zusammen,

    ich muss auf verschiedenen PCs Dateien Indexieren und gewisse Dinge damit erledigen.
    Manchmal brauche ich nur einige dutzend Dateien, manchmal aber mehrere 100'000!

    Eigentlich wäre für mich das Scripting.Dictionary optimal geeignet, da ich schnell Schlüssel mit jeweils einem Wert hinzufügen muss und im Anschluss prüfen muss, ob ein bestimmter Schlüssel existiert!
    Ich muss also nicht nur schnell hinzufügen können, sondern auch schnell auf Existenz eines Schlüssels prüfen!

    Soweit so gut.
    Ich verwende mal folgenden Code auf meinem (momentan) langsamen Rechner:

    [autoit]

    $oDictionary = ObjCreate("Scripting.Dictionary")
    If @error Or Not IsObj($oDictionary) Then Exit MsgBox(0,"Fehler", "Objekt konnte nicht erstellt werden")

    [/autoit][autoit][/autoit][autoit]

    $Timer = TimerInit()
    For $i = 0 To 100000
    $oDictionary.Add($i, "Teststring")
    Next
    $End = TimerDiff($Timer)
    MsgBox(0,"Dauer", Round($End, 2) & "ms")

    [/autoit]

    Damit dauert das hinzufügen (auf meinem Rechner) von 100'000 Datensätzen ca. 600ms
    Wenn ich nun aber 1 Million Datensätze hinzufüge, dauert das nicht 10x so lange, also ca. 6 Sekunden, sondern fast 100x so lange (50-60 Sekunden!)

    Das ist natürlich für mich nicht geeignet.
    Aber was wäre schneller?
    Ich habe es schon mit ArrayList, Hashtable, Queue und Stack versucht. (MSDN Link)
    Leider sind diese alle bei bis zu 600'000 Datensätzen langsamer als das Scripting.Dictionary. Dafür sind sie darüber massiv schneller!

    Was für eine Methode könnte ich verwenden, um bei 1 - 20 Millionen Objekten "am schnellsten" zu sein? (Natürlich immer noch in AutoIt). Wäre eine SQLite Datenbank schneller? (Habe noch nie etwas mit Datenbanken gemacht!)

    Ich sage bewusst bis 20 Millionen Einträge, weil ich die AutoIt internen Arrays nicht benutzen möchte. (Obwohl diese - direkt adressiert - am schnellsten sind.)
    In einigen Fällen habe ich eben wirklich mehr als 16 Millionen Objekte!

    Vielen Dank für Eure Hilfe!
    Veronesi

  • EDID / DDC Daten direkt vom Monitor lesen

    Hallo Dietmar,

    leider kann / soll / darf ich das nicht.

    Erklärung was ich eigentlich machen muss.


    Für eine Bank in den USA müssen wir ca. 8'000 neue Monitore testen.
    Sie haben u.a. die Anforderung, dass die Monitore keine Pixelfehler haben und dass die DDC Daten korrekt gesendet werden.

    Der Grund liegt darin, dass sie Ihre PCs nicht am Arbeitsplatz haben, sondern in einem 4,5km entfernten gesicherten Gehäude.
    Von dort gehen mehrere 10GBit Glasfaserleitungen zu den Monitoren. Mit anderen Worten:
    Wir remotisieren diese Computer mit allen Signalen (DVI / USB / Audio / seriell / ...)

    Dazu ist jeweils ein Sender beim PC und ein Empfänger bei Monitor / Tastatur / Maus / Telefon / Kartenleser notwendig.
    Damit der PC den Monitor korrekt darstellt müssen die DDC Daten über unsere abgesetzte Strecke übertragen werden.

    Wir haben nun einen kleinen Roboter konstruiert, welcher automatisch ein Bildschirm nach dem anderen an einen Prüfcomputer anschliesst und
    mehrere Testbilder auf dem Monitor darstellt. Dann kommt ein zweiter Roboter, welcher mit mehreren hochauflösenden Kameras den ganzen Bildschirm abfahren und ihn auf Pixelfehler prüfen.

    Ich muss nun mit AutoIt den Roboter ansteuern und die DDC Daten lesen. Unter Windows. Das ist Vorgabe.
    Den Roboter anzusteuern ist ganz leicht, denn ich muss bloss über die serielle Schnittstelle ein Startkommando senden, dann wird der nächste Bildschirm angeschlossen.
    Dann noch ein serieller Befehl und der 2. Roboter sucht nach Pixelfehler. Im Anschluss bekomme ich ein serieller String zurück, welcher sagt, ob Pixelfehler gefunden wurden, oder nicht.
    Dann muss ich noch die DDC Daten lesen, damit wir sicher sind, dass die EEPROMS in den Monitoren vom Hersteller korrekt geflasht wurden,
    damit sie später auch ohne Probleme an unseren Remotestrecken funktionieren.


    Gruss Veronesi

  • EDID / DDC Daten direkt vom Monitor lesen

    Mithilfe diesesBeitrages und der MSDNDokumentation habe ich folgendes Script geschrieben:

    Win32_DesktopMonitor
    [autoit]

    Local $strComputer = "localhost"
    Local $objWMIService = ObjGet("winmgmts:\\" & $strComputer & "/root\cimv2")
    Local $objInstances = $objWMIService.InstancesOf("Win32_DesktopMonitor", 48)
    Local $Output = ""

    [/autoit] [autoit][/autoit] [autoit]

    For $objInstance In $objInstances
    With $objInstance
    $Output &= "Availability: " & @TAB & @TAB & .Availability & @LF
    $Output &= "Bandwidth: " & @TAB & @TAB & .Bandwidth & @LF
    $Output &= "Caption: " & @TAB & @TAB & @TAB & .Caption & @LF
    $Output &= "ConfigManagerErrorCode: " & @TAB & .ConfigManagerErrorCode & @LF
    $Output &= "ConfigManagerUserConfig: " & @TAB & .ConfigManagerUserConfig & @LF
    $Output &= "CreationClassName: " & @TAB & @TAB & .CreationClassName & @LF
    $Output &= "Description: " & @TAB & @TAB & .Description & @LF
    $Output &= "DeviceID: " & @TAB & @TAB & @TAB & .DeviceID & @LF
    $Output &= "DisplayType: " & @TAB & @TAB & @TAB & .DisplayType & @LF
    $Output &= "ErrorCleared: " & @TAB & @TAB & @TAB & .ErrorCleared & @LF
    $Output &= "ErrorDescription: " & @TAB & @TAB & .ErrorDescription & @LF
    $Output &= "InstallDate: " & @TAB & @TAB & @TAB & .InstallDate & @LF
    $Output &= "IsLocked: " & @TAB & @TAB & @TAB & .IsLocked & @LF
    $Output &= "LastErrorCode: " & @TAB & @TAB & .LastErrorCode & @LF
    $Output &= "MonitorManufacturer: " & @TAB & .MonitorManufacturer & @LF
    $Output &= "MonitorType: " & @TAB & @TAB & .MonitorType & @LF
    $Output &= "Name: " & @TAB & @TAB & @TAB & .Name & @LF
    $Output &= "PixelsPerXLogicalInch: " & @TAB & .PixelsPerXLogicalInch & @LF
    $Output &= "PixelsPerYLogicalInch: " & @TAB & .PixelsPerYLogicalInch & @LF
    $Output &= "PNPDeviceID: " & @TAB & @TAB & .PNPDeviceID & @LF
    $Output &= "PowerManagementCapabilities: " & @TAB & .PowerManagementCapabilities & @LF
    $Output &= "PowerManagementSupported: " & @TAB & .PowerManagementSupported & @LF
    $Output &= "ScreenHeight: " & @TAB & @TAB & .ScreenHeight & @LF
    $Output &= "ScreenWidth: " & @TAB & @TAB & .ScreenWidth & @LF
    $Output &= "Status: " & @TAB & @TAB & @TAB & .Status & @LF
    $Output &= "StatusInfo: " & @TAB & @TAB & @TAB & @TAB & .StatusInfo & @LF
    $Output &= "SystemCreationClassName: " & @TAB & .SystemCreationClassName & @LF
    $Output &= "SystemName: " & @TAB & @TAB & .SystemName
    EndWith
    MsgBox(0, "Info", $Output)
    $Output = ""
    Next

    [/autoit] [autoit][/autoit] [autoit][/autoit] [autoit]

    $objInstances = 0
    $objWMIService = 0

    [/autoit]

    Leider jedoch auch ohne Erfolg. Der Monitorname oder auch die anderen Felder sind leer oder unbrauchbar, da zu allgemein (PnP-Standardmonitor)
    Irgendwie muss doch auch Windows mit den Bildschirmen kommunizieren. Oder erledigen das bloss die Treiber?

    Wie sieht es dann mit dem "Standard" Windows Monitor-Treiber aus? Könnte man den irgendwie ansteuern, bzw. anfragen?
    Ich bräuchte eigentlich bloss den Herstellernamen. (Am besten natürlich die rohen EDID Daten, aber mindestens den Monitornamen)

    Fällt noch jemandem etwas ein?

  • Objekte übergeben

    Also was ich noch versucht habe, ist das Objekt per Parameter bei ShellExecute zu übergeben.
    Klappt leider nicht. (War ja eigentlich zu erwarten)

    Hat jemand eine Idee wie man Objekte (oder vielleicht später auch mal Fenster handles) übergeben könnte?

  • EDID / DDC Daten direkt vom Monitor lesen

    Hallo Oscar,

    vielen Dank. Das liest eben "nur" die gespeicherten EDID Daten von der Registry ab. Und bei meinen sechs Monitoren am Arbeitsplatz liefert es für keinen die EDID Daten.
    Für zwei liefert es die Seriennummer, für drei den Namen (meistens aber nicht korrekt)

    Mit dem softMCCS (käufliches Tool, welches wir haben) bekomme ich da schon viel mehr Daten. Leider läuft dies wie gesagt unter Win7 nicht immer. Und nicht immer zuverlässig.
    Und leider muss ich das ganze automatisieren.

    Trotzdem danke für Deinen Beitrag!!!
    Veronesi

  • EDID / DDC Daten direkt vom Monitor lesen

    Hier habe ich auch noch einen Link gefunden.
    Anscheinend will diese Person ebenfalls die EDID Daten direkt vom Monitor lesen und hat ein Programm dazu geschrieben (C++)
    Allerdings scheint er Probleme beim kompillieren zu haben.

    Wie dem auch sei: Vielleicht kann man aus dem Code Ideen nehmen um meine Frage umzusetzen?
    Kann jemand mit C++ Kentnissen diesenLink mal anschauen?