Beiträge von BugFix

Ach DAS Beispiel - hättest du doch gleich sagen können

Ohne deinen Code zu sehen kann das nun wirklich niemand beantworten.

Zitat von wuff

Ich möchte das z.B der Name wilma erkannt wird, da er schon mit "wilma:08" in der listbox steht und dann "wilma:14" dahinter geschrieben wird.

Das ist zwar möglich aber unnütz kompliziert.
Verwende statt der Listbox ein Listview: NAME | ZEIT_1 | ZEIT_2 | ..ZEIT_n Zeit_n = max. Anzahl an Einträgen
Dann kannst du problemlos prüfen ob bereits ein Eintrag (Name) für die Person existiert und egänzt um die neue Zeit oder legst halt einen neuen Eintrag an.

Zitat von sam ghost

download von online-rechnungen und -konto-auszügen

:pinch:
Lass bloß die Finger von. Solch sensible Daten immer schön brav im Browser mit https-Protokoll laden. Oder über eine sicherheitszertifizierte Banking Software. Alles andere ist russisch Roulette.

1. Bitte rücke deinen Code ein, ist sonst schwer zu Lesen.
2. Beim Arbeiten mit der Listview-UDF solltest du die Handle und nicht die ID verwenden
3. Deine Methode war etwas aufwändig (immer das ganze Listview durchgehen um das Drag 'n Drop - Item zu finden). Das geht einfacher, wenn du $WM_NOTIFY benutzt, Bsp. habe ich erstellt

Hier hast du mal ein Beispiel, wie du deine GUI dynamisch vergrößern kannst:

Global $aInput[2] = [1]

$GUI = GUICreate('Test', 400, 50)
$aInput[1] = GUICtrlCreateInput('', 10, 10, 300, 21)
GUICtrlSetResizing(-1, 802) ; $GUI_DOCKALL
$btAdd = GUICtrlCreateButton('Add Input', 320, 10, 70, 21)
GUICtrlSetResizing(-1, 802) ; $GUI_DOCKALL
GUISetState()

While 1
Switch GUIGetMsg()
Case -3
Exit
Case $btAdd
_NewCtrl()
EndSwitch
WEnd

Func _NewCtrl()
Local $iDiff = 31 ; == Abstand + Höhe ==> 10 + 21
Local Static $iY = 10 ; == Startwert vom ersten Ctrl
$aInput[0] += 1
ReDim $aInput[$aInput[0]+1]
$iY += $iDiff
Local $aWin = WinGetPos($GUI)
WinMove($GUI, '', $aWin[0], $aWin[1], $aWin[2], $aWin[3] + 31)
$aInput[$aInput[0]] = GUICtrlCreateInput('', 10, $iY, 300, 21)
GUICtrlSetResizing(-1, 802) ; $GUI_DOCKALL
EndFunc

Zitat von Mars

Treffen sich 2 Ameisen sterben beide.

Das solltest du klarer ausführen.
Wenn ich das Programm schreiben würde, wäre Punkt 1 vor einer Bewegung zu prüfen ob ich nicht eine Kollision erleide (und wie hier angegeben sterbe).
Bezieht sich diese Anmerkung also nur darauf, dass bei einer fehlerhaften Überprüfung meinerseits die Kollision zu diesem Ergebnis führt oder ist das ein Lotteriespiel: Beweg dich - vielleicht stirbst du. :wacko:

Aber ich halte aufgrund der existierenden Lösungen in diesem Bereich eine Umsetzung in AutoIt auch nicht für sehr sinnvoll.
Sicher ist es schwer auf vollkommen neue Ideen zu kommen. Aber Altbackenes neu zu Lackieren ist nicht so der Hit..

Zitat von funkey

tut es aber nicht!? Es kommt die 'previously declared' Meldung!

Das habe ich auch schon festgestellt, deshalb lasse ich derartige bedingte Deklarationen auch weg. Wenn ich mich recht erinnere, ist das seit ca. 2 AutoItversionen nicht mehr möglich (Bug?).

Zitat von funkey

Für die 'Magic Number' 5 solltest du vielleicht $GW_CHILD verwenden, damit das ganze leichter verständlich wird.

Ich wollte nicht noch extra eine Konstante definieren. Nehme ich die Originalkonstante und im Skript wird die WinAPI oder ein anderes Skript, dass die Constants.au3 verwendet bekommst du eine Fehlermeldung (..Previous declared as Const..). OK, man könnte noch einen Unterstrich reinsetzen zur Unterscheidung..
Aber jede vermeidbare Zuweisung ist eine zu viel.

Ich hatte ja hier eine Möglichkeit gesucht das Updown im DateTime-Control zu verstecken. Inzwischen habe ich auch eine Möglichkeit gefunden und daraus gleich eine allgemeingültige Funktion erstellt. Vielleicht gibt es ja noch mehr Controls, die ein internes Control beherbergen, dessen Status auf diese Art und Weise beeinflussbar ist.

#include <DateTimeConstants.au3>

GUICreate("Time Control")
$DTP = GUICtrlCreateDate( "", 5, 10, 70, 21, $DTS_TIMEFORMAT)
_GuiCtrlSetState_InternalCtrl($DTP)

GUISetState()

Do
Until GUIGetMsg() = -3

Func _GuiCtrlSetState_InternalCtrl($_hCtrl, $_iState=@SW_HIDE)
; == by BugFix
If Not IsHWnd($_hCtrl) Then $_hCtrl = GUICtrlGetHandle($_hCtrl)
Local $aResult = DllCall("user32.dll", "hwnd", "GetWindow", "hwnd", $_hCtrl, "uint", 5)
WinSetState($aResult[0], '', $_iState)
EndFunc ;==>_GuiCtrlSetState_InternalCtrl

Die ID ist in Verwendung mit DateControl immer 1000. Daher schon bei Verwendung von zwei Controls nicht mehr brauchbar.
Class ist Standard UpDown: msctls_updown32 und ändert sich nur in der Instance. mal sehen ob sich das über die ID des DateControl ermitteln läßt.

Edit:

Habe eine Lösung gefunden. In Windows ist ja jedes Ctrl ein Fenster. Somit ist das Updown ein Child das DateTime-Ctrl. Also ermnittle ich das Child-Handle und setze dieses auf HIDE.

#include <WinAPI.au3>
#include <DateTimeConstants.au3>
#include <Constants.au3>

GUICreate("Time Control")
$DTP = GUICtrlCreateDate( "", 5, 10, 100, 21, $DTS_TIMEFORMAT)
WinSetState(_WinAPI_GetWindow(GUICtrlGetHandle($DTP), $GW_CHILD), '', @SW_HIDE)

GUISetState()

Do
Until GUIGetMsg() = -3

Hi,
wenn ich ein Time-Control erstelle habe ich immer ein überaus lästiges UpDown mit drinnen.
Hat jemand eine Idee, wie ich es eliminieren kann? (ohne ein eigenes Control schreiben zu müssen)

#include <DateTimeConstants.au3>

GUICreate("Time Control")
GUICtrlCreateDate( "", 5, 10, 100, 21, $DTS_TIMEFORMAT)
GUISetState()

Do
Until GUIGetMsg() = -3

Mehr oder minder sehr unangenehme Überraschungen.
Ich werde dann wohl lieber Skripte, die Variablenerkennung beinhalten, nach LUA portieren. Die dann (hoffentlich) angepaßte SciTE4AutoIt-Version wird ja auch einen angepaßten Lexxer enthalten und der Lexxerstyle läßt sich mit LUA sehr gut zur Identifizierung einzelner Skriptkomponenten nutzen.

Hi,
wie dem EN-Forum zu entnehmen ist, ist geplant zukünftig auch Variablennamen ohne Dollarzeichen zuzulassen.
Das ist eine mittlere Katastrophe und ruiniert mit Sicherheit Hunderte von Skripten.
Auch wenn AutoIt selber weiterhin abwärtskompatibel Variablen mit Dollarzeichen erkennen wird - unsere Skripte, die wir uns als Hilfen für den Umgang mit AutoIt erstellt haben sind darauf nicht vorbereitet.

Bisher ließ sich eine Variable mit dem Pattern "(\$\w+)" ganz einfach parsen. Nun können wir dieses Pattern in die Tonne treten und müssen feststellen, dass sich ein Parsen mittels RegEx wohl nicht so ohne Weiteres realisieren lassen wird.
Alle Begriffe aus AutoIt-Statements ( If, Then, Do, While etc. ) sind von Variablen aufgrund des Aufbaus nicht mehr zu unterscheiden.
Funktionsnamen sind im ersten Moment auch als Variablen interpretierbar, jedoch ist die folgende öffnende Klammer ein Unterscheidungsmerkmal.

Wie könnte ein Pattern aussehen, mit dem sich trotzdem Variablen erkennen lassen?
Es wird das alte Pattern und wohl oder übel eine Ausschlussprüfung auf alle Statement-Begriffe mit Folgeabfrage auf öffnende Klammer enthalten müssen.
Im Moment habe ich noch keine klare Vorstellung, wie ich das mit halbwegs Performance in ein RegEx-Pattern packen soll. Ideen werden gern entgegengenommen.

Was meint ihr, ist damit alles enthalten oder habe ich noch was vergessen?

Zitat von minx

Also ich finde StringSplit("a,b", ",")[1] nur logisch.

Das Bsp. im Zusammenhang mit StringSplit ist aus meiner Sicht eher unlogisch.
Wenn ich Split verwende, möchte ich gemeinhin mehrere Splitergebnisse verwerten, Anzahl oft vorher unbestimmt. Insofern ist der absolute Sonderfall, nur das erste (nte) Element des Splits zu verwerten sicher keine Referenz für diese Funktionalität.

Die erweiterte Zugriffsform als solche ist allerdings schon recht komfortabel, speziell (um auf den eigentlichen Threadkern zurückzukommen) der Zugriff bei Strukturen.

Was ternäre Operatoren angeht, so sehe ich das auch so, dass wohl die meisten User dafür wenig Anwendung sehen werden, aber sinnvoll eingesetzt ist das schon ein angenehmes Feature.
Vielleicht sollte man auch die allgemeine Form mal anführen, damit jenen, die davon noch nie etwas gehört haben klar ist, was ein ternärer Operator tut:
( Bedingung ) ? RückgabeWert_Wahr : RückgabeWert_Falsch

Zitat von progandy

Weder die Funktion och die DLL enthält Funktionalität um die benötigte Größe festzustellen.

Zitat von MSDN

If the function succeeds, the return value is the length, in characters, of the string copied to the buffer.

Hab es nicht getestet, aber laut MSDN ist die Funktionalität gegeben.

Edit:

Habe gerade noch wesentliche Informationen in der Diskussion entdeckt:

Zitat

lpszFormatName is NUL terminated
The API documentation fails to mention that the data dropped into the lpszFormatName buffer is always NUL (zero) terminated. The length returned is the number of characters not including the terminating NUL. Thus if the returned length is one less than the size of your lpszFormatName (in characters) then it's possible the format name was truncated.

This document also fails to mention what the maximum possible size is for a name that could get dropped into the lpszFormatName buffer Microsoft's example code uses an 80 character buffer. The RegisterClipboardFormat() API documentation is also silent on this other than to note that it's a case-insensitive string. A scan of the registered formats from 0xC000 to 0xFFFF finds the names range from 3 to 113 characters on my system at this instant. Testing finds that RegisterClipboardFormat() returns error 87 ERROR_INVALID_PARAMETER if lpszFormatName is 256 characters or longer. Attempts to register a zero length name result in error 123 ERROR_INVALID_NAME. In other words, the lpszFormatName can be from 1 to 255 characters plus the terminating NUL. Thus using a 256 character buffer will work for most, if not all, systems.

Also, der Puffer darf nicht größer als 256 Zeichen sein und muß Nulltermination berücksichtigen.

Zitat von water

Wie würdet Ihr das konkret bei meinem Beispiel aus dem ersten Post machen?

Wenn die Funktion erfolgreich ist, wird die Länge der in den Puffer kopierten Zeichen zurückgegeben.
Also:
- überlangen Puffer bereitstellen
- 1. Aufruf liefert Länge des notwendigen Puffers
- Puffer mit dieser Länge erstellen
- 2. Aufruf zum Befüllen auf exakte Puffergröße

Für variable Längen kenne ich eigentlich folgende Variante:
- erstmaliger Aufruf der Funktion gibt notwendige Pufferlänge zurück
- damit wird der Puffer erstellt und im zweiten Aufruf von der Funktion befüllt

Jetzt hier dazu einen Thread aufzumachen - OK
besser:
Wenn Admin/Mod/Poweruser online sind, diese sofort anschreiben (PN, nicht in SB) damit die Vollpfosten sofort stillgesetzt werden können.
Selbst wenn ich online angezeigt werde, lese ich nicht ständig die SB mit. Aber beim Aktualisieren fällt eine neue PN schon auf und man kann umgehend reagieren.

Ich habe auch die Erfahrung gemacht, dass (geschätzt) 90% aller Menschen die Sprache gewohnheitsmäßig richtig verwenden. Regeln kenne ich selber auch kaum (hat mich im Deutsch Unterricht nie interessiert), weiß aber aufgrund meiner "Leseerfahrung" die korrekte Anwendung.