Beiträge von BugFix

Hi,
ich habe mir ein SIP-Telefon von Linksys, WIP330-EU, zugelegt.
Nur leider bekomme ich das Teil nicht dazu, mit meinem SIP-Provider zu connecten.
Der Support des Herstellers hält sich bedeckt und verweist auf den Händler, welcher sich ebenfalls als nicht zuständig erklärt und auf den Hersteller verweist (Ich liebe die Servicewüste Deutschland *kotz*).
Natürlich könnte ich das Teil jetzt zurückschicken, aber ich will es ja haben.

Die Verbindung mit dem WLAN funktioniert tadellos und ist auch einfach zu konfigurieren.
Anders bei den SIP-Einstellungen. Hier werden gleich 3 verschiedene Proxy-IP plus Port abgefragt.
Im Allgemeinen erhält man von seinem Provider einen oder zwei Proxy.
Mein Provider ist 1und1 und der bietet einen sip und einen stun Server.
In der Konfiguration stehen zur Auswahl:
- Proxy
- Register Proxy
- Outbound Proxy
Laut 1und1 ist der sip-Server der Register Proxy. Aber wohin mit dem stun-Server?
Ein weiterer Parameter ist der RTP Port. Ich hab keine Ahnung wozu der dient und welchen Port ich dort eintragen muß (Dank des fabelhaften Supports werde ich es wohl auch nicht erfahren).

Falls also irgendjemand mir hier weiterhelfen kann, wäre ich ganz happy :).

EDIT
Also ich kenne inzwischen alle VoIP-Foren im In- und Ausland.
Resultat: Dieses Gerät läßt sich nicht mit meinem SIP-Provider ein.
Ergo tritt es nun doch den Rückweg zum Händler an und ich muß mir doch irgendein dösiges DECT-Telefon zulegen.

AspirinJunkie
Da hast du natürlich vollkommen recht. Da ich aber die Angst vieler User vor Arrays kenne, habe ich es dieses mal nicht erwähnt.
Aber gerade bei vielen Controls wäre das die bessere Alternative (oder auch ObjectDictionary :P)

Irgendeine Fehlermeldung?

Übrigens, erspare dir etwas Schreibarbeit :).
Packe die Aktionen bei Case $Button6 in eine Schleife:

Also zum Auslesen von Checkboxen (oder Radio-Button) sollte man doch die AutoIt-Syntax einhalten.

If GUICtrlRead($Control) = $GUI_CHECKED / $GUI_UNCHECKED Then

Eine andere Möglichkeit wäre noch:

If BitAnd(GUICtrlRead($Control), $GUI_CHECKED) Then

Diese Variante

Case $Button1
If GuictrlRead($Checkbox1)=1 then Run("Adobe Rader 8.1.exe")
If GuictrlRead($Checkbox2)=1 then Run("AnyDVD.exe")
If GuictrlRead($Checkbox3)=1 then Run("ATI.exe")
If GuictrlRead($Checkbox4)=1 then Run("autoit.exe")

hat den Nachteil, dass bei mehreren angehakten Checkboxen versucht wird die Installationen gleichzeitig zu starten.
Hier sollte RunWait oder ShellExecuteWait verwendet werden, damit alles nacheinander abgearbeitet wird.

Zitat

das es diesen dann in den Ring 0 verfrachtet ?

Meines Wissens ist es nicht möglich separat anzuweisen, auf welcher Ebene AutoIt-Skript implementiert wird. Wenn du so tief ins System eintauchst, solltest du auch eine systemnahe Sprache und keine Skriptsprache verwenden. Wie wärs mit Assembler ?

Was hast du denn "böses" vor, dass du eine neue WAN-IP brauchst?

Was blinkt denn da bei dir?? - Wohl die Weinachtsbaumbeleuchtung.
Hier mal ein ganz simples Beispiel:

DLL mit runtergeladen und registriert?

Für alle betroffenen Controls mußt du analog vorgehen.

Ich hab mal ein bischen probiert.
Am besten du "kettest" den Button an die Position des Listview.
Also Button_X = neuLV_X + neuLV_Höhe + gewünschter Abstand.
Einfach direkt im Anschluß an die Resize-Funktion ausführen.

Das Problem ist, dass wir einen Mix aus StandardResizing und der neuen Resizing-Funktion haben. Im Standard hast du Dock-Funktionalität, die ich hier nicht anbieten kann.
Du kanst aber versuchen für den Button die Option GUICtrlResize in Bezug auf das ListView zu setzen. Vielleicht klappt das.

Naja, ist ja alles Geschmackssache, aber ich kann diesen ganzen Überblendungen und Transparenzen keinen Nutzen abgewinnen. Und von der Optik her verursacht es auch eher ein Chaos, als dass es die Arbeit unterstützt.
Aber irgendwie muß der User ja gezwungen werden unbedingte noch mehr Speicher und schnellere Hardware zu verbauen. Also werden sinnlos speicherfressende Programmoberflächen erzeugt.

german-bash ==> school-bash

Hi,
wie schon einige leidvoll bemerkt haben, funktionieren in den neuen Funktionen die Standardroutinen von AutoIt nicht mehr.
Somit muß man hier eigene Funktionen erstellen, die diese Funktionalität wiederherstellen.
Ich habe jetzt die Funktion
_ResizeCtrl($hWnd, $hCtrl, $aSzWnd, $aSzCtrl) erstellt.
• $hWnd - Handle/ID des Fensters
• $hCtrl - Handle/ID des Controls
• $aSzWnd - Array mit Angaben Fenstergröße [WinGetPos()] bei Erstellung
• $aSzCtrl - Array mit AngabenControlgröße [ControlGetPos()] bei Erstellung

Hiermit wird Größe und Position des Controls bei Größenänderung der GUI angepaßt.
Ich habe mich nur auf die Basisfunktion beschränkt, wer mag kann ja gerne noch um die verschiedenen Dock-Varianten erweitern.
Auslöser für dir Funktion ist das Ereignis $GUI_EVENT_RESIZED.
Da die Größenänderung/Positionierung im Verhältnis zu den Parametern der Controlerstellung steht, müssen sowohl Fenster- als auch Controlgrößenangaben an die Funktion übergeben werden.
Dazu einfach WinGetPos() und ControlGetPos() verwenden, dann sind die Angaben auch gleich im passenden Format.
Bei Verwendung von GUIGetMsg() muß dann nur abgefragt werden ob $msg = $GUI_EVENT_RESIZED und dann kann die Funktion mit den Parametern aufgerufen werden.
Im OnEvent-Mode ist für das Ereignis eine parameterlose Funktion anzugeben, die dann ihrerseits _ResizeCtrl() mit Parametern aufruft - Grund: An mit OnEvent ausgelöste Funktionen können keine Parameter übergeben werden.

Hier mal mit einem Bsp.: Standard-Combo vs. _GUICtrlComboBoxEx_Create und _GUICtrlListView_Create

0815

Ich hatte das Problem in das Bug-Forum des engl. AutoIt-Forums gestellt.
Lapidare Antwort:

Zitat

Es ist völlig offensichtlich, du nutzt nicht die grundlegenden Funktionen von AutoIt und somit sind die grundlegenden Funktionalitäten von AutoIt nicht wirksam. Das ist KEIN BUG.

Na SUPER - willst du erweiterte Funktionalität nutzen (oder mußt du, weil die alte weg ist!!), sind die grundlegenden AutoIt-Funktionen eingeschränkt.
Also ich bin einfach nur stinksauer. Ich kann mich ja der Versionsfortschreibung nicht entziehen! Wenn ich meine Skripte weiter unter der 3.2.9-er Version schreibe, sind sie für andere wertlos.
Hier findet leider eine Entwicklung in AutoIt statt, die so sicher (von den meisten) nie gewollt war und irgendwann AutoIt ebenso kompliziert macht, wie eine Hochsprache.
Pessimistischerweise würde ich sagen, das ist der Anfang vom Ende. Aber der Optimist in mir ist noch nicht gestorben.

Carsten8:
Ich werde jetzt eine Resizing-Funktion schreiben, die dieses Problem beseitigt.
Der Nachteil wird sein: Ich nutze dazu das Resizing-Ereignis. Das wird erst wirksam, nachdem (und nicht während) ein Fenster aufgezogen/zusammengeschoben wird. Somit "springt" das Steuerelement erst am Ende der Aktion in die neue Position, optisch unschön.

Edit:
So, die Funktion ist erstellt. Zu finden hier: Resizing bei Nicht-Standard-Controls, z.B. _GUICtrlListView_Create

ich ==> King

Im Allgemeinen (zumindest bei den alten Funktionen :P) mit
GUICtrlSetResizing($Control, $GUI_DOCKAUTO) ==> DOCKAUTO paßt die Größe automatisch an, andere Varianten s. Hilfe zur Funktion.
Die GUI benötigt als Style: $WS_SIZEBOX und $WS_SYSMENU

Beim Reviewen ist mir aufgefallen, dass in den Beispielskripten auch übersetzt wird.
Bitte beschränkt euch dabei AUSSCHLIESSLICH auf Titel !!
Sonst lauft ihr Gefahr, dass die Bsp. nicht mehr funktionieren.
Es war z.B. für eine IE - Funktion der Parameter "textExample" übersetzt worden. Aber damit konnte die Funktion nichts mehr anfangen.

In diesem Sinne noch viel Spaß beim Übersetzen.

Schau bitte mal in die Suche. Zu diesem Thema hatten wir schon min. 1 Thread - weiß ich sicher, da ich dort was von getestet hatte.