Beiträge von BugFix

OK, Danke dir.

Ja, leck mich - Tatsache, so gehts. Aber wie soll man denn auf diese Elementbezeichnungen kommen? Im Quelltext steht doch folgendes:

Username:
	<input type="hidden"
	name="username"
	id="username"
	value="">
Passwort:
	<input type="hidden"
	name="password"
	id="password"
	value="">

Ich weiß schon, warum ich mich bisher immer gegen den FF gesträubt habe.
Aber leider tuts mein geliebtes K-Meleon nicht so richtig unter Win7.

OK, ich hatte vermutet, dass deshalb meine Eingabefelder leer bleiben.
Nun habe ich aber alle Returns ausgewertet, MozRepl funktioniert und somit werden die FF-Funktionen auch ausgeführt.
Seltsamerweise zeigen alle Funktionen Erfolg - aber meine Felder bleiben leer.

Und noch etwas Seltsames: Wenn ich obiges Skript auf eine geöffnete FF-Sitzung anwende (das im Moment im Hintergrund ist) werden die Funktionen WinActivate() / WinSetState() erfolgreich ausgeführt, aber das Fenster bleibt trotzdem verdeckt. SetWinOnTop hilft auch nicht. :wacko:

Zitat von ProblemUser

Hast du auch die aktuelle MozRepl? (MozRepl 1.1Beta2 hab ich)

guckst du

Zitat von BugFix

Installiert ist MozRepl 1.1beta2,

Nicht für die Installation - um die FF.au3 zu nutzen muß FF mit MozRepl kommunizieren, tut es aber hier nicht.
Daher meine Frage ob irgendwer FF.au3 in Verbindung mit dem FF4 nutzen kann.

Ja aber wo ist das Problem? Einfach, wie schon mehrfach gesagt:

Hat jemand von euch die FF.au3 mit dem FF4 verwenden können?
Ich bekomme folgenden Fehler:
__FFWaitForRepl ==> MozRepl Exception: !!! [Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"
Installiert ist MozRepl 1.1beta2, das einzige Mozrepl-Plugin, das sich im FF4 installieren ließ.

Guck mal hier.

Zitat von Ilse

bin langsam am Ende mit den Nerven

Ilse, zeig doch bitte mal den Text, den du verarbeiten möchtest. Und dann sag wo, was eingefügt werden soll. Deine Gehversuche verwirren uns mehr als dass sie Klarheit in dein Problem bringen.

TheLuBu
Du hast einige Fehler drin:

$search = StringinStr($aZielRead[$i],"ilse") ;String wird gesucht
$search = StringinStr($aZielRead[$i],"ilse", 1) ; hier sollte man CaseSens arbeiten um nicht Teilstrings zu finden

_GUICtrlEdit_InsertText($Ziel, @CRLF& "Text", $search) ; fügt den Text hinter dem gefundenen ein
; Falsch! $search gibt die Startposition des gesuchten Strings an - also wird DAVOR eingefügt

Um Daten auf meinem PC zu löschen reicht der 'normale' Löschvorgang völlig aus. Ich brauch mich nicht selbst davor zu schützen, dass ich meine Daten wiederherstellen könnte.
Interessant wird es nur, falls z.B. ein Laptop in der Firma von einem Mitarbeiter zum andren wechselt und man private Daten drauf hatte. Dazu verwende ich dann auch Acronis. Kommt aber nur alle 5 Jahre mal vor.

Ich verstehe nicht, weshalb du _StringBetween() verwendest. Du möchtest doch die Position im Edit herausfinden, dazu brauchst du StringInStr(). :wacko:

Lies mal mein Array-Tut, dann verstehst du auch das Warum.

Das hat nicht direkt mit dem Tab zu tun. Das passiert dir mit jedem GUI-Ctrl das du auf das Fenster setzt.
Meine Erklärung, die ich mir aus dem Verhalten erstellt habe:
Wenn du das Fenster mit gesetztem Ctrl minimierst passiert nix - aber beim Wiederherstellen wird erst der Fokus gesetzt und bekommt dann sofort die Kill-Message. Vermutlich, weil dann das Ctrl den Fokus hat.
Da du aber den Fokus des Fensters abfragst bekommst du dort keine Änderungen mehr - es hat ihn ja abgegeben.

Edit:
Übrigens gibt $wParam immer das 'entgegengesetzte' Handle zurück:
- KILLFOCUS, wParam = Fenster, das den Fokus erhalten hat
- SETFOCUS, wParam = Fenster, das den Fokus verloren hat

Aber so richtig verständlich ist es nicht. Minimiere mal und hol zurück. Seltsamerweise bekommt das Tab (oder das entsprechende Ctrl) den Fokus, verliert ihn aber nicht, zumindest läuft keine Msg dazu auf.

Stelle suchen, wo eingefügt werden soll und Position übergeben:

Kann es nicht probieren, da ich kein 64er System habe. Aber wie Greenhorn schon richtig bemerkte: die DEVMODE-Struktur ist voll daneben, sollte so aussehen

typedef struct_devicemode { 
  WCHAR dmDeviceName[CCHDEVICENAME]; 
  WORD dmSpecVersion; 
  WORD dmDriverVersion; 
  WORD dmSize; 
  WORD dmDriverExtra; 
  DWORD dmFields; 
  short dmOrientation; 
  short dmPaperSize; 
  short dmPaperLength; 
  short dmPaperWidth; 
  short dmScale; 
  short dmCopies; 
  short dmDefaultSource; 
  short dmPrintQuality; 
  short dmColor; 
  short dmDuplex; 
  short dmYResolution; 
  short dmTTOption; 
  short dmCollate; 
  BCHAR dmFormName[CCHFORMNAME]; 
  WORD dmLogPixels; 
  DWORD dmBitsPerPel; 
  DWORD dmPelsWidth; 
  DWORD dmPelsHeight; 
  DWORD dmDisplayFlags; 
  DWORD dmDisplayFrequency; 
  DWORD dmDisplayOrientation;
} DEVMODE;

das entspricht dann auch der bereits angeführten Lösung von KaFu in AutoIt

Der Grundgedanke scheitert doch schon an einer einzigen Frage (ohne die programmiertechnischen Belange zu betrachten): Was ist besser?
Ist schneller besser oder gründlicher/genauer? Besser ist immer subjektiv und läßt sich (außer bei mathematischer Fragestellung) niemals klar definieren.

Zitat von Mattthias

Ich verstehe nur nicht was die DLL bringen soll ?

Ist hier nur als Beispiel gedacht um zu zeigen wie man (rechenintensive) Vorgänge und Ressourcen auslagern kann.
(Wenn ich das Anliegen von RR04 richtig verstanden habe)

[OT] Auch wenn ich mich bei dem Pixel-Gedöns nicht wohl fühle: Solange kein Regelverstoß vorliegt gebe ich es frei. [/OT]

Zum Thema: Die Funktion gibt bei Erfolg ein Array zurück. Also prüfe die Rückgabe mit IsArray().

Na dann lass dir mal die Childs auflisten. Oder verwende zum Anschauen mal ein brauchbares Tool, wie "Winspector Spy" oder "Sysinternals Process Explorer".