Entweder die Definition ist falsch, oder die CallingConvention. Ich tippe ja(wie bereits zuvor) auf die Calling-Convention und vermute, dass es Cdecl sein dürfte.

jvbsl schrieb:

dass es Cdecl sein dürfte.

Steht doch in der P/Invoke definition in Zeile 5 meines letzen Posts. (Ich geh jetzt einfach mal davon aus, dass @tron25 den Code verwendet.

@tron25: Könntest du uns eventuell die DLL zur Verfügung stellen, so dass wir auch mal testen können.

Du erstellst eine Anwort, klickst auf Erweiterte Ansicht und dann unten auf den Reiter Dateianhänge. Da kannst du dann die Dateien anhängen. Aber am besten alles Zip-en, dann is alles beisammen

Hallo @tron25

Könntest du ein entsprechendes GekuerztText.Text und UngekuerztText.Text als Beispiel angeben. Ich nehme an, das sind ganz bestimmte Wörter.

Eventuell könnte ich es heute abend kurz anschauen.

Freundliche Grüsse

exc-jdbi

lou_translateString scheint einfach nur:

zu sein, und lou_translate wiederum:


die 0en sind dabei die eigentlichen optionalen Parameter.

lou_translateString scheint außerdem doch tatsächlich nen stdcall zu sein, trace_translate hingegen cdecl(what the hell).
Dabei scheint er nie größer outlen zu schreiben, d.h. du musst outlen wie es aussieht selbst groß genug machen, denn er wird dir nicht mitteilen, dass der output eigentlich größer ist.

Bei dem ganzen kann ich mich natürlich irren, ich habs jetzt nicht ausprobiert, sondern nur etwas die disassembly angeschaut.

Hallo @tron25,

ich hab mir mal die Lib angesehen und bin auf 2 Sachen gestoßen:
1.) Wenn du dir die Beschreibung der Funktion noch mal durchliest, dann wirst du feststellen, dass dein Code
völliger Schwachsinn ist. Denn (wie in der letzten Zeile steht The function returns 1 if no errors were encountered and 0 if a complete translation could not be done => 0 bedeutet ein Fehler ist aufgetreten, eine 1 zeigt an, dass alles gut gelaufen ist.
EDIT: IMHO hat der Programmierer der Lib hier schon einen Fehler gemacht, denn afaik wird in C und in C++ schon immer die 0 als Return value dafür verwendet um anzuzeigen 0 Fehler sind aufgetreten => alles OK und Zahlen >0 sollen anzeigen WELCHER Fehler aufgetreten ist. Das kann dann etwa per Batch und ECHO %errorcode% ermittelt werden (Historisch bedingt)

2.) Bezüglich der deklaration der Funktion: So wie es aussieht (und damit auch an @jvbsl), die Aufrufkonvention StdCall und WinApi funktionieren. Auch lassen sich die <MarshalAs(...)> Attribute entfernen. Die braucht man nicht.

Ich hab jetzt mal den Code mit den oben genannten Änderungen laufen lassen und lustigerweise spuckt mir der StringBuilder kein wo4ccde sondern {'}aus. Ich kann mir das nur erklären, als dass eine falsche Tabelle angegeben wird.

Lg Radinator

nene, dumm ist das nicht, er hätte nur nen typedef für bool machen müssen.
Also passt 1 für erfolgreich und 0 für nicht erfolgreich sehr wohl, dürfte sogar einfach mit einem bool return value in .Net funktionieren.
Also wenn ich nur zwei mögliche values hab, dann passt das, für einen Return Code wird, jedoch tatsächlich 0 für erfolgreich.

jvbsl schrieb:

lso wenn ich nur zwei mögliche values hab, dann passt das, für einen Return Code wird, jedoch tatsächlich 0 für erfolgreich.

Mag sein, dass das hier in dem Fall passt, jedoch hab ich mir sagen lassen - von jemanden der vor 30 Jahren als Software-Ingenieure angefangen hat und damals für die Firmware von Microcontrollern zuständig war - dass das mit dem Return Wert von 0, 1, ... damit zusammen hängt, als dass man damals ja noch keine Exceptions hatte. Damals wurden die Programme noch per Batch aufgerufen und wenn das Programm abgeschmiert ist, konnte man den %errorlevel% (nicht errorcode) auswerten und bekam anschließend Meldung, was für ein Fehler aufgetreten ist.

So stand, wie gesagt eine 0 für 0 Fehler, eine 1 für meinetwegen einen Eingebe Fehler, eine 2 für nicht vorhanden Datei und so weiter. Man nannte das halt damals StatusCode

Wenn du dir mal die MSDN Code Guidlines ansiehst unter Exceptions, dann sagt MS auch gleich im ersten Punks:

X DO NOT return error codes.

Lg Radinator

Wer vor 30 Jahren angefangen hat ist oftmals nicht auf dem Stand der Dinge. Und ja Statuscodes waren und sind auch heute noch in C sinnvoll(in Cpp gibts exceptions). Jedoch hat man auch damals wenn es eben nur eine boolesche ausgabe gibt es genau so gemacht, schließlich war C damals wie heute dies hier möglich:

und somit viel sinnvoller zu verwenden als ein StatusCode. Den Statuscode einer Funktion hast du damals auch nicht bekommen(schließlich war es mit Debuggern ja auch noch mau), man hat nur den ExitCode des Programms bekommen und das bekommt man auch nur, wenn man den StatusCode aller funktionen bis ganz nach oben durchreicht.
Diese Funktion die wir hier haben ist vergleichbar mit TryParse. da willste auch keinen Statuscode, du willst einfach nur wissen, ob es funktioniert hat oder nicht.->bool return

oder einfach stdbool.h includieren.

Ich beende diese Raterei jetzt mal. Folgendes läuft bei mir tadellos durch:

tron25 schrieb:

der "Sub Main" in eine Funktion kopiere

Am besten erstellst du dir eine eigene Klasse (mit den Namen NativeMethods), in diese fügst du die Funktion von @hal2000 ein und deklarierst sie als Public Shared Function.... Damit ermöglichst du den Zugriff, ohne eine Instanz der Klasse NativeMethods erstellen zu müssen.

Edit: falles es wen interessiert, aber das ganze gibt es auch auf Github(also das liblouis-Projekt)

@tron25 Vielleicht führst Du Dir den Post #2 noch mal ausführlich zu Gemüte.
Wenn Du das Prozedere verstanden hast, solltest Du mit Deinem Projekt keine Schwierigkeiten mehr haben.

@Radinator meint folgendes: