Eigene Funktionen eines Tools in UDF ausgliedern?

#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.

Dann mach es schön:

#AutoIt3Wrapper_Run_AU3Check=n

Ich übergebe dann das als Funktionsparameter:

#include <EditConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include "Test2.au3"
Local $Form1 = GUICreate("Form1", 167, 96, 192, 182)
Local $Input1 = GUICtrlCreateInput("Input123", 8, 8, 121, 21)
Local $Button1 = GUICtrlCreateButton("Klick mich", 8, 30, 121, 21)
GUISetState(@SW_SHOW)
While 1
	$nMsg = GUIGetMsg()
	Switch $nMsg
		Case $GUI_EVENT_CLOSE
			Exit
		Case $Button1
			_Testfunc($Input1)
	EndSwitch
WEnd

Func _Testfunc($hInput)
	MsgBox(0, "", GUICtrlRead($hInput))
EndFunc

"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.

Zitat von Bioshade

Dann mach es schön:

#AutoIt3Wrapper_Run_AU3Check=n

Exakt für so etwas gibt es #forcedef.

Also die Funktion folgendermaßen definieren und man hat weiterhin Au3Check und keine Fehlermeldung:

Func _Testfunc()
	#forcedef $Input1
	MsgBox(0, "", GUICtrlRead($Input1))
EndFunc   ;==>_Testfunc

Ich bin überglücklich mit meiner MVC Struktur.
Evtl was für dich...

über dieses Thema haben sich schon viele Gedanken gemacht.

Für mich hat sich folgendes als praktikabel und sinnvoll etabliert.
Link: https://www.autoitscript.com/wiki/Best_coding_practices

Über die Thematik Global und Local Variablen gab es auch schon ewige Diskussionen.

Ich glaube mich zu erinnern, dass es mal ein Problem mit Globalen Variablen gab und es besser war
im gesamten Script nur Local Variablen zu verwenden.

Ich finde aber auf die Schnelle den Thread nicht...

Zitat von Bioshade

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.

Aber nur weil die Gui nicht innerhalb einer Func erzeugt und die Variablen daher im Globalen Gültigkeitsbereich deklariert wurden. Versuch mal dieses Script:

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


Example()


Func Example()
	Local $Form1 = GUICreate("Form1", 167, 96, 192, 182)
	Local $Input1 = GUICtrlCreateInput("Input123", 8, 8, 121, 21)
	Local $Button1 = GUICtrlCreateButton("Klick mich", 8, 30, 121, 21)
	GUISetState(@SW_SHOW)
	While 1
		$nMsg = GUIGetMsg()
		Switch $nMsg
			Case $GUI_EVENT_CLOSE
				Exit
			Case $Button1
				_Testfunc()				;funktioniert nicht
				;_Testfunc2($Input1)	;funktioniert
		EndSwitch
	WEnd
EndFunc   ;==>Example


Func _Testfunc()
	MsgBox(0, "", GUICtrlRead($Input1))
EndFunc   ;==>_Testfunc


Func _Testfunc2($CtrlID)
	MsgBox(0, "", GUICtrlRead($CtrlID)
EndFunc   ;==>_Testfunc2

kannstb du obige Aussage immer noch bestätigen?

Yaerox: ich versuche mittlerweile soviele Variablen wie möglich Lokal zu deklarieren und nehme Übergabeparameter in Kauf. Sicher ist es nervig 15 Parameter zu übergeben (wie in [Beispiel] FTP-Downloader (rekursive Download's ) möglich) aber dafür ist die Func (im Beispiel _getAllFTPFilesRekursiv) sehr universell und erspart viel Arbeit bei zukünftigen Projekten ist daher auch in einer UDF ausgelagert.

UDF's erstelle ich nur für Funktionssammlungen die auch in anderen Projekten wieder verwertbar sind.

In https://www.autoitscript.com/wiki/Best_coding_practices sind einige Anhaltspunkte die man beachten sollte und zumindest einmal gelesen haben. Hilft beim Verwenden fremder UDF's ungemein und sollte daher beim erstellen von UDF's die weitergegeben werden sollen auch eingehalten werden.

Wenn du nur für dich selbst und zum Spaß programmierst ist es natürlich nur wichtig, daß du dein Skript nach X Jahren noch verstehst. Es soll sogar Leute geben die ihre Skripts vor dem Kompilieren noch unleserlich machen (obfuskatieren?), aber das ist ein anderes Thema.

In einer Firma/Projektgruppe ist es natürlich wichtig, daß die Skripte/Funktionen von Maier ohne große Probleme auch von Müller weiterentwickelt werden können, alles andere nennt man zwar Kündigugsschutzprogrammierstil ist aber ein Grund zur Kündigung wenn man Vorgaben bezüglich Namenskonventionen etc. widerholt mißachtet.

PS.: bei groben (Rest-) Typos Micha_he fragen, der hat anscheinend ein Dictionary zum übersetzen solcher.

Ich habe mir auch schon viele Gedanken über Strukturen usw. gemacht, seit ich im Bereich der Softwareentwicklung gelandet bin. Grundsätzlich gibt es fast so viele Stile wie Programmierer und in jeder Programmiersprache dominiert eine ungefähre Richtlinie. Bioshade hat ja auch schon einen Verweis auf C# platziert, aus dem in diesem Fall solche Richtlinien für AutoIt übernommen worden sind.

Ich habe in vielen Projekten schon viele Dinge ausprobiert und bin für mich persönlich zu dem Schluss gekommen, dass es keinen einheitlichen Stil geben muss. So schmerzhaft das auch klingen mag.
Ich finde, man muss Aufwand und Nutzen immer in Relation sehen. Strikter Stil schön und gut, aber wenn ich ein einfaches Tool schreibe, dessen Quellcode in einer Datei um die 200 Zeilen lang ist, dann muss ich das nicht in mehrere Dateien aufteilen, um den Überblick zu behalten. Hier ein Kommentar, da ein paar sinnvolle Bezeichnungen und ich kann das alles auch noch in einem Jahr lesen und verändern, ohne alles durch eine strikte Struktur aufzublähen. Wenn ich jetzt allerdings bspw. ein Warenwirtschaftssystem programmiere, dann funktioniert das natürlich nicht mehr. Da braucht es dann eine im Idealfall komplett modulare Struktur. Ich habe da meinen persönlichen Weg für so große Sachen; das zu erklären, führt aber imho zu weit.

Was die Übergabe von Variablen angeht, ist das meiner Meinung nach auch inhaltsabhängig. Ich gliedere meine Skripte immer ungefähr in universelle und spezielle Funktionen, mal am Beispiel eines ROT13-Verschlüsselers. Universelle Funktionen sind dabei Funktionen, die auch außerhalb dieses Skriptes eine Verwendung haben können, also hier z.B. die eigentliche Verschlüsselung. Diese universellen Funktionen arbeiten dann strikt ohne globale Variablen, damit sie auch universell bleiben. Die speziellen Funktionen hingegen können nur im derzeitigen Skript Anwendung finden, beispielhaft das Auslesen des Textes und die Übergabe an die universelle Verschlüsselungsfunktion. Hier greife ich dann auf globale Variablen wie GUI-Controls zurück. Das ermöglicht flexibles und nicht-redundantes Programmieren gleichzeitig.

Hi zusammen,
einige haben es mitbekommen, ein AutoIt-Team (UEZ,Xorinator,Lottich und ich) waren am Osterwochenende auf der Revision 2016.
Ich behaupte jetzt einfach mal, daß dort einige der kreativsten "Programmierer" im Grafikbereich anwesend waren.
Schaut man sich die Entwicklung in den letzten Jahren an, drängen sich mir zumindest frappierende Vergleich zu anderen "Technik"-Bereichen auf.
Genauso, wie es heutzutage kaum noch Automechaniker gibt, sondern Teiletauscher, gibt es auch kaum noch Programmierer, sondern Funktions-Copypaster!

Die Frage dabei ist, was das im Bereich der Programmierung bedeutet!? Wenn Kreativität dadurch eingeschränkt wird, dass man sich "künstlich" an von irgendwem postulierten Vorgaben orientieren MUSS, dann ist das Ergebnis bestenfalls mittelmäßig! Und das ist in den allermeisten Programmen das Problem...
Ein "Künstler" kommt nur dann zu einem sehr guten Ergebnis, wenn er seine volle Kreativität am Produkt kompromisslos ausleben kann. Jetzt kann man natürlich sagen, nicht jeder ist ein Künstler und KANN somit überhaupt nicht kreativ arbeiten! Stimmt, und genau DAS ist das Problem beim Programmieren!
Ohne Kreativität kein optimales Ergebnis!

Mal etwas krass gesagt, ein als compilierte EXE vorliegendes Programm ist das Ergebnis, und eben genau NICHT der zugrundeliegende Code. Und genau diese EXE wird verkauft und von Kunden/Anwendern benutzt! Diese interessiert es ehrlich gesagt kein Stück, ob sich der "Programmierer" im Code selbstverwirklicht, oder aber an eng gesteckte Software-Erstellungs-Konventionen gehalten hat!
Mir jedenfalls ist es als Anwender/Nutzer lieber, ich habe gegenüber einem Wettbewerbsprodukt möglichst viele Vorteile. Ob der "Programmierer", wenn er sich an strikte Vorgaben hält, dieses Ergebnis vorlegen kann, ist fraglich.
Und da bin ich immer mehr der Meinung, daß, wenn man sich viel zu vielen Einschränkungen im Schaffensprozess hingeben muss, das Ergebnis auch bestenfalls eingeschränkt ist...

Zusammengefasst: Mir ist das kreative/bessere Programm lieber als der "schön geschriebene" Code!
Das eine schließt das andere zwar nicht aus, allerdings schaffen es die meisten nicht. Aus o.g. Gründen!

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.

Zitat von Bioshade

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

Ich hoffe du weißt auch ohne diesen Test, daß deine (von mir zitierte) Aussage falsch ist:

Zitat von autoBert

Aber nur weil die Gui nicht innerhalb einer Func erzeugt und die Variablen daher im Globalen Gültigkeitsbereich deklariert wurden. Versuch mal dieses Script
....
kannstb du obige Aussage immer noch bestätigen?

und nichts anderes wollte ich mit dem Skript zeigen, daß Test Skript sollte nur dazu dienen, daß:

• du deine Aussage überdenkst
• die falsche Aussage nicht unwidersprochen bleibt.

Ich warte übrigens immer noch auf das Dementi.

Du könntest doch auch mit wenigen Funktionen die Parameter umgehen ich hatte da mal sowas wie:
(ich glaube das hab ich mal bei @BugFix gesehen :P)

Global $gc_oCTRL


Func _c_VarSet($_sVarname, $_vValue)
	Return __c_ManageVars($_sVarname, 'set', $_vValue)
EndFunc


Func _c_VarGet($_sVarname)
	Return __c_ManageVars($_sVarname, 'get')
EndFunc


Func __c_ManageVars($_sVarname, $_sType, $_vValue='')
	Switch $_sType
		Case 'get'
			If $gc_oCTRL.Exists($_sVarname) Then
				Return $gc_oCTRL($_sVarname)
			Else
				Return SetError(1,0,Null)
			EndIf
		Case 'set'
			$gc_oCTRL($_sVarname) = $_vValue
			Return 1
	EndSwitch
EndFunc

@BugFix Ja das kann man ja machen wie man will