Ja, es ist "nur" ein Darstellungsproblem.
Ich "brauche" das Listview, weil ich zeilenweise Daten für die Darstellung einfärben muss.
Klar, ginge das auch mit einem RichEdit, aber ich muss auch noch verschiedene Icons in der ersten Spalte darstellen.
Alles in allem ist das Listview deshalb einfacher.
Aber richtig, es ist "nur" ein optisches Problem. Der Kunde möchte das aber irgendwie weg haben....
Ich suche mal noch etwas.
Danke trotzdem!
Hallo!
Leider hat auch diese Variante diesen Fehler unter XP.
Das mit Ersetzen ist etwas schwierig. Da ich in der Lage sein sollte, alle nur denkbaren (auch nicht druckbare) Zeichen zu speichern.
Gespeichert wird sowieso im Binary Modus.
Aber mit welchem Zeichen kann ich das ersetzen, damit ich mir meinen "Zeichnsatz" nicht einschränke?
Wie ich umständlich zu erklären versuchte:
Ich benötige das @CRLF für eine spätere Weiterverarbeitung.
Ich schreibe die Daten später noch in ein File.
Deshalb benötige ich dort noch das Return.
Und ab Vista++ funktioniert es auch ja........
Hallo Zusammen
Mein Testscript ist hier:
[autoit]GUICreate("listview items", 400, 250, 100, 200)
$listview = GUICtrlCreateListView("A ", 10, 10, 400, 150)
GUICtrlCreateListViewItem("A" & @CRLF & "B", $listview)
GUISetState()
Do
$msg = GUIGetMsg()
Until $msg = -3
Exit
Führe ich das unter Windows 7 oder Windows 8 aus, sieht es einwandfrei aus.
Unter Windows XP hingegen erhalte ich für das @CRLF Quadrate!
Die Quadrate stören mich und sollen weg, aber wie?
Das @CRLF löst diese aus. Aber ich benötige dieses @CRLF, damit ich im eigentlichen Programm erkenne, ob die letzte Zeile zu Ende war, oder nicht!
Wenn sie zu Ende war, dann erstelle ich ein neues ListViewItem.
Also, langer Rede, kurzer Sinn: Ich benötige das @CRLF im ListView String. Aber unter XP habe ich dann Darstellungsfehler. Wie lassen sich diese vermeiden?
Gruss Veronesi
Du kannst auch mal das Login-Flag 0 ausprobieren. - Ohne Profil laden.
Aus eigener Erfahrung (in einer Domäne) lassen sich die Profile mit RunAs nicht immer laden.....
Sorry, für die späte Rückmeldung.
Ich bekomme leider vom Forum keine Mails mehr bei neuen Nachrichten!
Ja, die
[autoit]GUISetAccelerators
[/autoit]einfach in der Hilfe nachlesen!
"Setzt eine Tabelle mit Zugriffstasten in einem GUI Fenster"
Gruss Veronesi
Ich habe bisher 20 meiner Scripts auf Windows 8 getestet - und alle liefen einwandfrei.
Gut, natürlich mit der Einschränkung, dass wenn man einen Link im "Startmenü" erstellt, dass es dann eine Kachel auf der Modern-UI gibt!
Sonst laufen zumindest meine 20 Scripts gut.
(Musste bereits 140 PCs mit Windows 8 bestücken und ausliefern)
Gruss, Veronesi
Auch von mir alles Gute zum heutigen Geburtstag!
Es gibt natürlich auch noch eine andere Lösung.
Du kannst eine Art "Hotkey" nur für Deine GUI erstellen!
Hier mein Beispiel:
#include <GUIConstants.au3>
Opt('GUIOnEventMode', 1)
Global $hGUI = GUICreate('Example', 200, 80)
GUICtrlCreateLabel('Input', 10, 13, 50, 20)
Global $hInput = GUICtrlCreateInput('', 60, 10, 100, 20)
Global $hEnter = GUICtrlCreateDummy()
GUICtrlSetOnEvent(-1, "_Enter")
GUISetOnEvent($GUI_EVENT_CLOSE, '_Exit', $hGUI)
Local $aAccelKeys[1][2] = [["{Enter}", $hEnter]]
GUISetAccelerators($aAccelKeys)
GUISetState(@SW_SHOW, $hGUI)
While True
Sleep(1000)
WEnd
Func _Exit()
Exit
EndFunc ;==>_Exit
Func _Enter()
ConsoleWrite("Enter pressed while GUI active" & @CRLF)
MsgBox(64, "Enter", "Enter pressed while GUI active")
EndFunc ;==>_Enter
Gruss Veronesi
Hat niemand eine Idee, wie man ein MediaPlayer Objekt zur Laufzeit in der Grösse ändern kann?
Du schreibst, dass das Programm in WPF (Windows Presentation Foundation) programmiert ist.
Wir haben auch so ein Programm im Geschäft.
Nach meiner Erfahrung lässt sich dies "nicht" automatisieren.
Klar, kann man die Fenstergrösse abfragen und dann relativ zum Fenster die Maus bewegen und klicken.
Aber richtig toll wird das leider nicht.
Sorry, aber das ist meine Erfahrung!
Veronesi
Ich habe ein kurzes Testprogramm zusammengestiefelt, damit man mein Problem sehen kann.
Wenn bei Euch die angegebene AVI Datei im Windows nicht vorhanden ist, dann einfach durch ein beliebiges kleines Video ersetzen, welches vom Mediaplayer abgespielt werden kann!
Es geht darum, dass man nach dem starten des Programmes das Fenster in der Grösse ändern soll. Darauf wird ein Event erzeugt (klappt)!
In diesem Event soll nun das Video in der Grösse als Vollbild angepasst werden.
Wie kann ich das erreichen?
Macht Euch um allfällige Verzerrungen etc. keine Sorgen. Im endgültigen Programm kann man das Fenster nur immer im gleichen Verhältnis vergrössern oder verkleinern! Somit wird das Video bestimmt nie verzerrt!
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
Opt("GUIOnEventMode", 1)
$hGUI1 = GUICreate("WDP", 300, 250, -1, -1, $WS_SIZEBOX)
GUISetState(@SW_SHOW)
GUISetOnEvent($GUI_EVENT_RESIZED, "_Resize")
GUISetOnEvent($GUI_EVENT_CLOSE, "_Exit")
$oWMP1 = ObjCreate("WMPlayer.OCX")
If Not IsObj($oWMP1) Then Exit
$hWMP1 = GUICtrlCreateObj($oWMP1, 0, 0, 300, 250)
With $oWMP1
.URL = "C:\Windows\winsxs\x86_microsoft-windows-t..flicklearningwizard_31bf3856ad364e35_6.1.7600.16385_none_0d580453d317a99d\FlickAnimation.avi"
Local $iEmergencyTimerWMP = TimerInit()
While StringInStr(.status(), '...') ;Wait while status = Connecting...
If TimerDiff($iEmergencyTimerWMP) > 2000 Then ExitLoop
Sleep(100)
WEnd
.settings.autoStart = False
.controls.stop() ;Stop, to ensure, that they are at the beginning!
.fullscreen = True
.stretchToFit = True
.settings.setMode('loop', True)
.settings.playCount = 1000000
.settings.rate = 1
.uiMode = 'none'
.settings.volume = 100
.settings.mute = True
.enableContextMenu = True
EndWith
$oWMP1.controls.play()
[/autoit] [autoit][/autoit] [autoit]While Sleep(10)
WEnd
Exit
Func _Resize()
Local $aSize = WinGetPos($hGUI1)
ConsoleWrite("Resize: " & GUICtrlSetPos($hWMP1, 0, 0, $aSize[2], $aSize[3]) & @CRLF)
EndFunc ;==>_Resize
Func _Exit()
Exit
EndFunc ;==>_Exit
Wie kann ich die _Resize Funktion so ändern, dass das Video immer das ganze Fenster ausfüllt?
Gruss, Veronesi
Ich konnte zwar auf die Schnelle die SQLite Methode noch massiv verschnellern, doch diese Methode hat dann wiederum drei Nachteile:
1. Sie ist bei weniger als 600'000 Elementen langsamer als das Dictionary. Darüber ist sie z.T. massiv schneller
2. Da alle Transaktionen in einem String gespeichert werden, ist natürlich die maximale Stringlänge in AutoIt massgebend! Man könnte natürlich nach XYZ Elementen wieder aufteilen, doch das braucht auch Zeit.
3. Weil der String riesig werden kann, ist natürlich der RAM-Verbrauch entsprechend hoch.
Hier der Testcode:
Achtung, wenn man den laufen lässt, dauert es auf einem "normalen" Rechner schon 1-2 Minuten!
#include <SQLite.au3>
Global $sSQLDLL = @TempDir & "\SQLite3.dll"
FileInstall("SQLite3.dll", $sSQLDLL, 1)
Global Const $iMax = 1e6
Global $iTimer, $iEnd, $hDB, $aDatabase[$iMax][2], $sString = ""
_SQLite_Startup($sSQLDLL, False, 1)
$iTimer = TimerInit()
$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 $iMax - 1
_SQLite_Exec($hDB, "INSERT INTO Source VALUES ('" & $i & "', 'Teststring');")
Next
_SQLite_Exec($hDB, "End;") ;End of transactions => Faster!
_SQLite_Close($hDB)
$iEnd = TimerDiff($iTimer)
ConsoleWrite(StringFormat("SQLite: \t%7.1f ms\n", $iEnd))
$iTimer = TimerInit()
$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 $iMax - 1
$aDatabase[$i][0] = $i
$aDatabase[$i][1] = "Teststring"
Next
For $i = 0 To $iMax - 1
$sString &= "INSERT INTO [Source] VALUES ('" & $aDatabase[$i][0] & "', '" & $aDatabase[$i][1] & "');"
Next
_SQLite_Exec($hDB, $sString)
_SQLite_Exec($hDB, "End;") ;End of transactions => Faster!
_SQLite_Close($hDB)
$iEnd = TimerDiff($iTimer)
ConsoleWrite(StringFormat("SQLite with Array:\t%7.1f ms\n", $iEnd))
$oDictionary = ObjCreate("Scripting.Dictionary")
If @error Or Not IsObj($oDictionary) Then Exit MsgBox(0,"Fehler", "Objekt konnte nicht erstellt werden")
$iTimer = TimerInit()
For $i = 0 To $iMax - 1
$oDictionary.Add($i, "Teststring")
Next
$iEnd = TimerDiff($iTimer)
ConsoleWrite(StringFormat("Dictionary: \t%7.1f ms\n", $iEnd))
_SQLite_Shutdown()
[/autoit]???
SQLite ist bei Dir also ca 4x schneller als das Dictionary?
Hmm, da muss ich wohl nochmals über die Bücher!
Danke für den Hinweis. Ich werde das nochmals genau anschauen müssen.
Das mit dem Minimalbeispiel werde ich mir auch mal überlegen.
Allerdings könnte sich dies schwierig gestalten, da mein Chef immer mal wieder die Anforderungen "geringfügig" ändert oder "Klitzekleine" Dinge dazukommen, welche aber auf das Programm teilweise sehr grossen Einfluss haben.
Ich werde mir zuerst mal wieder alle Objekte (sicher Dictionary, Hash und SQLite) auf einem aktuellen Rechner vergleichen.
Doch das wird etwas dauern, da in den nächsten Tagen andere Dinge bei mir wichtiger sind.
Danke vorerst für diese Hilfe!
Danke!
Ich habe die Hashtable auch schon ausprobiert.
Aber leider muss ich auch für kleinere Verzeichnisse (50'000) Dateien schnell sein.
Und da ist die Hashtable (jedenfalls bei mir) massiv langsamer.
Bei etwa 600'000 Einträgen sind die beiden Objekte in etwa gleich schnell.
(Habe ich hier auch schon mal getestet: Link)
@progandy
Vielen Dank für den Link!
Ich konnte das nun testen. Und leider muss ich sagen, dass diese Lösung massiv langsamer ist, als wenn ich sequentiell einlese.
(Also das gleiche Ergebnis, wie ich schon früher erhalten habe! Sorry, aber ich konnte mich wirklich nicht mehr an diesen Thread erinnern!)
Ich werde das Ganze nun wirklich so machen, dass ich es sequentiell einlese und immer nach 1 Verzeichnis (oder ca. 1 Million Dateien) die Datensätze vergleiche.
Alles andere scheint mir wirklich ein zu grosser Aufwand zu sein, mit fragwürdigen Zeiteinsparungen.
Vielen Dank Euch allen für die angeregte Diskusion!
Gruss, Veronesi
Edit:
Nun habe ich soeben noch folgendes herausgefunden:
Wenn man in ein Scripting.Dictionary 300'000 Elemente speichert, dann dauert das etwa doppelt so lange, wie wenn man drei Scripting.Dictionary Objekte mit jeweils 100'000 Elementen befüllt.
Allenfalls könnte ich dies noch als Geschwindigkeitszuwachs nehmen, dass ich maximal 100'000 Dateien suche und dann schon vergleiche!
Hier mal ein erweitertes Beispiel zum testen dazu:
Global $oSource1 = ObjCreate("Scripting.Dictionary")
Global $oSource2 = ObjCreate("Scripting.Dictionary")
Global $oSource3 = ObjCreate("Scripting.Dictionary")
Global $oSource4 = ObjCreate("Scripting.Dictionary")
Global $oSource5 = ObjCreate("Scripting.Dictionary")
Global $oSource6 = ObjCreate("Scripting.Dictionary")
Global $oSource7 = ObjCreate("Scripting.Dictionary")
Global $oSource8 = ObjCreate("Scripting.Dictionary")
Global $oSource9 = ObjCreate("Scripting.Dictionary")
Global $oSource10 = ObjCreate("Scripting.Dictionary")
Global $iMax = 100000
Global $iTimer = TimerInit()
For $i = 1 To $iMax
$oSource1.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource2.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource3.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource4.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource5.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource6.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource7.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource8.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource9.Add($i, "Teststring")
Next
For $i = 1 To $iMax
$oSource10.Add($i, "Teststring")
Next
Global $iEnd = TimerDiff($iTimer)
ConsoleWrite("10x 100'000: " & Round($iEnd, 2) & "ms" & @CRLF)
$oSource1 = 0
$oSource2 = 0
$oSource3 = 0
$oSource4 = 0
$oSource5 = 0
$oSource6 = 0
$oSource7 = 0
$oSource8 = 0
$oSource9 = 0
$oSource10 = 0
$oSource1 = ObjCreate("Scripting.Dictionary")
$iMax = 1000000
$iTimer = TimerInit()
For $i = 1 To $iMax
$oSource1.Add($i, "Teststring")
Next
$iEnd = TimerDiff($iTimer)
ConsoleWrite("1'000'000: " & Round($iEnd, 2) & "ms" & @CRLF)
$oSource1 = 0
Hallo Andy
Leider gibt mir dieser Dos Befehl nicht alle benötigten Daten zurück.
Ich muss aus verschiedenen Medien Dateien (evtl. auch Ordner) auslesen. Von jeder Datei brauche ich zudem das Attribut Company.
Dieses Property kann ich bequem mit Shell.Application........... .NameSpace.......... .Parsename......... .GetDetailsOf herauslesen.
Das klappt wunderbar. Ich brauche leider genau dieses Attribut von den Dateien.
Und es handelt sich um die verschiedensten Medien (USB-Stick, CD, DVD, Backup-Tape, USB-HDD, IDE-HDD, SAS-HDD, SSD-HDD, SAN-Speicherarray,....)
Auf den kleinsten sind bloss ca. 50'000 Dateien drauf.
Aber auf den grössten (habe ich letzte Nacht extra zählen lassen) sind bis zu 11'975'868'102 Dateien drauf. (In Worten: Fast 12 Milliarden Dateien)
Wenn ich nun zwei solch grosse Datenträger vergleichen muss, und die Daten sequentiell einlese, dauert das schon ein Weilchen!
Könnte ich sie parallel einlesen, dann geht das (evtl.) etwas schneller.
Wenn ich zweimal 12 Milliarden Dateien in eine (riesige) Datei schreiben muss, und diese danach auch wieder komplett zweimal auslesen um zu vergleichen, bin ich überzeugt, dass dies langsamer ist!
In einem kleinen Test habe ich folgendes herausgefunden:
Klar, ich lese aber nicht alle Dateien auf einmal in den Speicher. Dann hätte ich zu wenig RAM. Ich lese immer nur entweder 1 Verzeichnis oder maximal 1'000'000 Dateien ein um danach zu vergleichen.
Auch der Vorschlag von Progandy während der Vergleichsphase weitere Datein einzulesen ist gut.
Nachid
Interessant vielleicht schon, aber für mich dann doch ein definitiver Overkill.
Dann lasse ich mein Programm lieber, wie es ist!
@progandy
Ich finde die Funktion _AutoItObject_RegisterObject wirklich nicht mehr.
Wo kann ich die finden?
Wirklich? Ich dachte dass das lesen von der Festplatte so langsam ist, dass das rumkopieren im Speicher egal ist.
Je nach Speichermedium ist es tatsächlich egal. Aber es gibt auch Speichermedien, welche ich bedienen soll, bei welchen es doch einen erheblichen Unterschied macht!
Ähhhhh...... die Funktion _AutoItObject_RegisterObject() gibt es bei mir gar nicht. (Ich habe AutoItObject V1.2.2.0)
Edit:
Peinlich!
Ich lese zuerst mal den Thread den Du verlinkt hast, nochmals genau durch 
Es geht ja um etwas änliches! Das alte Programm habe ich gar nicht mehr präsent gehabt 
Hallo progandy
So wie Du es beschrieben hast, möchte ich es ja in AutoIt umsetzen.
Mein Hauptprogramm (Prozess 0) erstellt zwei Scripting.Dictionary.
Dann startet es zwei weitere Programme (Prozess 1 und Prozess 2) und übergibt denen z.B. einen Pointer auf diese Dictionaries. Die beiden Prozesse befüllen dann diese.
Das Hauptprogramm (Prozess 0) überwacht die beiden Prozesse 1 und 2 und wartet bis sie fertig sind.
Anschliessend kann das Hauptprogramm (Prozess 0) mit den Daten arbeiten.
Genauso möchte ich es und genau so habe ich Deine Beschreibung verstanden.
Allerdings muss anschliessend nicht noch mal der Prozess 1 und 2 gestartet werden. Ich brauche das nur einmal!
Aber die Schwierigkeit ist, diese Bereiche zu erstellen und Pointer dazu zu übergeben. Ich möchte ja nicht die ganzen
Daten hin und her kopieren, denn das dauert viel zu lange.
Kannst Du mir einen Tipp geben, wie ich das mit AutoItObject bewerkstelligen kann?
Edit:
Möglicherweise geht es damit: _AutoItObject_IDispatchToPtr() und _AutoItObject_PtrToIDispatch().
Aber wie kann ich dann diese Pointer einem anderen Programm übergeben? Mit diesemScript übergebe ich ja nur Strings!
