Also ich sehe den Button.
Ich schaus mir mal an und werde den Bug fixen ![]()
Also ich sehe den Button.
Ich schaus mir mal an und werde den Bug fixen ![]()
was genau verhindert die Abwärtskompatbilität
Bezieht sich z.B. auf:
Was mich aber wirklich ankotzt ist die Tatsache, dass der KONSTANTEN-NAME $tagBITMAPINFO gleich geblieben ist!
Wer denkt sich denn solch einen Schwachsinn aus?
Das wäre, als wenn man "einfach so" GUI_EVENT_CLOSE von -3 auf 693 ändern würde....
Konstante hat denselben Namen (den wir in bestehenden Skripten verwendet haben) aber plötzlich neue Inhalte!! - Das ist Dummfug hoch drei!
Ich bin da auch stinkig, weil ich auch viele Skripte habe, die mit dieser Konstanten arbeiten.
Sollen wir in Zukunft zu jeder Programmversion eine Includesammlung separat abspeichern? Nein Danke, ohne mich.
Es ist mir ein absolutes Rätsel, welche Furze den momentanen Meinungsbildnern unter den Devs durchs Hirn schiessen. Aber eines können wir wohl festhalten:
Mit der Version 3.3.10.0 wurde das Ende von AutoIt eingeläutet. Eine Sprache ohne Abwärtskompatibilität ist echt ein Witz und leider völlig inakzeptabel. Fast 8 Jahre bin ich nun dabei - aber inzwischen sehe ich mich schon nach Alternativen um für Programme die auch noch in Jahren Bestand haben sollen. Somit rutscht AutoIt völlig ab auf die reine Freizeitschiene - ein Platz den es eigentlich nicht verdient hat. ![]()
1. Damit das hier nicht ausufert:
Zitat von peethebee... aber so einen Counter finde ich auch nicht gut.
Das haben wir im PU-Forum vor ein paar Tagen diskutiert.
2. Falls irgendjemand der Meinung ist, ein Forum sei eine Demokratie, liegt er schief. Auch das wurde schon häufiger diskutiert. Der/Die Administratoren stehen für die Gestaltung des Forums in jeder Hinsicht gerade. Und somit wird das Forum auch die Handschrift der Admins tragen. Als Mod bin ich gewissermassen "Erfüllungsgehilfe" der Administration. Und ihr könnt mir glauben (und wer lange genug dabei ist, weiss, dass dem so ist), ich vertrete hier keine private Meinung, sondern die des "Chefs". Also denkt nicht, mir würde die Legitimation fehlen, für das, was ich tue.
Anscheinend ist das "Danke-Button Fieber" ausgebrochen.
Damit hier nicht noch mehr User auf dumme Gedanken kommen:
Danke-Button werden nicht toleriert!
Wir haben schon vor längerer Zeit darüber diskutiert und entschieden, dass diese nicht mit unserem Forengedanken vereinbar sind.
Egal, was ihr ändern wollt -- klärt sowas im Vorfeld mit uns.
Ich hoffe, dass ihr dafür Verständnis habt.
Eines fällt mir gerade beim Thema Structures auf. Die Umsetzung mit der neuen Syntax ist hier leider nicht konsistent.
Bsp.:
; == Strukturen können Bezeichner führen, diese müssen aber aus Buchstaben bestehen
$tStruct = DllStructCreate("int links;int rechts")
; mit neuer Syntax ansprechbar:
$tStruct.links = 120
$tStruct.rechts = 70
; == Wenn die Felder der Struktur jedoch keine Bezeichner führen, kann die neue Syntax nicht angewendet werden
; == Hier wäre eigentlich folgendes sinnvoll und wünschenswert:
$tStruct = DllStructCreate("int;int")
; mit neuer Syntax ansprechen über Nummer des Elements:
$tStruct.1 = 120
$tStruct.2 = 70
Gibt es auch von einem deutschen Anbieter: https://selfhost.de/cgi-bin/selfhost?p=c…5ff36d92e97c7c5
selfhost erfordert aber ebenfalls einmal im Monat (aber erst nach Aufforderung per Mail) eine Aktivierung des Accounts. Alternativ kann man für 5 € eine Brief-Authentifikation durchführen, dann entfällt die monatliche Aktivierung.
aber beachte man, das es so sein sollte, was sicherlich nur aus Platzgründen nicht in einer Zeile ist:
Einfach an das Ende der ersten Zeile ein Leerzeichen + Zeilenfortschreibung " \". In *.properties ist der Backslash dasselbe, wie in AutoIt-Skripten der Unterstrich. ![]()
Ich persönlich halte ein derartiges Unterfangen für wenig sinnvoll.
Denn du prüfst ja nur, was du selbst festgelegt hast - doch dabei treten sicher die wenigsten Fehler auf. Wenn man sich dazu durchgerungen hat, seine Variablen im Vorfeld zu deklarieren, macht man sich auch ausreichend Gedanken über deren Anwendung.
Probleme sind doch eher derart, dass man z.B. in einer INI einen Zustand mit 0/1 abspeichert um mit einer direkten IF-Abfrage (If $Zustand Then .. ) darauf zuzugreifen und nicht bedenkt, dass eine INI immer Textwerte zurückgibt, der gelesene Wert vor der Verwendung also noch mit Number gewandelt werden muss.
Natürlich kannst du das Erstellen und wer mag kann es auch einbinden. Ich würde dir dann auch mal einen Blick hierauf empfehlen. In wesentlichen Komponenten wäre dieses Skript für dein Unterfangen nutzbar.
Als ich mit AutoIt anfing, war ich ziemlich verwirrt, wegen der fehlenden Variableninitialisierung. Das kannte ich bisher nicht. Ich bin nach wie vor nicht glücklich über den Datentyp Variant und würde eine saubere Typzuweisung bevorzugen, habe mich aber mit dem Zustand arrangiert. Ein Schritt vom Jetzt-Zustand weg würde eh zu Script-Braking-Chances ohne Ende führen. Ich muss mich aber auch Andy's Bedenken anschliessen, was die Entwicklung von AutoIt angeht. Sicher ergeben einige Syntaxänderungen in der akt. Version ein nettes Handling. Aber wie wäre es, wenn man vorhandene Fehler mal vorher beseitigt? Immer wieder werden Bug-Meldungen sofort geschlossen mit dem Verweis: Fixed in next Stable/Beta. Und wenn die Version dann auf dem Markt ist, hat sich absolut nichts geändert!
Im Portal ist aber schon ein Beitrag mit Beispielen zur neuen Syntax.
Du liest also auch in unserem Forum nicht richtig mit?! - Ich bin empört. ![]()
Aber das funktioniert nicht, wenn er, wie angegeben als $sString "DB5.DBW1" angiebt.
OK, hatte ich nicht gesehen - aber kein Problem, dann passt man das Pattern an. ![]()
Habe das Ergebnis jetzt der Einfachheit halber mal in eine Struktur gepackt.
Global $tSBS = DllStructCreate("int DB;int Byte;int Bit;")
Global $sPattern = "DB(\d+)\.DB[A-Z](\d+)(?:\.(\d+))?"
Global $sString = "DB5.DBW1"
Global $aMatch = StringRegExp($sString, $sPattern, 3)
If IsArray($aMatch) Then
For $i = 0 To UBound($aMatch) -1
DllStructSetData($tSBS, $i+1, $aMatch[$i])
Next
EndIf
; == Syntax mit mit v 3.3.10.0
ConsoleWrite('DB: ' & $tSBS.DB & @LF)
ConsoleWrite('Byte: ' & $tSBS.Byte & @LF)
ConsoleWrite('Bit: ' & $tSBS.Bit & @LF)
Also _StringBetween würde ich nicht empfehlen. M.M. nach ist hier Regex optimal:
[autoit]Global $sString = "DB5.DBX6.0"
Global $DB, $Byte, $Bit
Global $sPattern = "DB(\d+)\.DBX(\d+)\.(\d+)"
Global $aMatch = StringRegExp($sString, $sPattern, 3)
If IsArray($aMatch) Then
$DB = $aMatch[0]
$Byte = $aMatch[1]
$Bit = $aMatch[2]
EndIf
Eigentlich müsste es doch bei "Codebox" stehen oder
Oder trifft zu ![]()
Es ist in der class ".codeSnippetContainer". Dort BG-Color setzen und alles passt. ![]()
Edit: Hab gerade gesehen, dass der Tab-Bereich dann auch grau ist, also die class ".codeSnippetContainerTabs" auf BG-Color weiss setzen. Die obere Umrahmung fehlt dann - musst du mal suchen, wo die definiert ist, habe ich noch nicht entdeckt ![]()
Schau dir mal
[autoit]StringSplit
[/autoit]an.
Wenn es bearbeitet werden soll, kannst du in dem Moment ja ein Input drüberlegen, aber den Inhalt zeigst du dann im Label.
Es gibt eine Alternative: Erstelle ein eigenes Input-Ctrl aus einem Label. Dieses kannst du nach Belieben zentrieren.
Da man Funktionen jetzt Variablen zuweisen kann, ist auch eine Funktion hinzugekommen, mit der man auf native oder User definierte Funktion der Variablen prüfen kann:
[autoit]; == Neue Prüffunktion
[/autoit][autoit][/autoit][autoit]Func _AnyFunc()
Return True
EndFunc
$UserFunc = _AnyFunc
$NativeFunc = ConsoleWrite
ConsoleWrite('User Funktion: ' & IsFunc($UserFunc) & @LF) ; 1 = User Funktion
ConsoleWrite('Native Funktion: ' & IsFunc($NativeFunc) & @LF) ; 2 = Native Funktion
Funktionen in Variablen ermöglichen nun auch die Verwendung von Funktionen als Parameter anderer Funktionen:
[autoit]; == Funktion als Parameter
[/autoit][autoit][/autoit][autoit]Func _ParameterFunktion($a, $b)
Return $a + $b
EndFunc
Func _Any($x, $param)
Return $x + $param($x+1, $x+2)
EndFunc
$paramF = _ParameterFunktion
[/autoit][autoit][/autoit][autoit]ConsoleWrite( _Any(10, $paramF) & @LF) ; ==> 33
[/autoit]Der direkte Zugriff auf Elemente von Funktionen, die ein Array zurückgeben ist nicht nur bei integrierten, sondern auch bei selbst erstellten Funktionen möglich:
[autoit]ConsoleWrite(_ArrayRet()[2] & @LF) ; ==> "C"
[/autoit][autoit][/autoit][autoit]Func _ArrayRet()
Local $aRet[] = ['A','B','C','D','E']
Return $aRet
EndFunc
Ich bin der leibhaftige Grinch, ich kann Weihnachten nicht ausstehen.
Nichtsdestotrotz wünsche ich euch Fehlgeleiteten ein paar schöne Tage. ![]()
eMail regexen ist eklig. Du solltest dazu im Vorfeld schon definieren, welches reguläre Mailadressen sein können. Ein Pattern, dass so ziemlich alle Adressvarianten abdeckt ist mal eben locker 1000 Zeichen lang.
Aber mit dem hier sollte das meiste abgedeckt sein: ^[_A-Za-z0-9-\\+]+(\\.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\\.[A-Za-z0-9]+)*(\\.[A-Za-z]{2,})$
Edit: Kurze Erklärung warum das so lang sein könnte. Das gilt dann, wenn du gleich auf Gültigkeit der Adressen prüfst (also keine Trash- od. Fakemails)
Soweit ich beim Rumprobieren mit dem Resizing erfahren habe, wird das Resize-Verhalten nicht nur auf die Ctrl sondern auch auf den gesamten GUI-Hintergrund angewendet. Somit kannst du einen fixen Abstand zw. Ctrls aber dynamische Änderung der Ctrl selbst nicht realisieren.