Beiträge von Andy

Hi,

in linker TV Item anklicken und dann den Button unten

#include <Array.au3>
#include <GuiTreeView.au3>
#include <GuiConstants.au3>


; Dieses Array ist ein Beispiel dafür, wie die Daten aus den FahrtenbuchDateien zurück gegeben werden.
Global $a_FahrtenbuchDaten[13][3] = [[12], ["2012", "November", "01  (Montag)"], ["2012", "November", "02  (Dienstag)"], ["2012", "Dezember", "03  (Mittwoch)"], ["2013", "Oktober", "04  (Donnerstag)"], _
        ["2013", "November", "05  (Freitag)"], ["2013", "Dezember", "06  (Samstag)"], ["2014", "November", "07  (Sonntag)"], ["2014", "November", "08  (Montag)"], _
        ["2014", "November", "09  (Dienstag)"], ["2015", "Juni", "10  (Mittwoch)"], ["2015", "August", "11  (Donnerstag)"], ["2015", "Oktober", "12  (Freitag)"]]


; Dieses Array ist ein Beispiel dafür, wie FileListToArray() in der Funktion "TreeView_Fahrtenbuch()" die Daten zurück gibt.
Global $a_Fahrtenbuch[5] = [4, "Fahrtenbuch 2012.dat", "Fahrtenbuch 2013.dat", "Fahrtenbuch 2014.dat", "Fahrtenbuch 2015.dat"]


Global $hGui, $hSoSollsWerden, $hTreeView




Func _SoSollsSein()
    $hSoSollsWerden = GUICtrlCreateTreeView(250, 50, 200, 500)
    GUICtrlSetBkColor(-1, 0xFFFBBB)
    GUICtrlSetFont(-1, 12)
    Local $1 = _GUICtrlTreeView_Add($hSoSollsWerden, 0, "2012")
    Local $2 = _GUICtrlTreeView_Add($hSoSollsWerden, 0, "2013")
    Local $3 = _GUICtrlTreeView_Add($hSoSollsWerden, 0, "2014")
    Local $4 = _GUICtrlTreeView_Add($hSoSollsWerden, 0, "2015")
    Local $1_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $1, "November")
    Local $1_2 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $1, "Dezember")
    Local $2_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2, "Oktober")
    Local $2_2 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2, "November")
    Local $2_3 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2, "Dezember")
    Local $3_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $3, "November")
    Local $4_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4, "Juni")
    Local $4_2 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4, "August")
    Local $4_3 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4, "Oktober")
    Local $1_1_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $1_1, "01  (Montag)")
    Local $1_1_2 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $1_1, "02  (Dienstag)")
    Local $1_2_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $1_2, "03  (Mittwoch)")
    Local $2_1_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2_1, "04  (Donnerstag)")
    Local $2_2_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2_2, "05  (Freitag)")
    Local $2_3_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $2_3, "06  (Samstag)")
    Local $3_1_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $3_1, "07  (Sonntag)")
    Local $3_1_2 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $3_1, "08  (Montag)")
    Local $3_1_3 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $3_1, "09  (Dienstag)")
    Local $4_1_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4_1, "10  (Mittwoch)")
    Local $4_2_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4_2, "11  (Donnerstag)")
    Local $4_3_1 = _GUICtrlTreeView_AddChild($hSoSollsWerden, $4_3, "12  (Freitag)")
    _GUICtrlTreeView_Expand($hSoSollsWerden)
EndFunc                                                                  ;==>_SoSollsSein




$hGui = GUICreate("TestGUI", 470, 660)
GUISetBkColor(0xFFFBBB)
GUICtrlCreateLabel("So soll es aussehen...", 250, 20, 200, 30, $SS_CENTER)
GUICtrlSetFont(-1, 12, 800, 4)
GUICtrlCreateLabel("So ist es aktuell...", 20, 20, 200, 30, $SS_CENTER)
GUICtrlSetBkColor(-1, 0xBBBBBB)
GUICtrlSetFont(-1, 12, 800, 4)
_SoSollsSein()
$hTreeView = GUICtrlCreateTreeView(20, 50, 200, 500)
GUICtrlSetBkColor(-1, 0xBBBBBB)
GUICtrlSetFont(-1, 12)
_TreeView_Fahrtenbuch()                                                  ; Diese Funktion soll mir das TreeView mit den Daten aus dem Array "$a_FahrtenbuchDaten" befüllen.


$button = GUICtrlCreateButton("geklicktes Item", 100, 630)


GUISetState(@SW_SHOW)
While 1
    Switch GUIGetMsg()
        Case $Gui_Event_Close
            Exit
        Case $button


            $selectID = _GUICtrlTreeView_GetSelection($hTreeView)
            $tree_text = _GUICtrlTreeView_GetTree($hTreeView, $selectID)




            $file = StringReplace(StringLeft($tree_text, StringInStr($tree_text, " ") - 1), "|", "_") ;nur , wenn tag angeklickt
            If $file <> "" Then $file &= ".DAT"


            MsgBox(0, 0, "itemindex: " & $selectID & @CRLF & "Tree: " & $tree_text & @CRLF & "File: " & $file)




    EndSwitch
WEnd
#EndRegion ####                                                          ; Do not touch anything below this line ;-)))




Func _TreeView_Fahrtenbuch()                                             ; <---------------- Um diese Funktion dreht sich das Ganze.
    _GUICtrlTreeView_DeleteAll($hTreeView)
    Local $Anzahl_Jahre = $a_Fahrtenbuch                                 ; <---- Diese beiden Arrays werden im eigentlichen Script zwar anders deklariert,
    Local $a_FB_DATA = $a_FahrtenbuchDaten                               ; <-- aber im Endeffekt sind die Inhalte der Daten absolut identisch.
    Local $Index_Total = $a_FB_DATA[0][0], $Monat = "", $MonatCheck = "", $Jahr = ""
    Dim $hItem_Jahr[$Anzahl_Jahre[0] + 1], $hItem_Monat[1], $hItem_Tag[1]
    For $i = 1 To $Anzahl_Jahre[0]
        $Jahr = StringTrimRight(StringRight($Anzahl_Jahre[$i], 8), 4)
        $hItem_Jahr[$i] = _GUICtrlTreeView_Add($hTreeView, 0, $Jahr)
        GUICtrlSetFont(-1, 12, 800)
        $MonatCheck = ""
        $LastMonatControl = -1
        For $k = 1 To $Index_Total
            If $a_FB_DATA[$k][0] = $Jahr Then
                $Monat = $a_FB_DATA[$k][1]
                If $Monat <> $MonatCheck Then
                    $LastMonatControl = _GUICtrlTreeView_AddChild($hTreeView, $hItem_Jahr[$i], $Monat)
                    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $LastMonatControl = ' & $LastMonatControl & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console
                EndIf
                _GUICtrlTreeView_AddChild($hTreeView, $LastMonatControl, $a_FB_DATA[$k][2])
                $MonatCheck = $Monat
            EndIf
        Next
    Next
    _GUICtrlTreeView_Expand($hTreeView)
EndFunc                                                                  ;==>_TreeView_Fahrtenbuch








==>_TreeView_Fahrtenbuch

//EDIT
gibt den Dateinamen zurück, sobald ein Tag selektiert wurde

Hi,
teste das mal

Do                         ;schleife so lange wiederholen bis der namenskonflikt nicht mehr besteht
    $name = -1             ;vorbelegen
    If $Dateiname = ("I:\AIS_" & $Datum & $Dateiname) Or ("I:\AIS_" & $Dateiname) Then
        $name = MsgBox(262144, "Namenskonflikt!", "Dieser Dateiname existiert bereits!")
    EndIf
    If $name = 1 Then       ;Namenskonflikt
        $NeuerName = InputBox("Name", "Bitte korrigieren Sie den Namen:", $Dateiname)
        $Dateiname = $NeuerName
    EndIf
Until $name = 1             ;solange ein Namenskonflikt besteht

//EDIT
wieder mal nur 2ter...
@chip, wenn $name mit 1 vorbelegt ist, landest du in einer Endlosschleife

Hi,

Ping nützt dir nur etwas, wenn du herausfinden willst, ob der Rechner läuft.
Das hat NICHTS damit zu tun herauszufinden, ob dort auch die benötigten Dienste, bspw. Mail/FTP/File-blablubServer-Dienste, erreichbar sind!

vgl. HIER und HIER, die Antwortzeiten werden von M$-Betriebssystemen (und anderen btw. auch) dynamisch berechnet und können bis zu 15 Sekunden im Fall eines nicht laufenden Dienstes betragen!

Zitat von alpines

Handy-CPUs meist die ARM-Architektur haben,

....abwarten, WIN10 erwartet x86-Code auch auf ARM-Prozessoren, ich finde das Konzept gar nicht schlecht...warte mal, da gabs doch schon vor 20 Jahren was ähnliches...wie hiess das noch....sollte auf allen Maschinen laufen...ähhh...jetzt hab ichs, JAVA war´s! Und dann floppte dotNET mit dem gleichen Ansatz...
Mal sehen, ob die Jungs aus Redmont diesmal ein lebendiges Karnickel aus dem Hut zaubern können?!

Hi,
dieses Aufgabenfeld schreit doch nach UEZ!
GDI+ Animated Loading / Waiting Screens mit 32 Beispielen (Stand: 2014-05-06)

Ich hatte den obigen Post als Antwort auf AspirinJunkie bereits editiert.
in 2010, als dieses Script geschrieben wurde, war imho die 3.3.6 aktuell und nicht die 3.3.8.1, die gab es erst 2012!!

Habe eben mal nachgeschaut, in der Firma benutz(t)e ich tatsächlich auch die 3.3.6 . Das wird in dieser Woche dort mal ausprobiert!
Vielleicht finde ich ja wirklich noch auf einer meiner alten Platten (liegen in der Bank im Tresor) die damals aktuelle Version .
Und ein XP-Rechner steht noch komplett auf dem Speicher.
Sehr misteriös....

Ändert aber alles nichts daran, dass der Thread von "damals" vergleichbare Zahlen/Ergebnisse liefert.

hmmm, da ist offensichtlich etwas oberfaul

bitte mal das von mir verlinkte Script von "damals" durchlaufen lassen und die letzen Zeilen posten.
Dann dort die casesense-flags setzen und die sicherheitshalber auch mal posten.

Es macht nichts, wenn ihr die dll´s nicht habt, es geht sowieso nur um die AutoIt-Funktionen.
Da zzt. mobil online und die dll´s nicht im Zugriff, poste ich das komplette Paket später noch mal...

@AspirinJunkie,
die Grafik sagt mir eigentlich nur, dass auf deinem System aktuell der von dir geposte Code im Bezug der AutoIt-Versionen in etwa gleich schnell ist.
Dass die RegEx-Engine zugelegt hat ist unzweifelhaft für uns alle ein Vorteil, auf meinen Rechnern (alle AMD) teilweise wesentlich mehr als der von dir angegebene Faktor 1.2!

Was ich allerdings nicht verstehe, sind deine Angaben zum StringInstr() und Stringreplace().

Ich habe das "damals" in diesem Thread vorgestellte Script (Suche von NEEDLE in a HAYSTACK) nochmals auf aktueller AutoIt-Version laufen lassen.
Lassen wir aussen vor, dass für alle Algorithmen eine in etwa lineare Suchzeit abhängig von der Größe des Haystacks gilt und beschränken uns nur auf den 52MB großen String:

Suchzeiten in Millisekunden: damals (9.Februar 2010) = AutoIt 3.3.6 (Release 3.3.8.1 erst im Januar 2012!) heute=3.3.12

Stringlänge     Suchzeit   Boyer-Moore        StringInstr            FindBytes              StringRegExp        Stringreplace
damals     52428651             766.900541             3617.06166             535.991306             1134.43077             577.359971  
heute      52428651             653.176145             9291.22775             468.556555             240.314610             5136.25052

Deine Boyer/Moore-Umsetzung liegt als dll vor, genau wie Findbytes aus der prospeed.dll. Ich gehe jetzt einfach mal davon aus, dass diese beiden Funktionen auf meinem Rechner damals und heute gleich schnell laufen (ich weiss, du bist ein ganz genauer, aber hier geht es nicht um +-10% )
StringRegExp hat Faktor 4,7 zugelegt, da ziehe ich wirklich den Hut!
Jetzt solltest du allerdings erklären können, wieso StringInstr ca. 2.5x langsamer läuft, und StringReplace ca. 9x langsamer....
Und das ist mir nicht nur im Beispielscript aufgefallen, sondern in einigen meiner beruflich genutzten Anwendungen.

//EDIT
Mal ausser Konkurrenz StringInstr() und StringReplace() mit gesetztem casesense-flag, da tue ich mir kein RegEx an

Stringlänge     Suchzeit   Boyer-Moore        StringInstr            FindBytes              StringRegExp        Stringreplace
          52428651             721.892732             336.473134             473.657176             188.530235             589.024543

und wen es interessiert, hier gibt es eine feine Dokumentation zu Agner Fog´s für C++ optimierten Bibliotheken:
http://www.agner.org/optimize/
dort sind auch die Downloadlinks zu finden.

@AspirinJunkie, mit Zugriff auf den neuen INTEL-Compiler und die dort angehängten Bibliotheken und Möglichkeiten der Verwendung externer Hardware (Grafikkarten) durch einfache #pragma<blablub> kannst du wahrscheinlich darüber nur lachen...jaja, ich bin zugegebenermaßen ein kleines bisschen neidisch

//EDIT2
Da die RegEx-Engine wirklich rasend schnell ist, stellt sich mir die Frage, wieso man nicht die Stringfunktionen nur als Wrapper für einen StringRegExp-Aufruf nimmt....damit werden diese gleich schnell und das Umschreiben der Funktionen gestaltet sich als Einzeiler...

Zitat von BugFix

@Andy, vermutlich müssen wir für 3.3.12 die nativen Stringfunktionen per FASM einbinden um den Speed von 3.3.8 wieder zu erreichen.

Mich hat es ja schon in den Fingern gejuckt

Aber wesentlich einfacher ist, einfach bei der 3.3.8 zu bleiben....
Sämtliches Objektgedöns wickele ich sowieso direkt in VBA ab, alternativ funktioniert die "alte" Excel-UDF immer noch!
Meinen programmiertechnisch eher unbedarften Kollegen einen RegEx-Kurs nahezubringen dürfte auf totales Unverständnis stossen! Die haben das in ihrem ganzen Leben noch nicht gebraucht, und werden das auch in Zukunft nicht brauchen!

Ternäre Operatoren?! "Alter, wer soll denn DIESE Programmzeile verstehen? Schreib das gefälligst LESBAR als IF/THEN/ELSE, das kapieren auch die Programmierer unserer Produktionsmaschinen sofort auf Anhieb!"

"Und was soll überhaupt dieses AUTOIT? Statt die diversen Branchensoftware "fernzusteuern", schreib/lese doch per VBA direkt aus deren Datenbank, das machst du doch aus Excel auch!!"

Manchmal bin ich echt froh, KEIN Programmierer zu sein....

RegEx ist für "Viel-Text-Bearbeiter" die ultimative und schnelle Waffe, da gibt es gar keine Diskussion! Und ein Geschwindigkeitsgewinn dieser Engine hilft ALLEN Anwendern weltweit, egal in welcher Sprache sie arbeiten!

Sehr wohl sei aber die Frage erlaubt, wieso gerade bei einer "langsamen" Scriptsprache bei Simpelst-Funktionen noch absichtlich gebremst wird?!
Den ersten Reflex bei einem derartigen Vorkommen, nämlich ein Ticket zu schreiben, unterdrücke ich mittlerweile...

Die logische Konsequenz, und das ist jetzt kein Witz, ist doch, sämtliche "einfachen" Stringfunktionen komplett zu entfernen und den User darauf hinzuweisen, diese durch RegEx-Konstrukte zu ersetzen!
Den Aufschrei der Nicht-"Goldstatus-User" (hehe, DER hat mir gefallen ^^) kann ich mir vorstellen
Da man das vermeiden will, kommt bei solchen Threads aus dem Lager der "Goldstatus-User" der wohlgemeinte Rat, RegEx zu benutzen, das sei "professioneller" und nebenbei auch noch 10x schneller (s.o. AspirinJunkies Beispielscript).

Einige (teilweise zugegebenermaßen profilneurotische) TOP-Entwickler abzusägen und durch wesentlich profilneurotischere Leute (mit deutlich weniger Skill) zu ersetzen hat noch keinem Produkt gutgetan....
Sonst würden die TOP-TEN der Hard/Softwareindustie immer noch in ihrer Garage hocken und an ihren Prototypen rumbasteln...

//EDIT

Zitat von alpines

Da wird einmal erwähnt das mal man mit den Funktionen die Anzahl zählen kann und schon wird alles zerlegt und gebenchmarkt

Stell dir vor, einige alte Scripte von dir, welche intensiv Stringfunktionen mit größeren Textdateien nutzten, sind nun, nur weil sie mit der neuesten AutoIt-Version compiliert werden, jetzt extrem langsamer...
Alle Anwender deines Scriptes warten jetzt länger, das summiert sich bei der tägl. Arbeit auf Stunden...
Du erklärst das deinem Chef damit, dass du eine "neue" Compilerversion benutzt und der fragt dich, ob du noch alle Tassen im Schrank hast, KEIN Entwickler würde sein Produkt künstlich schlechter machen!
Also setzt du dich hin und schreibst ALLE je von dir geschriebenen Scripte mit Stringfunktionen in die RegEx-Variante um! Was deutlichen Zeitaufwand bedeutet aber natürlich auch wesentlich "professioneller" ist! Aber billiger, als alle Anwender der Scripte warten zu lassen, ist es auch! DAS wiederum kapiert jeder Chef sofort, dein Job ist wieder mal eine Woche länger gesichert...
Ein HOCH auf die AutoIt-Entwickler, mit jeder neuen Version werden Jobs in der IT sicherer, Arbeit für Scripter ist mit jeder neuen Version GARANTIERT!!!

Hallo zusammen,

neulich gab es eine interessante Diskussion in der Shoutbox, die ich an dieser Stelle noch einmal aufgreifen wollte.
Es ging um die "Suchgeschwindigkeit" diverser AutoIt-eigener Funktionen.

Dazu hatte AspirinJunkie ein kleines Testscript gepostet, welches StringRegExp() (und auch Replace) als wesentlich schneller als die "nativen" Funktionen StringReplace() und auch Stringinstr() auswiesen.

Global $s_String = BinaryToString(InetRead("https://autoit.de/"), 4)
 
ConsoleWrite(StringLen($s_String) & @CRLF)
For $i = 1 To 10
        $s_String &= $s_String
Next
ConsoleWrite(StringLen($s_String) & @CRLF)
 
Global Const $N = 5
Global $x, $s_Search = "AutoIt"
 
$iT = TimerInit()
For $i = 1 To $N
        StringReplace($s_String, $s_Search, $s_Search, 0, 1)
        $x = @extended
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringReplace CS", $iT / $N, $x))
 
$iT = TimerInit()
For $i = 1 To $N
        StringReplace($s_String, $s_Search, $s_Search)
        $x = @extended
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringReplace CI", $iT / $N, $x))
 
$iT = TimerInit()
For $i = 1 To $N
        $x = UBound(StringRegExp($s_String, $s_Search, 3))
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringRegExp CS", $iT / $N, $x))
 
$iT = TimerInit()
For $i = 1 To $N
        $x = UBound(StringRegExp($s_String, "(?i)" &  $s_Search, 3))
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringRegExp CI", $iT / $N, $x))
 
$iT = TimerInit()
For $i = 1 To $N
        StringRegExpReplace($s_String, $s_Search, "")
        $x = @extended
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringRegExpReplace CS", $iT / $N, $x))
 
$iT = TimerInit()
For $i = 1 To $N
        StringRegExpReplace($s_String, "(?i)" &  $s_Search, "")
        $x = @extended
Next
$iT = TimerDiff($iT)
ConsoleWrite(StringFormat("% 25s: %6.3f ms\tn = %3d\n", "StringRegExpReplace CI", $iT / $N, $x))

Allerdings sieht das mit den "alten" AutoItversionen wiederum völlig anders aus!
String nach zeichen durchsuchen

vgl heute:

Stringlänge  Boyer-Moore   StringInstr   FindBytes    StringRegExp   Stringreplace
251           0.30482085   0.13116089   0.34292346    0.11504056      0.08866183
651           0.19271126   0.32900135   0.25645985    0.03590438      0.19857320
1451          0.20736611   0.77011231   0.25865808    0.03810260      0.42352513
3051          0.25352888   1.56220690   0.27404567    0.04543003      0.88808384
6251          0.38542252   3.23212694   0.36050928    0.07913618      1.89413923
12651         0.52244536   7.01893992   0.42352513    0.09232554      3.69375468
25451         0.80674943   14.1587823   0.54882409    0.15387591      7.27320155
51051         1.72634121   27.4573250   1.57832723    0.40593931      14.4079147
102251        3.01816615   52.7515944   2.20482203    0.75692295      26.8843204
204651        6.23710373   104.664931   3.77362361    1.41785664      56.6241382
409451        12.1144309   209.560676   7.86232648    3.64685917      112.311098
819051        28.6062652   420.421238   16.4339476    6.82256495      212.509232
1638251       49.6660159   763.889865   32.9375058    13.6707758      443.497496
3276651       112.843802   1538.02054   56.9655962    25.3279755      880.808449
6553451       170.384601   2596.69855   126.769573    53.3216680      1553.45575
13107051      222.120615   3161.95439   151.180887    71.3771747      2020.19731
26214251      884.983615   12665.1572   490.066210    206.091141      6898.92404

Ich will ja niemandem auf den Schlips treten, aber wenn eine Funktion in egal welcher Bibliothek hochoptimiert ist, dann die Suchfunktion von Strings in Strings!

Dass PCRE hochoptimiert und im Lauf der Jahre ggf. sogar multithreaded doppelt bis dreimal so schnell wird, akzeptiere ich, aber dass eine 6 Jahre alte SUCHFUNKTION aus einer Bibliothek Faktor 3-4 SCHNELLER sein soll als eine aktuelle Funktion, kann mir wirklich keiner mehr erzählen....
Für mich sieht das so aus, als ob, nachdem in einigen Threads im EN-Forum das "elitäre" RegEx mit "simplen" Stringfunktionen geschwindigkeitsmäßig an die Wand gespielt wurde, dieses "Sakrileg" in den neueren AutoIt-Versionen einfach "korrigiert" wurde.

Wer möchte, kann die Funktionen gerne unter 3.3.6 oder 3.3.8 testen und sich bei den Stringfunktionen gegenüber der aktuellen Version 3.3.12. um Faktor 3-4 an Geschwindigkeitszuwachs wundern.

Da wird AutoIt-Usern im Jahre 2015 ein Golf II als "neu" verkauft und alles freut sich!

Da brauchst du garnix "basteln", Lochbleche gibts für ne Handvoll Euros in jedem Baumarkt oder (besser, da gehe ich immer hin) beim Schlosser/Metallbauer um die Ecke.

Wenn du dem Schlosser noch ne Schachtel Zigaretten in die hohlen Rippen schmeisst, kantet der dir das Lochblech so, wie du es brauchst
Für ein Computercase bietet sich Aluminium an, kannst aber auch Edelstahl nehmen, dann kannst du dir den Dreck mit dem Acrylglas und der Beleuchtung sparen, ist dann auch so ein Hingucker...

Lochbleche, Lochbleche, Lochbleche.....

Zitat von UEZ

Im transparenten Modus?

Sofort nach Start der Uhr, ich vergleiche mal mit der vorherigen Version, die läuft einwandfrei!
Aero ist eingeschaltet.

Übrigens lustig, wenn man den Laptop aufklappt und dieser "aufwacht" rotieren die Augen immer so schön SUPER IDEE!!

Irgendetwas ist unfit, das ist die Uhr, Win7-64 Laptop
uhr.PNG

seeeeehr geschmeidig

Hi,

Zitat von life2play

gibt es eine saubere und einfache Möglichkeit mit AutoIt Parallelität zu ermöglichen?

Sauber und einfach schließen sich aus. Fast immer. Möglich ist alles, bei entsprechendem Aufwand. Die Frage ist, was du mit "Parallelität" meinst.

Zitat von life2play

Insbesondere bei einer GUI-Anwendungen ist es wünschenswert, dass das GUI weiterhin reagiert, während das Script andere Funktionen ausführt.

Das hat aber mit "Parallelität" im Sinne von Multithreading/Multitasking nichts zu tun. Btw. ist Multithreading/Multitasking bei eine "GUI"-Anwendung völlig fehl am Platz, da der Prozessor bei dieser Art der Anwendungen meist sowieso im völligen Tiefschlaf liegt.

Zitat von life2play

Möglicherweise mit einer Controller-Datei, welche andere Dateien aufruft, welche eigenständig arbeiten und durch das Betriebssystem pseudo-/parallel laufen?

Aha...
Pseudo-Parallel
Wenn man selbst zu faul ist (oder die Technik dafür nicht berherrscht) überlässt man andern die Arbeit, in diesem Fall dem Betriebssystem. Genau aus diesem Grund waren/sind die "neuen" Betriebssysteme so erfolgreich. Man muss nicht jedes Mal das Rad neu erfinden!
Das wäre, gerade im Hinblick auf AutoIt, mein persönlicher Favorit, um an ein "parallel"-Projekt heranzugehen.

Zitat von life2play

[Wie kann man allgemein Projekte in AutoIt gestalten? - Kommunikation zwischen Prozessen - Gibt es hierzu evtl. ein TUT?]

Es gibt viele Wege der InterProzessCommunikation (IPC). Ob da "einfache" Modelle dabei sind, muss jeder selbst entscheiden, ich denke, dass in den meisten Fällen simple Techniken sowohl das Debugging als auch die Stabilität positiv beeinflussen.
Einer der vielen Links zu diesem Thema, sehr interessant die Lösungen und ein feines Beispiel dafür, wie ein Problem von mehreren Leuten zusammen gelöst werden kann: Kommunikation Skripte untereinander

Hi,
du kannst entweder den OnEventModus oder den MessageModus benutzen, beides zusammen geht nicht...

Zitat von bollen

noch ein altes stück code eine schlichte variante von Tic Tac Toe

erinnert mich an einen Freund, der 1984 mit ein bisschen Fädeldraht und einem 32 BYTE großen "Ram"-Chip aus einem Casio FX82 einen "programmierbaren" Taschenrechner bastelte. Auf diesem Gerät konnte man tatsächlich ein lernfähiges TiCTacToe spielen. In 32 Byte Ram! Man hat das "Programm" gestartet und konnte durch eine Taste auswählen ob der Rechner anfängt oder der Spieler. Das Spielfeld war aus den Ziffern 1-9 auf der Taschenrechnertastatur aufgebaut....
Nach einigen Runden Spielen hat der Computer immer mindestens ein unentschieden erreicht!

Daran muss ich immer denken, wenn ich den Begriff KI im Zusammenhang mit TicTacToe lese^^

Hi,

auf den ersten Blick schön gemacht...

Auf den zweiten Blick...
Ein Labyrinth macht eigentlich nur Sinn, wenn es mehr als einen (vorgegebenen) Weg gibt.
Ich habe jetzt mehrere Labyrinthe durchprobiert, leider gab es bei jedem nur einen möglichen Weg.

Zitat von UEZ

Irgendwie laufen die Sekunden nicht sauber...

"nicht sauber" ist stark untertrieben. Abhängig von der eingestellten Zeit für den TimerSet sollte die Laufzeit von Eye_Clock() gleichmäßiger sein. Bei meinem Laptop habe ich bis zu 200ms Laufzeitunterschied in dieser Funktion. Ab und zu auch mehr. Daher führt eine "feinere" Auflösung unweigerlich zu "ruckeln"...

Ansonsten ist das klasse

Um die Pupillen unabhängig von der rechteckigen GUI zu machen , könnte man je Auge eine runde GUI erstellen. Dann noch ein TOPMOST und die Uhr über die Zeit/Datumsanzeige in der Traybar projeziert und und und ......