Beiträge von misterspeed

Zitat von ExBerliner

Vielleicht entdeckt ja jmd. was. Jedenfalls kann ich hier nicht mit "_IEFormGetObjByName" oder ähnliches arbeiten. Nach meinen Kentnissen jedenfalls.

Also nur anhand des HTML Quellcodes den du da gepostet hast sehe ich kein Problem darin Anstelle von send() und den Window Funktionen komplett auf die IE Funktionen zu setzen. Das löst evtl. das Problem.
Relevante Stellen für den Login:

<INPUT id=user name=user 
<INPUT id=pwd name=pwd type = "password"
background=./images/button.jpg

Die beiden Inputs sollten mit diesen Funktionen ausfüllbar sein:

_IEGetObjById()
;oder
_IEGetObjByName()

_IEFormElementSetValue()

Danach kommen dann noch diese Funktionen in Frage:

_IEFormSubmit()
_IEImgClick() ; sofern die button.jpg von oben zum login Button gehören sollte...

#include <GUIConstantsEx.au3>
#include <SliderConstants.au3>
#include <WindowsConstants.au3>

$Form1 = GUICreate("Form1", 625, 445, 192, 124)
GUISetBkColor(0xFFFFFF,$Form1)
$Slider1 = GUICtrlCreateSlider(96, 160, 409, 49)
GUICtrlSetBkColor($Slider1,0xFFFFFF)

GUISetState(@SW_SHOW)

While 1
$nMsg = GUIGetMsg()
Switch $nMsg
Case $GUI_EVENT_CLOSE
Exit
EndSwitch
WEnd

Da deine Funktion auch verlassen werden kann ohne dass ein Array zurückgegeben wird (Zeile 5) musst du natürlich nach dem Funktionsaufruf auch prüfen ob du ein Array oder einen error von der Funktion zurückgeliefert bekommen hast. Deine msgbox Schleife darf also nur dann ausgeführt werden wenn kein error auftrat.

Func _CI_GetPrinter()
;...
If Not IsObj($objWMIService) Then Return SetError(1, 0, 0) ; verlässt die funktion ohne ein array zurückzugeben
;...
EndFunc

#include <array.au3>
$_CI_GetPrinter = _CI_GetPrinter()
if not @error then
for $i = 1 to UBound($_CI_GetPrinter)
msgbox(0,0, "Name: " & $_CI_GetPrinter[$i][0] & ", Treiber: " & $_CI_GetPrinter[$i][1] & ", Anschluss: " & $_CI_GetPrinter[$i][2])
Next
else
msgbox(0,"Fehler","WMI Objekt konnte nicht erstellt werden..")
endif

Naja so wie ich das sehe wird beim Befüllen des Arrays der Zähler x erhöht und dann erst im Array gespeichert, das heisst die Zeile 0 des Arrays wird leer bleiben und die Daten fangen erst in Zeile 1 an. Dein erster Ansatz die Ausgabe mit $i=1 anzufangen war also meiner Meinung nach korrekt, nur eben hinten beim ubound hattest du deinen Fehler.

EDIT: Name war schneller

Und was stimmt da nun nicht? Also mal davon abgesehen, dass dein Quellcode nahezu unlesbar ist dank fehlenden Einrückungen und extremster Verschachtelung funktioniert das doch im Prinzip alles.
Bei mir lässt sich das Bild problemlos bewegen, resizen und die neuen Werte werden in den flackernden Labeln angezeigt. Also so wie es sein soll.

Zitat von Hilfe

Flag = 3 oder 4 :
@Error Bedeutung
0 Array ist gültig.
1 Array ist ungültig. Keine Übereinstimmungen.
2 Falsches Suchmuster, Array ist ungültig. @Extended = Offset des Fehlers im Muster.

if @error <> 0 then msgbox(0,"Fehler","Fehlercode: " & @error & @CRLF & "Extended: " & @extended )

#include <inet.au3>
TCPStartup()
$ip = TCPNameToIP("chip.de")
$name = _TCPIpToName($ip)
TCPShutdown()
msgbox(0,"I own the internet",$ip & " ---> " & $name)

Das ging bei mir schon immer mit der 3.5 / 3.6 und nun auch mit der 4er die ich zu testzwecken hier als portable hab. An den Settings wurde nichts verändert, was in irgendeinerweise mit dem Verhalten der file inputs zusammenhängen würde. Daher hatte mich deine Aussage und die genannte Funktion überrascht (war mir neulich nämlich auch aufgefallen beim stöbern in der ffex.au3)

EDIT: Auch in der neuen 5er Version läuft das oben gepostete Script
EDIT2: Möglicherweise ist das aber auch ein Feature von MozRepl, welches mit der Zeit hinzugekommen ist, denn grundsätzlich verhindert der FF das manuelle Ausfüllen ohne Hilfsmittel

Teste mal bitte ob das Problem innerhalb von 30 Sekunden verschwindet, denn das würde bedeuten, dass er schon in der Schleife vor der WindowClass Geschichte hängen bleibt:

Local $iTimeOutTimer = TimerInit()
While 1
Sleep(2000)
If ProcessExists($sProcName) Then ExitLoop
If (TimerDiff($iTimeOutTimer) > $iTimeOut) Then
SetError(__FFError($sFuncName, $_FF_ERROR_Timeout, "Browser process not exists: " & $sProcName))
BlockInput(0)
Return 0
EndIf
WEnd

Wenn er hier drin hängt findet er den Prozessnamen nicht. Sinnvoller wäre es hier sowieso auf die Variable $PID (Prozess ID) und nicht auf den Prozessnamen zu prüfen. Vielleicht hat sich da in der 5er Version auch was geändert, oder aber der Pfad weiter oben aus der Registry wird überhaupt nicht richtig ausgelesen, dann solltest du in der Scite console aber einen Hinweis sehen.

EDIT: Der Workaround, also der Verzicht auf die _FFstart() Funktion klappt jedenfalls auch mit FF5, gerade getestet.

Braucht man keine UDF dazu, die Funktion controlgetpos() reicht völlig:

Zitat von nordx

In der _FFStartProcess() wird bereits der neue Handler ([CLASS:MozillaUIWindowClass]) verwendet.

Falsch. Die neue WindowClass ab FF Version 4 lautet "MozillaWindowClass", also ohne das "UI". Könnte höchstens sein, dass es in FF5 wieder zurückgeändert wurde, hab die 5er noch nicht angesehn, aber dann sollten ja keine Proleme auftreten.

Auch darauf gibts keine allgemeingültige Antwort. Du musst dir da schon die Herstellerseiten der Programme ansehen um herausfinden zu können ob es eine automatisierte Installationsmethode ohne User Interaktion gibt (oft als silent Parameter bezeichnet). Eine weitere Alternative zur Installation sind im übrigen auch oftmals portable Versionen (http://portableapps.com/).

Es gibt schlichtweg keine Variante um jede x-beliebige Installation zu automatisieren, das hängt immer vom Programm ab.

Ich widerspreche dir als Verantwortlichem für die ff.au3 ja nur ungern, aber auch ohne die genannte Funktion aus der ffex.au3 funktioniert das bei mir im FF ohne murren:

#include <FF.au3>

$ffProzess = Run(@ScriptDir & "\FirefoxPortable.exe", "", @SW_SHOW)
Do
_FFConnect()
$OK = @error
If @error Then _FFDisConnect()
Until Not $OK

_ffopenurl("http://www.doc2pdf.net/de/")
_FFSetValue("C:\test.docx", "inputDocument" ,"name")

Ach stimmt da war was. Die problematische Stelle befindet sich in der Funktion __FFStartProcess()
Einfach dort die Änderung vornehmen, dann sollte das klappen. Oder du benutzt die Funktion der FF.au3 erst garnicht um FF zu starten, sondern machst das so:

$ffProzess = Run(@ScriptDir & "\FirefoxPortable.exe", "", @SW_SHOW) ; ggf. hier @SW_HIDE benutzen wenn du es verstekt haben willst
Do
_FFConnect()
$OK = @error
If @error Then _FFDisConnect()
Until Not $OK

Also bei mir liefern die Makros @ipaddress 1-4 sowohl unter vista, als auch unter win2k8R2 alle IP Adressen auf, also auch mehrere pro physikalischer Netzwerkkarte. Allerdings liegt die neu hinzugefügte Adresse des 1. Controllers nun auf dem makro @ipaddress3, die Zuordnung erfolgt also vermutlich anhand der Reihenfolge wann die IPs zugewiesen wurden. Evtl würde das nach einem Neustart anders ausschaun. Logischer wäre die Makro Zuordnung jedenfalls nach Controller.

@ipadress1: 1. IP 1. Controller
@ipadress2: 1. IP 2. Controller
@ipadress3: 2. IP 1. Controller

Das Problem liegt weniger an der Auswertung der Checkbox Stati (wobei I2C hier auch die korrekte Lösung hat), sondern das Problem entsteht schon weiter oben bei der GUI Erstellung. Du verwendest für die 2. GUI die selben Variablennamen nochmals. Das hat zur Folge, dass du die Controls aus der 1. GUI überhaupt nicht mehr auswerten kannst, weil deine Variablen alle auf die Controls der 2. GUI verweisen. Wildes rumgedrücke auf der Checkbox der 1. GUI wird aber nichts am Status der Checkbox der 2. GUI bewirken, somit ist der Status immer unchecked und deine Funktion blendet dann natürlich auch nichts ein. DevFlys Lösung hat nur deshalb funktioniert, weil er das Verhalten umgedreht hat, das heisst er blendet die 2. GUI ein wenn die Checkbox nicht angehakt ist. Das ist aber denke ich nicht in deinem Sinne.

Also vergib den Variablen der 2. GUI eigene Namen und ändere die checkbox Abfrage so wie es I2C gezeigt hat, ansonsten wirst du Probleme bekommen wenn du die Checkbox ausgrauen wills, denn dann stimmen die Zahlenwerte 4 und 1 nicht mehr.

Wüsste nicht warum deine Maus hängen bleiben sollte. Die FF Funktionen haben keinerlei Einfluß auf Eingabegeräte. Wenn das also wirklich dein komplettes Script ist kann ich mir den Fehler beim besten Willen nicht erklären.
Tritt das Problem denn auch beim sichtbaren Start auf? schonmal eine 3er Version von FF getestet?

Dort solltest du alles finden was es zum Ausfüllen und Abschicken eines einfachen Formulars mit der FF.au3 zu wissen gibt: https://autoit.de/index.php?page=Thread&amp;threadID=15415

Hmm ja FF scheint sich da in der Tat etwas zu wehren. Mit Au3info kommt man jedenfalls nicht an die Controls ran, der Speichern Button wird sogar deaktiviert wenn das Fenster keinen Focus hat. Den Dialog abzuschalten wird wohl die einzig sinnvolle Lösung sein.

Klar geht das.