Beiträge von misterspeed

Naja ich will es generell zentriert haben unabhängig von der Schriftgröße und Inputhöhe. Deine Lösung ist lediglich "hingemurkst" und schaut halbwegs zentriert aus (19 wäre eher passend, wenn man es so lösen mag...).

Irgendwie mag das gerade nicht so recht klappen, vielleicht weiß ja jemand von euch wie ich den Text in den Input controls vertikal zentriert bekomme, genauso wie links daneben in den Label controls.

BugFix :

Deine Links sind mit irgendeinem Chrome-Extension Kram verunstaltet

Genau für solche Dinge wurde Autoit ursprünglich entwickelt würde ich sagen.

Alternativen zu Autoit gibt es natürlich ebenfalls jedemenge. Jenachdem welche Schnittstellen die Programme bereitstellen genügt vielleicht auch eine simple Batchdatei oder du verwendest VBS oder powershell. Autoit ist aber recht einfach zu lernen und bietet dir eine sehr gute und leicht verständliche Hilfe, Supportforen und Tutorials, so dass man auch als Programmieranfänger recht schnell zum Erfolg kommt.

Zitat von SgtIgram

dann hast du nen fehler gemacht beim includen der sqlite3 dll au3

Wie soll man dabei einen Fehler machen? Das Problem wird mit fehlenden Administrator Rechten bzw. der Benutzerkontensteuerung unter Windows 7 zusammenhängen, denn die sqlite.au3 versucht die dll, welche binär in der sqlite.dll.au3 vorliegt ins Systemdir zu extrahieren, sofern keine neuere SQLite Version dort oder andernorts vorgefunden wird:

If $fUseInline Then
$sDll_Filename = @SystemDir & "" & $sDll_Filename

Ein #Requireadmin würde vermutlich ausreichen. Da es aber vielleicht nicht immer praktikabel ist Adminrechte anzufordern ist es ohnehin die sauberere Lösung die DLL im Scriptverzeichnis mitzuliefern. Fileinstall könnte hierbei behilflich sein, wenn man die DLL nicht separat mitliefern will.

Zitat von chrisbyRRC

Hmm... das klingt ja gar nicht gut...

Das mit dem Sicherheitsabfrage im 2.ten Programm kann und werde ich auch durchführen nur wirkt AutoIt irgendwie mal gar nicht sicher.
Ich denke ich kann mir dann fast meine zweite Sicherheitsfrage schenken, aber dennoch vllt. irre ich ja:

In einiger Zeit möchte ich ein Programm schreiben mit denen es Anwendern möglich sein soll kleine 1-3MB große Dateien auf einen Server hochladen zu können wo diese dann weiterverarbeitet werden. Nun gehts wieder los => um eine FTP-Verbindung aufbauen zu können muss ich ja die Zugangsdaten zum Server ins Script schreiben.  


Jemand ne Idee oder ist es hoffnungslos solche Programme mit AutoIt zu schreiben?  

Das hat wenig mit Autoit zu tun. Egal mit welcher Sprache du programmierst, es wird immer möglich sein Reverse Engineering zu betreiben. Zugangsdaten haben deswegen auch niemals etwas im Quellcode zu suchen. Das würde ohnehin Probleme bereiten wenn du aus welchen Gründen auch immer dazu gezwungen wirst die Zugangsdaten zu ändern.

Ein Ansatz wäre es die Zugangsdaten separat zu verwalten und am besten für jeden Anwender eigene Daten zu vergeben. Diese könnten z.B. per Email weitergegeben werden. Der Anwender hinterlegt diese dann bei sich lokal in einer verschlüsselten ini Datei. Das minimiert das Risiko, dass dritte die Zugangsdaten erhalten. Wenn du auf Nummer sicher gehen willst verzichte komplett auf die Speicherung beim Anwender, dann muss er die Daten aber jedesmal eintippen.

Vorteil: Du kannst einzelne Anwender jederzeit am Server sperren, sollte es zu Mißbrauch der zugehörigen Daten kommen.
Nachteil: Je nach Nutzeranzahl hoher Verwaltungsaufwand.

Nein ist wol die einzige Antwort. Du kannst schlichtweg nicht die Festplatte nutzen wenn die Datei nicht kopiert werden soll. Selbst wenn du es schaffen solltest diverse Fileattribute zu nutzen oder Windows global so zu manipulieren, dass Kopieroperationen kurzfrisitg nicht möglich sind, so wird die Methode sehr sicher keiner VM standhalten die einfach eingefroren wird sobald die exe entpackt wurde. Die Datei unsichtbar machen ist jedenfalls ein viel zu primitiver Ansatz. Wenn die integrierte exe selbst programmiet wurde würde ich dort ansetzen und entsprechende Prüfungen einbauen, die sicherstellen, dass der Parentprozess zur Ausführung berechtigt ist und natürlich auch während der Ausführung aktiv ist. Wenn es sich nicht um deine Software handelt hast du wohl Pech gehabt, da verstehe ich dann aber auch nicht so recht mit welchem Recht du diese Software einsetzt und warum diese vor dem Anwender versteckt werden muss.

Deine Schwachstelle ist sowieso das Autoitscript. Es gibt genügend dekompiler mit deren Hilfe es dann ein leichtes wäre die pw geschützte rar Datei zu entpacken, weil nach dem Dekompilen sehr sicher dein PW der rar Datei sichtbar wird.

Ich halte es für möglich, dass der Benutzer keine ausreichenden Berechtigungen hat um die Datei zu lesen. Der eigentliche Fehler liegt aber an mangelhaftem Errorhandling in deinem Code, denn sonst könnte es garnicht zum Absturz kommen, sondern dein Programm würde stattdessen eine detailierte Ausgabe machen was an welcher Stelle nicht geklappt hat und entweder angemessen reagieren, den Anwender fragen oder eben das Programm sauber beenden.

Um den Fehler zu finden bleibt dir nichts anderes übrig als nach jedem Funktionsaufruf die Rückgabewerte und sofern vorhanden Errorcodes auszuwerten. Details was eine Funktion im Fehlerfall zurückgibt werden im jeweiligen Hilfeeintrag beschrieben.

Kurzes Beispiel wie das ausschaun könnte bzw.immer sollte:

#include <File.au3>
$filepath = "C:\test.txt"
dim $adata
$debug = _filereadtoarray($filepath,$aData)
if $debug = 0 then
msgbox(0,"Fehler beim Datei einlesen","Errorcode: " & @error)
exit ; pech hat nicht geklappt, also abbrechen
else ; alles ok
if ubound($adata) >= 3 then
consolewrite($adata[2] & @crlf) ; alles ok, irgendwas mit Zeile 2 machen
else ; pech Zeile 2 gibts garnicht
msgbox(0,"Fehler","Die Textdatei enthält weniger als 2 Zeilen, daher abbruch")
exit
endif
endif

Das klassische Echo, welches man von Batch Dateien kennt kannst du z.b. durch

consolewrite

erzeugen. Davon siehst du aber nur etwas, wenn dein Script als Konsolenanwendung (CUI) kompiliert wurde oder als au3 im Scite Editor ausgeführt wird. Andernfalls kannst du natürlich auch einfach eine msgbox zur Ausgabe nutzen:

msgbox

Weiteren Methoden sind keine Grenzen gesetzt, eigene GUI, Traytips, Emailversand, Ereignisprotokoll usw.

Zitat von reeky

Wie kann ich diesen Befehlen den Dialog zu meinem Ordner navigieren und dann alle Dateien auswählen?

Du brauchst normalerweise nirgendwo hin navigieren. Es reicht wenn du im Öffnen Dialog einfach den vollen Pfad unten in das Feld des Dateinamens mit controlsettext setzt und dann mit controlclick auf "OK" bestätigst.

Was winhttp anbelangt benötigst du wie bereits richtig erkannt ein Browserplugin um den Aufbau des HTTP Posts mitzuschneiden. Diese Informationen kannst du dann verwenden um z.B. die Funktion winhttpsimpleformfill anzuwenden. Soweit ich mich erinnere findest du in der winhttp Hilfedatei auch Beispiele zu den Funktionen. Aber ich gebe zu, dass die winhttp.au3 Methode natürlich etwas mehr Einarbeitungszeit erfordert, dafür aber dann auch zuverlässige und performante Ergebnisse liefert. Ob es da gute Tutorials gibt weiß ich nicht, ich hab mir das damals nur anhand der Hilfe und ausgiebigem Testen bzw. einigen Beispielcodes aus dem englischen Forum beigebracht.

1. Ebay besitzt eine API, siehe dazu den Developer Bereich von Ebay.
2. Wenn man schon nicht die API verwenden mag gibt es noch zig andere Methoden um Webseiten zuverlässig zu automatisieren, schau dir dazu die winhttp.au3, die ff.au3 oder die bereits in Autoit vorhandenen Funktionen für den Internet Explorer an.
3. Send oder auch controlsend ist ohnehin nicht sehr zuverlässig, verwende lieber

controlsettext
controlclick
controlcommand

Zitat von AyKay

Hi Bowser,
PS: Und wieso nochmal verwendest du nicht ControlSend?

Vermutlich deswegen:

Zitat

Da AutoIt Window Info in MPLAB X leider keine Controls erkennen kann, muss ich immer mit Tastaturbefehlen zu den jeweiligen Optionen navigieren.

Da die Software aber eine IDE für Entwickler ist würde es mich schon sehr enttäuschen, wenn der Weg über eine GUI der einzige wäre um compiler oder Plugins hinzuzufügen. Ich würde daher mal die Dokumentation absuchen ob sowas auch durch kopieren von Dateien in dafür gedachte Verzeichnisse und ändern von config files der IDE machbar ist. Alternativ gibt es vielleicht auch ein cmdline Tool der IDE für diese Aufgabe. Im Zweifelsfall würde ich den Hersteller befragen ob es alternative Wege gibt bzw. was genau der dafür gedachte Wizzard eigentlich alles tut.

Zitat von masterplc

Naja das Problem mit RunAs ist das dafür das Userpasswort erfordert wird und ausserdem der Nutzername.Das Skript soll ja auch auf anderen PCs laufen können ohne das ich den Nutzernamen weiß oder das der Nutzer das PW einem Programm geben muss das ohne jegliche Probleme das PW übermitteln könnte und sich dann selbst schrottet.Also ich würde nem Programm net so einfach über den Weg trauen.Es muss doch universell möglich sein zur Laufzeit Adminrechte zu erfragen oder eine Batch oder whatever mit Adminrechten zu starten oder?

Ja was denn nun? Du hast (zu Recht) Bedenken bzw. Probleme damit einem Programm das du nicht kennst Accountdaten anzuvertrauen, damit es die Rechte bekommt die es nunmal braucht (oder gerne hätte...), aber andererseits wünscht du dir Programme die ohne die Interaktion mit dem Anwender (nach Erlaubnis / PW fragen...) einfach mal so Administrator Rechte erlangen können. Das widerspricht sich doch, meinst du nicht?

UAC wurde eben genau deshalb eingeführt, damit nicht mehr jeder Hobbyprogrammierer volle Administratorrechte auf fremden Systemen erlangen kann. Wenn dir das nicht gefällt kannst du UAC auch abschalten und wieder wie zu XP Zeiten jeder Malware Tür und Tor öffnen.

Wie schon erwähnt bleibt dir "#requireadmin" um die UAC Abfrage zu starten und dadurch jedesmal bei Programmstart nach Erlaubnis zu fragen oder aber du fragst einmal nach Administrator Daten speicherst diese irgendwo verschlüsselt (z.B. in einer ini) und verwendest sie für alle zukünftigen Programmstarts in deinen runas Aufrufen. Alternativ muss UAC eben auf dem System deaktiviert werden oder zumindestens eine Ausnahme für dein Programm eingerichtet werden, aber auch dafür brauchst du einmalig Administratorrechte, welche du erstmal erfragen musst.

Deine Einstellung erlaubt dir nun auf dem Rechner der die angegebene IP hat eine Serveranwendung mit Port 21 zu betreiben welche weltweit über deine öffentliche IP erreichbar ist, dein Router weis nun also wenn jemand aus dem Internet etwas auf Port 21 an dich schickt auf welchem Rechner dieser Server von dir läuft. Wenn es das war was du wolltest ist das soweit korrekt. DHCP muss man nicht zwingend im Router deaktivieren. Viele Router unterstützem auch einen DHCP Modus der anhand der MAC Adresse des Netwerkadapters immer die gleiche IP für diesen Rechner zuweist. Deaktiviertes DHCP und manuelle IP Vergabe im Netzwerk ist aber natürlich die sicherste Lösung wenn es um korrektes und fehlerfreies Portforwarding geht.

Jenachdem welchen Provider du hast wirst du aber noch das Problem haben, dass deine öffentliche IP Adresse alle 24h geändert wird, du musst also sicherstellen, dass die anderen da draussen im Internet immer deine aktuelle öffentliche IP Adresse kennen. Dafür gibt es Dienste wie DynDNS.org

Wenn du bei einem Kabel Provider bist ändert sich deine öffentliche IP eher selten, da ist es nicht unbedingt erforderlich solch einen Dienst zu nutzen (jenachdem wie wichtig dir die Erreichbarkeit ist).

Erstmal nochmal zur Klärung... redest du nun von Netzwerk interner Kommunikation oder wirklich von Kommunikation zwischen zwei Standorten die durch das Internet getrennt sind?

Netzwerkintern würdest du den Rechner durch seine lokale IP Adresse eindeutig identifizieren, also z.B 192.168.1.2, zusätzlich musst du die Serveranwendung auf diesem Rechner eindeutig ansprechen (Port des Servers), ein FTP Server wäre also z.B. per 192.168.1.2:21 erreichbar.

Wenn beide Geräte durch das Internet getrennt sind benötigst du die öffentliche IP über die der Rechner (und alle anderen lokalen Rechner dieses Netzes) erreichbar ist, also z.B. 85.216.8.123 (frei erfunden...) und natürlich wie oben den Port des Servers, also z.B. 85.216.8.123:21

Was passiert nun in einem herkömmlichen Heimnetzwerk?

Deine Anfrage landet an der öffentlichen IP Adresse des Routers. Dieser entscheidet nun an welchen der Rechner er deine Nachricht weiterleiten soll. Dafür wird eine Regel im Router benötigt (Portforwarding / Portweiterleitung). Anhand dieser Regel weiß dein Router auf welche lokale IP Adresse er Nachrichten mit diesem speziellen Port weiterleiten soll. Fehlt diese Regel wird er das Paket einfach verwerfen, außer es handelt sich um eine Antwort auf eine Anfrage die aus deinem lokalen Netzwerk nach Außen gestellt wurde, in diesem Fall merkt sich der Router temporär an welche lokale IP die Antworten weiterzuleiten sind (z.B. wenn du eine Webseite besuchst, die Antwort des Webservers landet immer auf dem richtigen PC in deinem Netzwerk). Letzteres ist eher uninteressant, da du ja offensichtlich keinen Client sondern einen Server betreiben willst.

Ich hoffe das hat ein wenig zum besseren Verständnis beigetragen wie eine Client-Server Kommunikation hinter einem Router zu stande kommt. Ansonsten kann ich nur dazu raten google und insbesondere wikipedia zu den Themen NAT, Portforwarding, Client Server, TCP usw. zu befragen.

Zitat von WhiteF

Ich empfehle Variante 2 - schliesst Eventualitäten aus.

Ähm nein nicht wirklich, da der Ordner recht standardmässig für mich ausschaut und somit evtl auch solch ein Ordnersymbol in einem anderen Programm gefunden werden könnte, das gerade im Vordergrund ist. Da wäre ich also ein wenig vorsichtig.
Da der Ordner aber wohl sehr wahrscheinlich für "Datei öffnen" steht gibt es vielleicht noch

Variante 3: Starte das Programm mit Parametern um die Datei zu öffnen. Viele Programme reagieren auf solche Konstrukte --> prog.exe "c:\dateipfad\datei.endung" bzw. alternativ eben die Datei im Standardprogramm öffnen per shellexecute("datei")

Je nachdem ob noch mehr als das Öffnen automatisiert werden soll ist das aber vllt dann nur die halbe Lösung.

Hilfe lesen?

_GetIp()

Zitat

Die öffentliche IP-Adresse eines Netzwerk/Computers erhalten.

Sofern du keine zwei Internetanschlüsse (oder einen Provider der dir mehrere IPs anbietet) hast werden natürlich alle Rechner in deinem lokalen Netzwerk auch die gleiche öffentliche IP Adresse haben. Wenn du hingegen die lokale IP Adresse des jeweiligen Rechners wissen willst, dann brauchst du eher das hier:

@IPaddress1

EDIT: Name22 war schneller...

Zitat

oder wie sehe ich das?

Nein, aber so in etwa. Am besten schaust du dir die Beispiele zu _filelisttoarray in der Hilfe an. Ein anschließender Blick ins Array Tutorial von Bugfix würde sicher auch nicht schaden, da du scheinbar absoluter Autoit Anfänger bist.

http://www.bug-fix.info/array_tut.htm

Oder eben gleich den Code von PainTain nehmen, aber ob du das mit dem aktuellen Wissenstand verstehst ist eben eine andere Frage. Sein Script wäre im übrigen problematisch wenn du doch mal mehr als eine msi Datei im Ordner hast und eben nicht alle installiert werden sollen.

EDIT: Sein Script ist sogar falsch, da filelisttoarray ein 1-based Array zurückgibt und in Feld 0 wo seine Schleife anfängt eben kein Dateiname zu finden ist, sondern nur die Anzahl der Treffer. Außerdem ist die Pfadangabe für shellexecute unvollständig, da filelisttoarray nur die Dateinamen und nicht den Pfad zurückgibt. Man muss sich den Pfad also zusammensetzen.

Hier die korrigierte Fassung:

#include <File.au3>
$sFS_JAVA = 'C:\DeinJavaOrdnerPfad\'
$sInstParams = "-silent"
$aFiles = _FileListToArray($sFS_JAVA, "*.msi", 1)

For $i = 1 To $aFiles[0]
ShellExecuteWait($sFS_JAVA & $aFiles[$i], $sInstParams)
Next

Hier mal mein Vorschlag, denn nur so dürften Passworte mit beliebigen Sonderzeichen fehlerfrei funktionieren. Wenn du die Variabeln nicht in Anführungszeichen einschließt besteht immer die Gefahr, dass die Parameter falsch interpretiert werden. Ich würde außerdem vermuten, dass deine Pfadangabe beim Phonebook evtl. inkorrekt ist (evtl. mal vollen statt relativen Pfad testen oder das workingdir im run Aufruf richtig festlegen, damit der relative Pfad stimmt). Grundsätzlich solltest du immer wie unten gezeigt vorgehen, erstmal den Aufruf in die console ausgeben, dann von Hand testen ob genau diese Zeile funktioniert und wenn ja kannst du den Run Aufruf wieder einkommentieren und solltest auch den stdout prüfen, da du sonst das Ergebnis bzw. die evtl. vorhandene Fehlermeldung nicht sehen kannst.

#include <Constants.au3>
$vpnconnectusername = ENVGET("USERNAME")
$vpnconnectpassword = InputBox("Passwortabfrage", "Bitte geben Sie Ihr Windows-Anmeldekennwort ein:", "", "*")

$test = 'rasdial "unserVPN" "' & $vpnconnectusername & '" "' & $vpnconnectpassword & '" /Phonebook:res\unserVPN.pbk'
ConsoleWrite($test & @CRLF)

;$debug = Run(@ComSpec & " /c " & $test, "", @SW_HIDE,$STDOUT_CHILD)
;$debug = Run(@ComSpec & " /c " & $test, @scriptdir, @SW_HIDE,$STDOUT_CHILD) ; workingdirfix????

#cs
$debugout = ""
while not @error
$debugout &= stdoutread($debug)
wend
consolewrite($debugout & @crlf)
#ce

PS: Statt envget könntest du auch das Makro @username verwenden.

Naja ich würde das so organisieren:

1. Du legst auf deinem Networkshare für die verschiedenen Programme je einen Ordner an, so wie du es ja schon hast.
2. Neue Setups kommen mit Versionsnummer in den jeweiligen Ordner, alternativ und vielleicht auch besser du benennst sie nach Hinzufügedatum, also z.B. JAVA-Setup_20130915.msi
3. Dein Installationsscript auf dem Client Rechner vermerkt in einer DB oder Textdatei welche Updates es bereits installiert hat.
4. Das Client Installationsscript muss nun zwei Dinge tun:
a) Auf deinem Networkshare nachschauen welche Version die neueste ist (letzte Datei im jeweiligen Ordner)
b) Nachschauen ob diese Version bereits in der DB als installiert vermerkt wurde, wenn nicht muss sie installiert und in der DB vermerkt werden, andernfalls ist der Client Rechner bereits "up2date" und kann das nächste Programm auf gleiche weise prüfen.

Funktionen die diesbezüglich hilfreich sein sollten

_filelisttoarray
iniread
iniwrite