Beiträge von Runa

So müsste es hinhauen:

For $x = 1 To 120
	ConsoleWrite($x & " | " & ((Mod($x, 4) = 0) ? 4 : Mod($x, 4)) & " | " & Ceiling($x / 4)+1 & @CRLF)
Next

Yaerox: Dein Code gibt nicht einmal die Tabelle oben aus - die erste Spalte stimmt bei dir nicht

Ohne die Seite schwierig zu sagen... gib uns bitte Mal ein bisschen mehr "Input" - ersetze deine Zeile 4 durch folgendes:

Local $oIE = _IECreate("https://XXX.com/itim/console/main")
Local $error = @error
Local $extended = @extended
ConsoleWrite("@error creating webpage: " & $error & @CRLF)
ConsoleWrite("@extended creating webpage: " & $extended & @CRLF)

Dann postest du uns bitte den Output deiner Konsole - damit hätten wir wenigstens die genauen Fehlercodes und der Fehler ist leichter zu finden, wenn man schon ohne die Webseite arbeiten muss.

Yaerox:

Leider geht das Au3Check so unsinnig vor. Kannte bisher Forcedef auch nicht. Das werde ich nun eventuell auch verwenden.

Faktisch arbeite ich schon mit mehreren zusammen. Teilweise mit über 15 Jahren Erfahrung. Die gewöhnen sich derzeit eher mein System an statt das sie sich darüber aufzuregen. Das System funktioniert einwandfrei und sicher. Auch wenn es darum geht CRM-Systeme oder gar Finanzverwaltungen zu programmieren - mit Kundenverwaltung, Kreditverwaltung und so weiter.

Für mich persönlich ist es das beste System. Und ich kenne keines was so simpel so viel Arbeit erspart. Ja - man kann auch Regionen verwenden im Programm. Verliert damit aber mehrere Vorteile dadurch dass es eben alles in einer Datei ist statt jede Region in eine einzelne Datei auszulagern. Stichwort: Mehrere Programmierer.

Ich diktiere niemandem hier wie er vorgehen soll. Aber das wäre mein Weg und für mich ist er der beste. Und das wurde gefragt.

Turbo: Bisher nicht. Könnte ich aber demnächst. Bin gerade nicht zu Hause.

autoBert: Brauch ich nicht testen weil ich so einen Unfug nie machen würde.

Letztendlich muss es jeder für sich selbst entscheiden. Ich selbst programmiere auf einem sehr professionellen Level weil ich persönlich für kleine Änderungen nicht erst 90 Zeilen Code umwälzen möchte. Und ich unterscheide nicht zwischen "einmaligen" und universellen Code: für mich ist jede Funktion universell. Ihr glaubt nicht wie oft ich Funktionen in anderem Kontext noch einmal "aufwärmen" konnte schlicht weil die Vorraussetzungen sehr ähnlich waren. Drei Änderungen im Code und die Funktion ist fertig.

Ich selbst schreibe am Arbeitsplatz fast täglich Individualsoftware für Kunden die ich aufgrund meiner Arbeitsweise schnell und sicher erstellen kann. Das ist mir persönlich wichtig.

Meine Antwort wurde deaktiviert und der Post vom TE entfernt. Also: Wird wohl als "Spaßvirus" eingestuft

Vielleicht sollte man dann allerdings den kompletten Thread entfernen um Verwirrung zu vermeiden.

"Dann sieht es schön aus, ist aber trotzdem nicht ordentlich programmiert."

Lass mich mal mit einer Metapher ausdrücken, wie unsinnig die Aussage ist:

"Du hast einen Stapel Zettel, die sauber gestapelt auf deinem Schreibtisch liegen. Du sortierst diese Zettel in einzelne Fächer auf dem Schreibtisch, damit du die entsprechenden Teile schneller findest. Einen Teil davon lässt du direkt auf dem Schreibtisch liegen. Als Deckblatt des Stapels direkt auf den Schreibtisch verwendest du ein Blatt, auf dem du mit roter Schrift in Schriftgröße 72 schreibst: 'REST IST IN DEN FÄCHERN!!!' Aus welchem Grund auch immer hast du dir einen grenzdebilen Hilfsarbeiter geholt, der dir nun einen dieser Zettel holen soll. Du sagst ihm, dass der Zettel auf dem Schreibtisch liegt. Er guckt nur den Stapel direkt auf dem Schreibtisch durch. Er kommt zu dir und sagt, dass der Zettel nicht da ist. Du weißt aber, dass er da ist, dass er nur in einem Fach liegt. Also ignorierst du den Hilfsarbeiter, denn obwohl er dir in vielen Fällen helfen kann, ist er einfach nicht intelligent genug, um logische Zusammenhänge zu kapieren."

Genau das ist das Vorgehen der AU3-Check. Sie kapiert logische Zusammenhänge zwischen den Includes nicht. Sie kapiert nicht, dass GUI-Variablen immer im globalen Scope sind und zeigt diese als Fehler an.

Wie strukturiert ihr Anwendungen mit grafischer Oberfläche?

Ich bin ein C#-Kindchen. Ich habe für jeden eindeutigen Teilbereich ein eigenes Script:
Eine für die GUI, eine für die Optionen und globale Variablen, eine für die Verschlüsselung, eine für GUI Funktionen, eine für Fremdfunktionen, ..., und eine, in der die Hauptschleife (ohne eigene Funktionen) liegt, zusätzlich zu den Includes.

Das Minimalbeispiel bedeutet, dass ich dann folgende Scripts minimum habe:

• Includes und Hauptschleife
• Optionen und Globale Variablen
• GUI
• GUI Funktionen

Schreibt ihr alles in ein Skript?

Bei mir ist das letzte Mal über 2 Jahre her, dass ich so einen Unfug gemacht habe. Finde da mal den Fehler in angemessener Zeit...

Gliedert ihr Funktionen in andere Dateien aus?

Ja.

Wenn ja warum?

• Übersichtlicher
• leichter zu warten
• allgemeiner
• professioneller
• Code wird schlanker
• Mehrere können gleichzeitig am Programm arbeiten
• Script ist schneller in den Arbeitsspeicher geladen (wichtig bei sehr großen Projekten)

Wie greift ihr dann auf die Controls zu?

Die Controls sind bereits im Global Scope. Ich verwende sie also einfach, wie ich sie verwenden würde, wenn sie im Hauptscript wären. Dabei verwende ich AU3-Check nicht, weil die zu fehleranfällig ist und ohnehin meist nur unnütze Fehler- und Warnmeldungen bringt. Ich weiß in der Regel auch ohne diese "tollen" Fehlermeldungen, wo das Problem liegt, wenn eines auftaucht. Sollte das mal nicht der Fall sein, kann ich das Ding immer noch einschalten.

Du sagst, du willst möglichst optimiert und "qualitativ" programmieren. In dem Fall solltest du

• die AU3-Check als das verwenden, was sie ist: Ein einfaches Hilfsprogramm, dass dir potentielle Fehler anzeigt - mehr nicht
• dir Refactoring angewöhnen
• sauber programmieren
• wiederkehrende Programmteile wieder in einzelne Funktionen ablegen
• Den Quellcode "schlank" halten

Solltest du an Punkt 1 weiterhin scheitern, so hast du mehrere Möglichkeiten:

• Programmiere unoptimiert in einer einzigen AU3 und vermeide damit alle AU3-Check - Fehlinterpretationen
• Programmiere schlampig in dem du durch Redundanzen die AU3-Check-Fehler beseitigst (BSP: Variablen in allen Includes erneut definieren)
• Beachte die Fehler bloß während der Programmierung. Im Regelfall sollte das keine all zu lange Zeit in Anspruch nehmen. Für die Produktion gibt es die Exe. Die hat keine AU3-Check
• Programmiere eine eigene AU3-Check, die solche Fehler eben nicht macht

Das Übergeben von derart vielen Variablen ist keineswegs "optimal" oder "qualitativ" - nicht einmal annähernd. Von den zwei Werten entfernst du dich dann noch weiter von dem Punkt, an dem du warst, bevor du angefangen hast, Dinge auszulagern: Deine Scripts werden deutlich größer aufgrund massenhaft redundanter Daten und der Mehrwert durch die Auslagerung der Funktionen geht komplett verloren. Dann solltest du es besser in einem Script lassen. Denn wenn jemand deinen Source sieht, und feststellt "Oh Refactoring!" um dann im nächsten Augenblick festzustellen, dass es kein Refactoring ist, sondern nur ein Redundanting, wird er bitter enttäuscht sein, und alleine das Bild, was er von dir als Programmierer hat, würde in dem Augenblick in den Keller sinken - ganz gleich, was du sonst in dem Code machst: Denn Redundanzen sind in 99,99% der Fälle ein eindeutiges Zeichen für schlampige Programmierung - und das nicht nur in AutoIt.

Dann mach es schön:

#AutoIt3Wrapper_Run_AU3Check=n

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


Local $Form1 = GUICreate("Form1", 167, 66, 192, 182)
Local $Input1 = GUICtrlCreateInput("Input1", 8, 8, 121, 21)
GUISetState(@SW_SHOW)


_Example()


Func _Example()
	While 1
		$nMsg = GUIGetMsg()
		Switch $nMsg
			Case $GUI_EVENT_CLOSE
				Exit
			Case $Input1
				Exit
		EndSwitch
	WEnd
EndFunc

Du wirst feststellen, dass GUI-Funktionen (die von AutoIt selbst jedenfalls) die GUI auch von Funktionen finden, selbst wenn du die GUI-Variablen explizit auf Local setzt.

Demnach ist die GUI definitiv kein Problem. Die Frage ist: Wo könntest du dadurch ein Problem bekommen? Dann kann ich dir auch sagen, was ich persönlich als "best practice" empfinde und warum. Ich persönlich betreibe gerne Refactoring in allen meinen Scripts - und ich glaube nicht, dass ich daran was ändern sollte oder werde.

Gerne kann ich dir heute Abend (etwa 2000) ein Beispielscript schreiben. Bin jetzt erst Mal an der Arbeit. Und da bin ich heute voll ausgelastet.

Edit - Schokolade - Hier ein kleines Beispiel... eben schnell hingeschmiert, daher bisschen unstrukturiert und oftmals noch verbesserungsfähig.

Erst einmal brauchen wir eine Liste der Nutzer, bei denen das Script aktuell läuft (im Beispiel mit dem Explorer - damit bekommst du dann die eingeloggten Nutzer generell):

MsgBox(64, "Userlist", UBound(_LoggedInUsers()))
Func _LoggedInUsers()
	Local $avProcProps = ProcessList("Explorer.exe")
	Local $aReturn[UBound($avProcProps)-1]
	For $i = 1 To UBound($avProcProps) - 1
		$aReturn[$i-1] = _ProcessOwner($avProcProps[$i][1])
	Next
	Return $aReturn
EndFunc
Func _ProcessOwner($pid=0,$hostname=".")
    $objWMIService = ObjGet("winmgmts://" & $hostname & "/root/cimv2")
    $colProcess = $objWMIService.ExecQuery("Select * from Win32_Process Where ProcessID ='" & $pid & "'")
    For $objProcess In $colProcess
        If $objProcess.ProcessID = $pid Then
            $usr = 0
            $objProcess.GetOwner($usr)
            Return $usr
        EndIf
    Next
EndFunc

Jetzt müssten beide Scripts in eine gemeinsame Datei schreiben (z.B. in @AppDataCommonDir), welche Idle-Time sie aktuell haben. Wie oft du diesen Wert aktualisieren lässt, hängt davon ab, wie genau die Werte für dich sein müssen. Dein Script müsste dann die Idlezeiten aller eingeloggten Nutzer aus der Datei lesen, und dann prüfen, welche dieser Idle-Zeiten die niedrigste ist. Das wäre dann die System-Idle-Zeit, die du für deinen Energiesparmodus beachten müsstest. Beispielini:

[IDLE]
UserA=213.63634
UserB=14.123

Über die Funktion "_LoggedInUsers" bekommst du einen Array, in dem alle eingeloggten User aufgeführt sind. Das kannst du dann schlicht in eine kleine Funktion umbasteln:

Func _GetIdleTime_Global()
	$aUsers = _LoggedInUsers()
	$iIdleTime = 900*60000 ;15 Stunden
	For $i = 0 To UBound($aUsers) - 1
		$iIdle_User = IniRead(@AppDataCommonDir & "\IDLE.ini", "IDLE", $aUsers[$i], $iIdleTime)
		If $iIdle_User < $iIdleTime Then $iIdleTime = $iIdle_User
	Next
	Return $iIdleTime
EndFunc

Alles was jetzt nur noch fehlt ist eine Funktion in deinem Script, dass die Idle-Time in die Ini-Datei schreibt. Diese sollte möglichst (zur Sicherheit) direkt bei Scriptstart aufgerufen werden und die IDLE-Time auf 0 setzen. Dann könntest du - beispielsweise über AdlibRegister - periodisch deine Update-Funktion aufrufen, die die Zeit in die Ini-Datei schreibt. Damit wäre der mögliche Worst-Case der mir momentan einfällt, dass die Idle-Zeit eine Ungenauigkeit bis zu deinem Update aufweist.

Beispiel:

User A ist inaktiv (gesperrter Zustand)
User B ist angemeldet, allerdings aktuell inaktiv für 20 Sekunden.
Intervall tritt ein: User A und User B schreiben die Idle-Zeit in die Ini.
Direkt danach zeigt User B wieder Aktivität.

In diesem Beispiel würde bis zum nächsten Intervall dennoch in der Ini-Datei stehen, er wäre inaktiv. Abhilfe könnte beispielsweise das Script durch einen zweiten - kürzeren - Intervall auf eine andere Funktion schaffen. Diese Funktion würde dann den zuletzt eingetragenen Idle-Wert mit dem aktuellen vergleichen. Ist der aktuelle kleiner, würde das Ergebnis damit schneller in der Ini-Datei landen.

Ich hoffe, das Kurzbeispiel reicht bis heute Abend aus. Weiß nicht wann ich zu Hause bin.

@autoBert eigentlich das zuerst gestartete. Denn das würde ohne Kommunikation eher davon überzeugt sein es müsse in den Energiesparmodus schalten da das zuletzt gestartete ja in dem Benutzerkontext des Nutzers läuft der gerade aktiv ist.

Des Weiteren habe ich es nicht als Energieoptionen verstanden sondern als den Betriebsystemmodus - früher Standby genannt. Faktisch muss das Script auf allen Profilen laufen und die kleinste Idle-Time ermitteln.

Nicht ganz nutzerunabhängig aber dürfte dein Problem lösen:

Statt das Script in den Autostart eines Nutzers zu schieben könntest du es in den HKLM Schlüssel dafür schieben. (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run)

Das Hindernis bleibt nur noch eine wie auch immer geartete Kommunikation zwischen den Scripts. Beispielsweise über Dateien oder Registry.

Anregungen evtl auch hier: Feststellen ob ein Anwender angemeldet ist

Ausführlicher gerne wenn ich am Rechner bin.

@water er hat die UDF kaputt gemacht. Siehe Edit 2 meines Posts

In deiner Fehlerbeschreibung hast du vergessen den eigentlichen Fehler mit rein zu kopieren.
Ohne den ist es allerdings nahezu unmöglich dir das Problem des Scripts zu nennen.

Hier Möglichkeiten für Fehler, die exakt so angezeigt werden könnten:

Error: Variable must be of type "Object".
Error: $objEmail: undeclared global variable

Und beide Fehler haben vollkommen unterschiedliche Problematiken dahinterstehen. Bei ersterem könnte es hunderte verschiedene Gründe haben, weshalb AutoIt nicht auf das Objekt zugreifen kann. Es könnte nicht erstellt worden sein, es kann wieder zerstört worden sein, es könnte der Zugriff verweigert werden, ... es könnte auch schlicht die Methode nicht für das Objekt bekannt sein. Auch könnte es sein, dass der Methodenaufruf faul ist.

Du merkst:

Deine Fehlermeldung lässt sich ohne die genaue Fehlermeldung, mit dem sich das Problem nachstellen lässt nicht analysieren oder nachvollziehen, daher wird dir auch keiner so wirklich helfen können.

EDIT: Ich bin blind - Script übersehen ...

"C:\Users\SAL\Desktop\Test.au3" (66) : ==> The requested action with this object has failed.:
$objEmail.Send
$objEmail^ ERROR

Oder anders: Die Mail kann nicht versendet werden.

EDIT2:

Das Problem ist gelöst, wenn du die UDF so verwendest, wie sie war, bevor du darin herumgepfuscht hast.
Heißt: Zeile 45 hast du aus der 2 einfach eine 0 gemacht. Damit nutzt dein Script keine Authentifizierungsmethode (nicht im Schema enthalten) und dein Script scheitert daran.

Des Weiteren bitte ich dich solches Verhalten in der Shoutbox in Zukunft zu unterlassen, da ich mich sonst gezwungen sehe, die Lösung weiter hinauszuzögern oder zu verweigern:

• ArtOne Vor 30 MinutenBITTE UM HILFE!
• ArtOne Vor 30 MinutenBITTE UM HILFE!
• ArtOne Vor 29 MinutenSMTP

Sieht so aus, als soll dein Script durchgehend die Maus nach 0,0 bewegen...

HotKeySet ("{F1}", "_anschalten")
HotKeySet ("{F2}", "_ausschalten")
Global $aktiv = False


While Sleep(100)
    While $aktiv
        Mousemove (0,0)
    WEnd
WEnd


Func _anschalten()
    $aktiv = True
EndFunc


Func _ausschalten()
    $aktiv = False
EndFunc

#include <Array.au3>
Func _GetProcessListByPart($sPart)
	$aProc = ProcessList()
	For $i = UBound($aProc) - 1 To 0 Step -1
		If Not StringInStr($aProc[$i][0], $sPart) Then
			_ArrayDelete($aProc, $i)
		Else
			ConsoleWrite($aProc[$i][0] & @CRLF)
		EndIf
	Next
	Return $aProc
EndFunc
_ArrayDisplay(_GetProcessListByPart("Fire"))

Diese Variante funktioniert für alles, wo du prüfen willst, ob "Fire" enthalten ist. Mit einer kleinen Modifikation in Zeile 6 kannst du prüfen, ob es mit einem Wert beginnt:

If Not StringLeft($aProc[$i][0], StringLen($sPart)) = sPart Then

Beide Varianten sind darauf ausgelegt, dass es mehrere Prozesse mit diesem Namen geben *könnte*. Gibt es nur einen, landet der - logischerweise - in dem RückgabeArray[0][0] bzw. seine ProzessID in RückgabeArray[0][1]...

Zitat von kunigunde

Da es ab und an missverstanden wird, hier der obligatorische Hinweis:

Es handelt sich hierbei nicht um die Aussage das ich deine Anregungen nicht gut finde, sondern lediglich darum erklären zu wollen das dies in meinem Fall nicht benötigt wird.

Dein Humor gefällt mir!

War auch nur, falls du es hättest erweitern wollen

So ein ähnliches Script hab ich mir auch mal gebastelt - das Script hier hat noch Potential. Daher hier ein paar Hinweise, was aus meiner Sicht noch fehlt und hinzugefügt werden könnte:

• Dein Script unterstützt nur die 24er-Subnetzmaske (255.255.255.0) - nicht selten wird aber eine andere verwendet (z.B. das 21er-Netz [255.255.248.0])
• Dein Script bietet nicht die (evtl. optionale) Möglichkeit die "gefundene" IP-Adresse aufzulösen. Für die meisten Einsatzzwecke eines IP-Scanners (finden von Geräten im DHCP-Bereich, ...) ergeben sich hierdurch dann gewisse Schwierigkeiten, dass Gerät schnell zu finden.
• Außer dem eigentlichen "Ping" hast du keine weiteren "Features" hineingebastelt. Kurzum: Wofür suchst du die IP-Adressen eigentlich? Wolltest du sie dir nur mal angucken? Willst du sie exportieren? (Dann fehlt der Export...) Willst du die Weboberfläche aufrufen (sofern vorhanden)? (Dann fehlt diese Möglichkeit) Du weißt, worauf ich hier hinaus will?
• Die Geschwindigkeit des Scripts könnte sich optimieren lassen - beispielsweise über die Nutzung mehrerer Prozessoren. Hierzu gab es mal einen Thread, wie man das bewerkstelligen könnte (Hauptprozess der die eigentlichen Aufgaben auf Child-Prozesse verlegt, um alle CPU-Kerne auszulasten, nach Abschluss werden alle Child-Prozesse geschlossen) - auf Wunsch suche ich gerne noch einmal danach (da ging es meines Wissens um MD5-Schlüssel).

Da es ab und an missverstanden wird, hier der obligatorische Hinweis:
Es handelt sich hierbei nicht um Kritik, sondern lediglich um ein paar Anregungen, wie man das Script noch erweitern und verbessern könnte.

Kurz und knapp: Ja.

Faktisch musst du nur rausfinden welche Parameter das Programm erwartet wenn es eine Datei öffnen soll.

Am simpelsten findest du das - bei korrekt installierten Programmen - über deren Registrierungsschlüssel unter Shell Open.

In 9 von 10 Fällen ist dies aber einfach nur der Dateiname als Parameter. Ab und an noch ein -o oder -Open aber viel Variation gibt es da nicht.

#include <ButtonConstants.au3>
#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
$GUI = GUICreate("GUI", 396, 116, 192, 114)
$in_file = GUICtrlCreateInput("", 8, 8, 377, 21)
$rb_note = GUICtrlCreateRadio("Öffnen mit Notepad", 8, 40, 113, 17)
GUICtrlSetState(-1, $GUI_CHECKED)
$rb_word = GUICtrlCreateRadio("Öffnen mit Wordpad", 8, 56, 113, 17)
$open = GUICtrlCreateButton("Öffnen", 8, 80, 115, 25)
GUISetState(@SW_SHOW)
While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $open
			$file = GUICtrlRead($in_file)
			If $file <> "" Then
				If GUICtrlRead($rb_word) = 1 Then
					ShellExecute("wordpad", GUICtrlRead($in_file))
				ElseIf GUICtrlRead($rb_note) = 1 Then
					ShellExecute("notepad", GUICtrlRead($in_file))
				EndIf
			EndIf
		Case $GUI_EVENT_CLOSE
			Exit
	EndSwitch
WEnd

Hier mal dein Beispiel angepasst.

BTW: Notepad und Editor sind exakt das gleiche Programm... Daher mal frech deinen Editor zu einem Wordpad gemacht. Alternativ hätte ich auch Notepad++ nehmen können, aber das Prinzip bleibt das gleiche.

Jup, gerade gesehen, Zeile 25 hatte ich nicht angepasst. Das wäre die einzige Stelle gewesen, die du hättest anpassen müssen, aber dein angepasstes Script stimmt dann natürlich auch.