Beiträge von BugFix

    Zitat

    die bei der Eingabe über InputBox entscheidet, ob der User eine Zahl (0-99) oder einen Text eingegeben hat.

    Da haben wir mal wieder ein XY-Problem. Ein Input-Ctrl im Style ES_NUMBER nimmt dir diese Überprüfung ab und lässt nur Zahlenwerte zu.

    Mit den folgenden Funktionen kann ich das Window Handle auslesen:


    Nun wollte ich versuchen den Titel auszulesen:

    Code
    proc GetWindowText*(hWnd: cint, lpString: cstring, nMaxCount: int32): int32 {.cdecl, varargs, importc: "GetWindowTextA", dynlib: "User32.dll".}

    Wenn ich die Funktion mit Dll-Aufruf in AutoIt oder Lua ausführe übergebe ich als Buffer (lpString) einfach einen String. Das klappt dort - aber nicht in Nim, der String wird nicht befüllt. Wenn ich statt cstring einen ptr cstring oder ptr string verwende, bleibt der Inhalt nil.

    Wie muss ich hier vorgehen?

    Ich würde trotzdem von AutoIt aus den Speicher reservieren (DllStructCreate).

    Einfach eine geschätzte Maximalgröße eintragen, den Pointer darauf an Nim übergeben, dort die Änderungen vornehmen und dann (je nach Datenstruktur) ein Int für die Anzahl an AutoIt zurückgeben

    Ja, ist wohl die sinnvollste Variante.

    Wobei ich mich gerade frage, warum ich das nach Autoit zurückgeben will. Die Projekte kann ich doch kpl. in Nim umsetzen. :Face:

    Aber Datenaustausch kann man immer brauchen. Danke nochmal für die "Erleuchtung" :D

    Ich übergebe Dateipfade, lese mit Nim die Dateien ein, parse Includes, Variablen, Konstanten, Funktionen und will all diese Daten zurückgeben. Menge ist vorher unbekannt.

    Soll das Grundgerüst werden für mein ManageIncludes und die Überarbeitung von UnusedVars.

    Wenn Du Strings übergeben willst, pack sie am besten in eine Struktur (mit Nullbyte am Ende) und übergib nur die Pointer auf die Strings

    :thumbup: Fein, wieder einen Schritt weiter.


    Und jetzt kommt gleich der nächste Punkt, wo ich hänge.

    Das bisherige diente dazu um 1..n Dateipfade übergeben zu können. Jetzt verarbeite ich die entsprechenden Dateien mit Nim und will das Ergebnis sofort zurückliefern. Nur weiß ich nicht, wie ich die Datenstruktur zum Empfang des Ergebnisses bereits beim Aufruf übergeben soll, wenn die Anzahl/Länge der Elemente erst zur Laufzeit bestimmt wird (z.B. Variablennamen auslesen o.ä.). Möglich wäre als Return Type cstring zu verwenden mit Trennzeichen zwischen den Werten und in AutoIt durch Splitten in ein Array packen. Halte ich aber für die schlechtere Variante, als wenn ich es in einer Struktur habe, auf die ich sofort ohne Umwandlung zugreifen kann.


    Bei Anwendung von Dll hat man ja oft den Hinweis: "Rufe zuerst mit NULL für den Parameter auf, um die Größe für den Puffer zu erhalten" - Das mag gehen, wenn ich einen Fenstertitel abfrage. Aber ich kann doch nicht 2-mal komplexe Programmabläufe durchführen um beim ersten mal nur die Größe zu erhalten. :rolleyes:


    Bin für Ideen empfänglich. ;)

    Danke, numerische Werte klappen tadellos.

    Jetzt wollte ich Strings übergeben. Strings aus AutoIt sind in Nim cstring. Und da fängt die Misere an. Versuche ich auf string zu casten crasht es. Und auf cstring kann ich nicht mit Range im Index zugreifen. Meine Idee war, Strings zusammenzuhängen und die Länge der Einzelstrings parallel als Array. Dann kann man das hinterher wieder zerlegen.



    Die DLL

    Ich spiele gerade mit der Möglichkeit Daten mittels Dll-Aufruf von AutoIt an Nim zu leiten.

    In pur AutoIt würde ich das so machen, um Strings zu übertragen:

    Nun ist die Frage, wie kann ich in Nim die Daten aus dem Pointer in eine Variable entpacken? Ich erstelle dazu den passenden Datentyp ByteArray, der so dimensioniert ist, dass er exakt die Daten aus dem Pointer aufnehmen kann - aber wie gehts?

    Code
    type ByteArray = array[3*128,char]
    proc sendData(pData: PInt32): int {.stdcall,exportc,dynlib.} =
    var received: ByteArray
    # wie Daten aus Pointer in die Variable entpacken?

    Und die Dateinamen dann zu übersetzen ist kompletter Humbug, da die Dateien selbst anders sortiert werden als mit ihrem originalen Unicode-Titel.

    :rofl: Du bist lustig - schon mal was von Ziffern gehört? Da auch ANSI konforme Daten nicht in alphabetischer Reihenfolge auf der CD/DVD gespeichert sind, wird doch sowieso nummeriert. :P

    Lass von der Progressbar die prozentuale Auftragsabarbeitung anzeigen, unabhängig von der Dauer des jeweiligen Vorgangs.

    Du hast 10 Vorgänge, also 10% je Vorgang. Nach jedem fertigen Vorgang erhöhst du den Wert der Progressbar also um 10. Sind alle durch bist du bei 100 und die Progressbar ist "voll". ;)

    Als Möglichkeit sehe ich hier, die Datei temporär umzubenennen

    Ich würde eher dazu tendieren, Nicht-ANSI Zeichen in Dateinamen generell durch ANSI zu ersetzen.

    Also statt

    Louisa Johnson - Whos Loving You.m4a

    besser

    Louisa Johnson - Who's Loving You.m4a


    Ist vielleicht Geschmackssache, aber ich halte absolut nichts von Nicht-ANSI Zeichen (und Leerzeichen!) in Pfad-/Dateinamen. In meiner Musikbibliothek würde dein Bsp. so aussehen:

    Louisa_Johnson__Who's_Loving_You.m4a

    In den Tags kann drinstehen was will, das wird ja auch entsprechend für die Anzeige genutzt, also kann doch der Dateiname "sauber" bleiben. ;)

    Wenn ich von hier die Versionen für x86 (nim-1.2.0_x32.zip, mingw32.7z) verwende, dann kann ich die dll mit deinen Parametern zwar erstellen, ohne dass gemeckert wird, aber es funktioniert dann trotzdem nicht in AutoIt, wenn #AutoIt3Wrapper_UseX64=n.

    Ja, ich hatte dazu in der VM nim und mingw schon als 32bit installiert um so eine eigene Umgebung zu haben. Da funktioniert auch das Kompilieren, aber die Dll ist nicht nutzbar (@error=1).

    Hinzu kommt das Problem des automatisch erstellten Funktions-Namens-Suffix (@8).

    DllStructGetData($tBitmapData, "Scan0")

    Es wäre erst mal nicht ganz unwichtig, wenn du uns den Aufbau deiner Struktur $tBitmapData mitteilst (lauffähige Minimalskripte werden von uns überhaupt sehr begrüßt).

    Laut deiner Befehlszeile ..., DllStructGetData($tBitmapData, "Scan0") ist "Scan0" ein Pointer, der auf ein DWORD-Array der Größe $iWidth * $iHeight verweist. Das ist alles, was man deinem Post entnehmen kann. Alles andere.... - wie Bitnugger bereits sagte: Glaskugel

    Diesen Thread hast Du sicher bereits selbst gefunden, oder ?

    Ja, du brauchst aber keine Threads vor ~2018 ansehen. 90% von dem dort geschriebenen ist inzwischen inhaltlich überholt.

    Das, was dort zusätzlich als Einzelparameter übergeben wird, ist inzwischen schon so in der Konfiguration enthalten.