Beiträge von Andy

    Hallo Gorgo,


    bitte beschreibe Dein Problem etwas genauer. Ich habe jetzt den gesamten Thread 3x komplett durchgelesen und könnte es sein daß Du die Variablen in der FOR-Schleife benutzen willst, um nicht die 1,2,3,4,...Maximaleanzahlkunden schreiben zu müssen?


    Also in etwa so?
    For $index =1 To $maximaleanzahlkunden ;wäre z.B. die Anzahl der Zeilen deiner *.INI-Datei, in jeder Zeile steht ein Kunde
    $kunde[$index] = _hierliestdieschleifedatenvonirgendwoher() ; z.B. Iniread()
    Next
    Im Feld $kunde[] wären nun alle Kunden aus der *.INI Datei enthalten.


    Um die jetzt alle als *.CSV abzuspeichern könnte man das so machen
    For $index =1 To $maximaleanzahlkunden ;wäre z.B. die Anzahl der Zeilen deiner *.INI-Datei, in jeder Zeile steht ein Kunde
    _schreibedatenirgendwohin($kunde[$index] & ",") ; z.B. in die *.CSV
    Next


    Inhalt der *.CSV wäre somit
    Kunde1,kunde2,kunde3,kunde4......


    ciao
    Andy

    Hallo,

    Zitat

    ja klar ist pixel glei pixel


    wo hast du diese Information denn her?
    Die Darstellung des pixels ist natürlich abhängig von seinem Seitenverhältnis. Und erst wenn das Seitenverhältnis(4:3 oder 16:9 oder 16:10 oder oder oder) gleich ist, dann ist bei gleicher Auflösung des Bildschirms auch die Darstellung des Bildschirminhalts gleich, völlig egal ob 14 zoll oder 22 zoll Bildschirmdiagonale.
    Warum werden wohl beim Abspielen von Filmen je nach Bildschirmformat diese netten, unterschiedlich dicken schwarzen Balken meist oben und unten an das eigentliche Bild gebastelt?
    Um also ein "quadratisches" GUI auch auf jedem Monitor quadratisch darzustellen, sollte nicht die eigentliche Auflösung, sondern das Seitenverhältnis des Monitors abgefragt werden....viel Spass dabei :D


    ciao
    Andy

    Hi,


    FireFlyer
    ja, klar könnte man das so machen, aber ein z.B. Portscanner checkt ja auch reihenweise Ports in kürzester Zeit. Genau solch eine "Anfrage" (incl. sofortiger Antwort) an den Server wird ja gesucht.
    *edit* Hatte Denkfehler, die Portscanner checken natürlich nicht EINEN port sondern extrem viele gleichzeitig, daher entsteht der Eindruck der hohen Geschwindigkeit, der eigentliche scan dauert natürlich auch ca 10-15 Sekunden.


    ciao
    .Andy

    ...oder Fractint oder ein anderes hochoptimiertes Programm verwenden.
    Mit dem hier kann man auch auf langsamen Rechnern schöne "Reinzoom-Flüge" mit der Maus machen (rechts im SEARCH-Fenster)
    Aber ich glaube der Witz liegt darin, in der Minimalstversion mit ca. 50-100 Zeilen Code mit jeder beliebigen Programmiersprache solche Bilder hinzubekommen (von der Rechenzeit mal abgesehen)


    ciao
    .Andy

    Moin Leuts,


    ich habe heute schon derbe geflucht, weil sämtliche 15-25 Jahre alten Disketten mit meinem MANDEL.BAS unlesbar waren. In grauer Vorzeit habe ich mit Turbo- oder Powerbasic einen feinen 4,77 Mhz IBM-PC mit 8088 und 8087 (Numerischer CoProzessor :rock: ) programmiert. Basic war für die Oberfläche, das Numbercruncen hat dann ein Inline-Assemblercode übernommen. Das Programm wurde nach der Anzahl der Takte/Schleifendurchgang optimiert. Ich weiß genau, daß die "innere" Schleife vollständig im 16 Byte-Stack des CoPro lief, d.h. Prozessor und Copro liefen Parallel^^...btw..die Platte hatte 10MB (nicht Gig^^) und Grafik war CGA (320x200x4), später EGA(640x480x16) . BS war soweit ich weiß Novell-DOS. In irgendeinem Schrank fliegt der Rechner noch rum, werde morgen mal suchen, vielleicht startet das Monster ja noch^^


    @topic
    Was in Autoit garkeinen Spass macht, ist auf das Setzen der Pixel zu warten :D


    Habe mal bissl gebastelt und das Programm erweitert, man kann nun mit Slidern während der Berechnung die Schrittweite der Pixel (nur jedes 2. oder 3. usw) und die Iterationstiefe einstellen.
    Damit man schnell "zoomen" kann wird bei einem Mausklick in die Grafik (auch während der Berechnung) eine 4-fache Vergrößerung an der Mausposition gestartet.
    Wenn man nun eine "schöne" Stelle gefunden hat, kann man diese mit voller Iterationstiefe und Schrittweite von 1 durchrechnen lassen.
    Dauert aber...^^


    Ggf. hat ja wer von den "Profis" lust, eine DLL (vielleicht in C) für die Schleife zu basteln, und so nebenbei das pixelsetzen zu beschleunigen. Habe beim googeln das da gefunden, aber von "pointern" wollte ich schon früher nix wissen^^


    ciao
    .Andy


    solange Ihr die NW-Architektur / Server / Programme / Strategie / auf der anderen Seite nicht kennt, könnt ihr über mögliche Ursachen nur RATEN


    Da ich sowohl die eine, als auch andere Seite bin, gibts da nicht viel zu raten.
    Wirf dem usenet oder der Tante die dementsprechenden Brocken zu und du wirst feststellen, daß es Threads über dieses Thema gibt, die teilweise 10 Jahre alt sind. Lösungsvorschläge bzw. -ansätze Fehlanzeige. Von Dokumentationen mal ganz zu schweigen.
    Teilweise funtionierts, meistens nicht^^.
    Jedenfalls bleib ich mal am Ball, man lernt ja nie aus und Bitweises vergleichen von Transportströmen durch mehrere Schichten eines Protokolls hat ja auch was ^^. Jedenfalls bekomm ich´s raus.
    ciao
    .Andy

    Definitiv liegts nicht am Router sondern an der....Anfrage!?


    Diverse Portscanner melden nach 1-2 Sekunden den Port bzw laufenden FTP-Server, genausoschnell auch den Fall, wenn ich den Serverprozess beende. Frage ist: Wie machen die das? ?(

    Habe nun mal mittels Ethereal den Paketen auf den Zahn gefühlt.


    Anfrage an den ftp-Server über lokale IP, der Client sendet ein [SYN] und "merkt" sofort , daß der Server offline ist, d.h. der Server schickt NICHTS zurück


    Anfrage an den Server über I-net (Router), der Client sendet mehrere [SYN] (das wird wohl diese schon angesprochene dynamische Timeoutgeschichte sein) bis nach ca 15 Sekunden vom Server (oder Router?) ein [RST] (reset) zurückgesendet wird, was der Client auch sofort anzeigt.....Info in diesem Paket "ACKs a Segment we have not seen (lost)" d.h. doch, der Server (bzw Rechner, der den Port 21 offen hält) hat Antworten geschickt, aber vom Client nix bekommen und deshalb die Verbindung gekappt.


    Es scheint wirklich so zu sein, daß der Router (oder Provider) Antwortpakete droppen. :thumbdown: Der Sinn erschließt sich mir nicht, 15 Sekunden warten zu müssen damit die Info kommt, dass irgendein Dienst NICHT läuft...


    Werde mal in den Eingeweiden meines Routers graben ....


    ciao
    .Andy

    Na dann frag dich mal, wozu du eine Firewall brauchst, wenn da "jeder" nach Hause telefonieren (oder pingen) kann 8)
    Natürlich muss die FW den Ping blocken, wenn du das nicht explizit freigegeben hast.


    Aber nochmal zum Topic :D
    Ping ändert nichts an meinem Problem, d.h. wenn der Rechner zwar erreichbar ist, aber der serverprozess z.b. nicht läuft.
    Habe das ganze mal auf socket-ebene getestet:

    ; aus der Hilfe
    Opt("TCPTimeout",1000) ;1000 milliseconds egal welche zahl, bringt nix....
    $szIPADDRESS = "XXX.xxx.xxx.xxx" ; ip-adresse des ftp-servers
    $nport=21 ;ftp
    TCPStartup()
    $MainSocket = TCPconnect($szIPADDRESS, $nPORT) ; wenn -1, dann keine Verbindung
    msgbox(0,"mainsocket",$mainsocket)
    If $MainSocket = -1 Then Exit

    Läuft der FTP-Server, bekomme ich sofort eine Rückmeldung (sowohl beim Server als auch beim Script), ist der Server offline, warte ich 13 Sekunden auf Rückmeldung d.h. dann erscheint erst die Msgbox. Unabhängig von der opt("tcptimeout",xxx). Dieser timeout hat wahrscheinlich nur Auswirkung auf eine bestehende Verbindung.


    *weitersuchendaltesteintafelnausgrauervorzeitentziffert* :?:
    .Andy


    *edit*
    Die Antwortpakete werden Providerseitig geblockt! Das hat wohl etwas mit evtl. möglichen DoS-Angriffen zu tun.
    Laut Protokoll/Microsoft wird die maximale Wartezeit auf Antwort dynamisch berechnet, Problem ist nun folgendes:
    1.Fall: Die angefragte IP-Adresse ist offline oder nicht existent: Router(oder Gateway im i-net) sendet eine Antwort (ICMP Paket 3), die wird vom Script innerhalb der einstellbaren Zeit (timeout) ausgewertet. Alles paletti.
    2.Fall: Die IP-Adresse ist erreichbar, ein darauf laufender Server( oder Port) aber nicht. Das Gateway(Zielrechner) sendet die Antwort "Rechner existiert (Port offen)" (per ICMP). Der anfragende Rechner weiss nun, dass die Gegenseite sendet und wartet jetzt auf ein Antwortpaket vom Zielrechner (dieser timeout ist wie gesagt dynamisch und kann m.e. nicht "einfach" verändert werden, jedenfalls habe ich nichts bis wenig dazu gefunden). Der Zielrechner sendet nun ein Paket "Port nicht erreichbar( Serverdienst läuft nicht)". Dieses Paket wird, wohl weil über ICMP Angriffe (DoS) möglich sind, vom Provider geblockt (oder vom Ziel-Router), und der anfragende Rechner wartet und wartet und wartet....., bis nach Ablauf des dynamisch berechneten timeout (bis zu 15 Sekunden) das Script die Info erhält, daß der Zielrechner nichts sendet.


    Wenn ich einen Web(FTP)Server über die lokale IP-Adresse (Lan) anfrage, bekomme ich die Antwortpakete, sobald I-net mit im spiel ist , dann nicht.

    sry, wenn man als alter DOS-ler eher an den Befehl PING denkt als an die schon in AutoIt implementierte Funktion....dann wird das nix, aber nach 5 Tassen Kaffee gehen einem ab und zu auchmal Kronleuchter auf 8o


    gute Nacht :rock:
    .Andy

    Hallo zusammen,


    ich greife per inetget() und div. _ftpxxxx auf Web- bzw. ftp-Server zu. Ist der Server offline, dauert der Versuch des Verbindungsaufbaus ca. 10 Sekunden, bevor das Script die Info Server=offline ausgibt.
    Kann man diese "Abfragezeit" einstellen? So daß man schon nach ~1-2 Sekunden die Info server=offline bekommt?
    Ich befürchte, daß diese Zeitspanne Teil des tcp ist, dann habe ich natürlich gelitten....oder doch nicht? ;(


    thx vorab
    .Andy

    @ alle
    bin zu langsam^^


    ja, das mit dem schreiben in die console ist mir klar. der fehler lag aber trotzdem nicht an der übergabe der parameter, oder steh ich jetzt völlig auf dem schlauch?


    Zitat

    Also ich habe es jetzt so gemacht aber es funkt nicht:
    Case $CMDLINE[$i] = '/Hallo'
    ConsoleWrite("Lfgdfgdfgfdgdfgvfdvgefvgfdvg")

    Ist nur ein Teil vom Script



    *edit* immer noch zu langsam^^
    die endgültige lösung hatte mit dem problem nichts zu tun, wie so oft auch bei meinen scripten :rolleyes:

    Zitat

    er meint aber das ergebnis mit cmd dann laden...
    also cmd sendet an autoit und dann EMPFÄNGT der auch was...


    eben. ob du nun per drag&drop parameter übergibst oder per console ist der *.exe völlig schnurz.
    anfangs beschrieb er das problem so, als würde er die parameter nicht übergeben können, bzw so, als kämen die übergebenen parameter nicht im script an.
    was sie aber definitiv doch taten ^^


    .andy

    Hallo zusammen,


    bei mir funktioniert die Übergabe der Parameter auch reibungslos ohne CUI-Modus.


    Einfaches Testverfahren:


    Datei erstellen mit der Zeile:
    msgbox(0,"",$cmdline[1])
    Diese Datei in eine *.EXE kompilieren.


    Dann einfach im Explorer irgendeine Datei per drag&drop auf die kompilierte *.EXE ziehen.
    Sollte dann im msgboxfenster nicht der Pfad/Dateiname der gedroppten Datei stehen, weiss ich auch nicht weiter....jedenfalls liegts dann m.e. nicht an AutoIt.


    Sollte allerdings die msgbox den pfad/dateinamen anzeigen, dann vermute ich ein Layer-8-Problem oder den berühmten handbooknotreaderror :o)


    ciao
    .andy


    *edit* so wie ich das sehe war die abfrage der parameter wohl nicht das problem....

    Hi,



    $dateiname = ControlGetText("Wallpaper-ACDSee Pro 2.5", "",59393)

    Ich kann nicht erkennen, ob der Bindestrich beim Wallpaper von Leerzeichen eingefasst ist....


    Zitat

    ControlGetText ( "title", "text", controlID )


    Parameter
    title Der Titel des Fensters, auf das zugegriffen werden soll. **** hier hattest du den $handle vom Control übergeben*******
    text Der Text des Fensters, auf das zugegriffen werden soll. ****** s. pic Nr. 3 ************
    controlID Die ID des Steuerelements, das beeinflusst werden soll. Siehe Controls. ****** rischtiiiisch^^ *****


    Sollte funktionieren, Ich habe allerdings auch schon div. Schwierigkeiten bei der Ermittlung der Statuszeile gehabt. Siehe Deinen Screen Nr. 7 bzgl. Statusbar.....


    ciao
    .Andy

    Hi,


    HIER gibts eine ausführliche deutschsprachige Hilfe zu AutoIt, incl. Beispielen zu den Funktinen usw...


    Dort ist auch deutlich beschrieben wie der IchhabedenPixelindieserFarbenichtgefunden-Fall abgefangen wird.
    Ich meine, ein kleines bisschen Selbstinitiative kann/sollte/muß man erwarten!


    ciao
    .Andy