Beiträge von Ashpool

  • Unklarheiten bei _GUICtrlRichEdit_SetParaShading

    Kann bitte mal jemand den folgenden Code unter XP testen und einen Screenshot (unter MS Word) der erzeugten Datei ( wird auf dem Desktop abgelegt) posten?



    Bei mir (unter Win7) ergeben die Schattierungsstile andere Ergebnisse, als erwartet:


    [Blockierte Grafik: http://www.jesso.gmxhome.de/Test/Test.jpg]

  • CompInfo.au3

    Wenn ich in die CompInfoExamples.au3 als erste Zeile ein #RequireAdmin
    einfüge, läuft das Skript durch, sonst nicht! :P


    (Windows 7 64bit)

  • Unbegreifliches Scriptproblem

    Man muss auch nicht jede smal ein neues IE-Objekt erstellen, sondern man kann auch _IENavigate verwenden:



    #include <ButtonConstants.au3>
    #include <EditConstants.au3>
    #include <GUIConstantsEx.au3>
    #include <StaticConstants.au3>
    #include <WindowsConstants.au3>
    #include <IE.au3>
    #include <Array.au3>
    #include <File.au3>



    #Region ### START Koda GUI section ### Form=
    $Form1 = GUICreate("Quellcode Schreiber", 343, 206, 192, 124)


    $Group1 = GUICtrlCreateGroup("Speicherpfad", 0, 80, 337, 65)
    $Input1 = GUICtrlCreateInput("Ordner", 8, 96, 297, 21, BitOR($ES_AUTOHSCROLL, $ES_READONLY))
    $Button1 = GUICtrlCreateButton("Browse", 8, 120, 97, 17, 0)
    GUICtrlCreateGroup("", -99, -99, 1, 1)


    $Group2 = GUICtrlCreateGroup("Liste", 0, 8, 337, 65)
    $Input2 = GUICtrlCreateInput("Datei", 8, 24, 297, 21, BitOR($ES_AUTOHSCROLL, $ES_READONLY))
    $Button2 = GUICtrlCreateButton("Browse", 8, 48, 97, 17, 0)
    GUICtrlCreateGroup("", -99, -99, 1, 1)


    $Button3 = GUICtrlCreateButton("In .txt Dateien exportieren", 192, 176, 139, 25, 0)


    GUISetState(@SW_SHOW)
    #EndRegion ### END Koda GUI section ###



    While 1
    $nMsg = GUIGetMsg()
    Switch $nMsg
    Case $GUI_EVENT_CLOSE
    Exit
    Case $Button1
    $File = FileSelectFolder("Ordner, in dem die Dateien gespeichert werden sollen", "")
    GUICtrlSetData($Input1, $File)
    Case $Button2
    $File2 = FileOpenDialog("Datei mit den Links", "", "Text files (*.txt)")
    GUICtrlSetData($Input2, $File2)
    Case $Button3
    Dim $links
    _FileReadToArray($File2, $links)
    $name = ""
    $Objekt = _IECreate("", 0, 0)
    For $i = 1 To $links[0]
    _IENavigate($Objekt, $links[$i])
    $HTML = _IEBodyReadHTML($Objekt)
    $name = StringSplit($links[$i], "=", 0)
    FileWrite($File & "\" & $name[2] & ".txt", $HTML)
    Next
    _IEQuit($Objekt)
    MsgBox(0, "Erfolg", "Der Quellcode wurde erfolgreich in TXT abgespeichert!")
    EndSwitch
    WEnd


    So geht es jedenfalls bei mir. :D

  • Dateiname aus Pfad extrahieren

    Zitat von Andy

    Wer hat dir den diese Weisheiten gepredigt? Wenn du jeden Tag mit dem Fahhrad zur Arbeit fährst und dort irgendwann eine tolle Maschine ausgemustert wird, schulst du dann um auf Fuhrunternehmer und kaufst eine Flotte von Sattelzügen um das Ding nach Hause zu bringen oder leihst du dir einfach mal kurz ´nen kleinen LKW?

    Darum geht es doch überhaupt nicht. AutoIt ist für mich ein Tool, um Abläufe mit möglichst geringem Aufwand zu automatisieren. Das Verwenden einer fremden Dll stellt für mich eine Abweichung von eben diesem Prinzip dar. Man muss mit den Aufrufkonventionen vertraut sein und man muss sicherstellen, dass die Dll auf den Rechnern des Anwenders installiert ist.
    Im Übrigen sind das keine Weisheiten, sondern es ist meine Meinung, die ich ja wohl noch vertreten darf.

    Zitat von Andy

    Einen 10-Zeiler schreiben, F7 drücken und die EXE in den Autostartordner schieben, dauert incl. GUI keine 5 Minuten, und es wird genau das gemacht was gemacht werden soll. Ja, ich bleibe bei meineM Leisten!

    Da muss ich mich wiederholen: Du musst sicherstellen, dass die Dll beim Anwender vorhanden ist. Und wenn dann dank Avira irgendein Teil deines Codes als Schädling eingestuft wird,
    bist du Nase. Da nützt dir auch ein einzelner Leisten nichts.

    Zitat von Andy

    Als was bezeichnest du denn eine herkömmliche Programmiersprache? Ich vermute du meinst eine Sprache, bei der man den größten programmtechnischen Unfug verzapfen kann

    Wollen wir sachlich bleiben?
    AutoIt ist keine Programmiersprache (und will es auch laut dem Willen des Entwicklers auch nicht sein), warum muss man sie zwanghaft aufblähen, um sich hinterher Gedanken über die Ausführungsgeschwindigkeit machen zu müssen?
    Herkömmmliche Programmiersprachen sind in meiner begrenzten Wahrnehmung: C(++,#), Object Pascal, Fortran und Lisp.
    Basic in allen seinen Ausprägungen ist in meinen Augen eine Krücke, die dem Behinderten den Weg ins normale Leben ebnen kann.
    Dann kommen die Skript-Sprachen, zu denen AutoIt gehört, die algorithmisch nur eingeschränkte Möglichkeiten bieten, die jedoch den Zugriff auf die GUI-Funktionen des Betriebssystems deutlich vereinfachen können.


    Aber warum muss man nun jedes Problem in AutoIt lösen können wollen/müssen?
    Aber ich finde es wirklich albern, eine Skriptsprache zu verwenden, und sich dann über Ausführungsgeschwindigkeiten im ms-Bereich zu unterhalten.
    Um hier irgendwelchen Flame-Wars zuvorzukommen, wird das mein letzter Beitrag in diesem Thread sein, sollte noch Mitteilungsbedarf bestehen, kann man mich ja über PN kontaktieren.


    Sorry for the bad atmosphere!


    P.S.: Assembler habe ich vor ca. 20 Jahren aufgegeben.
    Bitte nicht falsch verstehen, ich schätze dein Wissen und deine Arbeit für das Forum

  • GUI fixieren

    Zitat von Milla

    so dass man es nicht verschieben,vergrößern oder verkleinern kann?


    Mal so 'ne Idee aus der Hilfe:


    GUICreate("Test",200,100,default,default,$WS_DLGFRAME)


    Zum Probieren hier mal ein ausführbares Skript:



    Soviel zum Thema vergrößern/verkleinern. Das (Nicht-) Verschieben bekommen wir auch noch hin.
    Ist das das, was du dir vorgestellt hast?

  • Dateiname aus Pfad extrahieren

    Ich will ja nicht meckern, aber konterkariert die Verwendung einer DLL nicht gerade den Ansatz von AutoIt, ohne jegliche externe Zutat genau das zu tun, was man erwartet?
    Und wenn's um Geschwindigkeit geht, sollte wohl jeder noch so dämliche Versuch in einer herkömmlichen Programmiersprache um Größenordnungen schneller sein, als der optimalst optimierte AutoIt-Code!


    Schuster, bleib bei deinen Leisten!

  • Deutsche Hilfe - was gibts zu optimieren?

    Zitat von Tweaky

    wie würdest du Control dann übersetzen :?:

    Da hab ich auch keine Idee, ich wollte nur ausdrücken, dass ich das Wort Steuerelement 'sperrig' finde ('umständlich' war also falsch ausgedrückt, da es ja suggeriert, ich hätte eine einfachere Alternative anzubieten :rolleyes: ). Ich muss jedes mal nachschauen, ob ich alle 'e's drinnen habe, es scheint irgendwie meinen Schreibfluss zu stören :D.

  • Deutsche Hilfe - was gibts zu optimieren?

    Also ich bin wie Greenhorn auch dafür, in den Beschreibungen die deutschen Entsprechungen für die Bezeichnungen der Steuerelemente zu verwenden.
    Es ist doch nicht Schlimmes dabei, wenn nach einer Zeile wie
    GUICtrl_Listview_Create(....)
    in der Beschreibung dann "Erstellt ein Listenansicht-Steuerelement" steht, obwohl ich den Begriff "Steuerelement" sehr umständlich finde.
    Das mit den englischen Bezeichnungen in Klammern hatten wir doch schon mal, ich fand die Lösung sehr gut, aber leider wurden sie dann oftmals von den Rewievern wegrationalisiert.


    Zum Thema Eltern-/Kindelement oder Haupt-/Unterelement: Ich würde Ersteres favorisieren, weil es den Objektansatz besser wiedergibt, außerdem kommen in einigen Texten auch Subitems vor, die ja dann mit Unterelement übersetzt werden können. Ich weiß jetzt aber gerade nicht, ob Child- und Subitem im selben Kontext vorkommen oder nicht.


    Interessant finde ich die Frage, ob man "radio button" übersetzen sollte. Ein klares JA von mir, da es wirklich Leute geben soll, die dahinter eine Schaltfläche zum Aktivieren des Webradios vermuten! Mein Vorschlag (lt. dict.cc: "Optionsschaltfläche").

  • Testbutton für .au3 Files

    Also ich würde das gut finden, ich teste beim Reviewen sowieso jedes Beispiel in SciTe, es würde also ein paar Klicks ersparen. :)


    Außerdem würde ich gut finden, wenn die Vorschau der txt-Dateien nicht nur in LastAction und der SuFu verfügbar wäre, sondern auch in den Kategorie-Ansichten.


    Und leider erscheint in LastAction immer noch der Name des Übersetzers und nicht der des letzten Bearbeiters. :(

  • Anleitung für deutsche AutoIt-Hilfe, Funktionsbeschreibung und SciTe-Gui

    Nachdem mich mein kleiner Bruder mal wieder genervt hat, wie er SciTe und AutoIt auf Deutsch umstellen kann, hab ich mal 'ne kurze Anleitung verfasst und inkl. der Links zu den benötigten Dateien hier eingestellt:



    Aktuelle AutoIt-Version
    Aktuelle Scite4AutoIt-Version
    Deutsche Hilfe-Dateien
    au3.api und locale.properties

  • Anzeige in "Last Action"

    Ich finde es äußerst unübersichtlich, das in der "Last Action"-Liste auch die Aktionen auftauchen, die an einer Datei vor der letzten Aktion durchgeführt worden sind.
    Ich glaube, das war vor Kurzem schon mal besser gelöst.
    Ich weiß jetzt gerade nicht, ob das auf einem Vorschlag von Tweaky basiert, aber besser fände ich, wenn in der Liste "Last Action" wirklich nur die letzte Aktion an der Datei erscheint.
    Wenn man die Datei dann ausgewählt hat, dann wäre ja so eine Art Historie nicht schlecht, aber in der Übersicht störts (finde ich).


    Mal so am Rande: Die deutsche Übersetzungsseite der AutoIt-Hilfe wählt als Kategorie "Last Action"? ?( Mir ist schon klar, dass sich im IT-Bereich nicht alles 1:1 übersetzen lässt, aber "Letzte Aktion" oder so ähnlich wäre doch sicher auch 'ne Alternative.


    Aber unabhängig davon will ich dem Der_Doc (kannste dir nicht 'nen anderen Namen ausdenken, ich komme da immer mit der Grammatik in Schwulitäten ;) ) nochmal meine äußerste Hochachtung für seine unzähligen Mannjahre, die er in die HelpTranslation investiert hat, entgegenbringen! :thumbup:


    Mach weiter so!