Inoffizielles deutsches Xbase-Forum

Bringt mir nichts. Hab eine C-DLL, wenn ich da eine bestimmte Funktion rufe, ist die Applikation für ca. 20 - 30 Sekunden (eine 10-15 MB große Datei wird geöffnet und eingelesen) auf 100% und nichts geht mehr, obwohl ich das in einem eigenen Thread laufen lasse. Schade. Da könnte ich die das Öffnen ...

Servus,

gibt es inzwischen eine Möglichkeit, gezielt einen Thread auf einen Kern zu legen? Egal ob virtuell oder physisch. Ähnlich dem Beispiel smprun, aber nicht die ganze App, sondern eben nur entsprechende Threads.

und hier die Antwort von Pablo, so funktioniert es! Hi, int* mean a pointer to 32bit integer ( in C++ the asterisks mean pointer to) so your DLL IMPORT must be DLL x.dll IMPORT dateUnpack AS int; PARAM nWert AS Double,; PARAM nYear AS LPLONG,; PARAM nMonth AS LPLONG,; PARAM nDay AS LPLONG,; PARAM nH...

Servus Jimmy,

hab ich jetzt gemacht, werde das Ergebnis hier posten.

Servus Jimmy, danke, dass Du Dir die Arbeit hier machst, aber davon verstehe ich absolut nichts. Der Syntax sagt mir nichts und löst auch nicht mein ursprüngliches Problem: "Interne Datenstrukturen beschädigt" beim Aufruf der o. zitierten C-Funktion, die mir wohl Werte in die übergebenen V...

AUGE_OHR hat geschrieben:der numerische Wert 41255 ist IMHO nur der Pointer "wo" sich die Struktur befindet

Nein, ziemlich sicher nicht, er muss mit der Funktion aus der C-Lib in ein Datum zerlegt werden.

Servus Jimmy, danke. Aber weder mit static function dateUnPack(cConvertTime) local cFileTime := space(8) IF DllCall("Kernel32.dll",DLL_STDCALL,"SystemTimeToFileTime", cConvertTime, @cFileTime)==0 RETURN Space(8) ENDIF RETURN cFileTime noch mit DLL Kernel32.dll IMPORT dateUnPack A...

Servus Jimmy, ich wüsste nicht, wie ich das hier verwenden soll, sorry, da blicke ich nicht durch. Den Wert, den ich der C-Funktion übergebe, sieht auch völlig anders aus, ist z. B. 41255 und müsste das Datum 12.12.2012 mit irgendeiner Uhrzeit sein. Es geht hier wohl ums Grundsätzliche, hab noch meh...

AUGE_OHR hat geschrieben:in ot4xb gibt es die Function FileTime() welche diese Structur hat.

Nach meinem Verständnis hilft mir hier aber die Struktur nicht, da die Vars einzeln übergeben werden müssen und nicht eine Struktur?

brandelh hat geschrieben:Ich würde Pablo fragen, ob die mit int* bezeichneten Variablen richtig umgesetzt sind.
Eventuell muss man dort definieren, dass es Pointer sind und es reicht nicht, es im Parameter zu tun (@).

Weißt Du, wie das geht, dann teste ich es einfach, ohne da gleich Pablo zu fragen?

Was mache ich hier falsch? int XAPIENTRY XDateUnpackA(double value, int* year, int* month, int* day, int* hour, int* min, int* sec, int* msec) soll mir aus der C-Lib einen Datumswert in die angegebenen Vars schreiben. Der Rückgabewert der Funktion ist 0 für ok, und <> 0 für Fehler. Das hab ich dann ...

Subkey unterhalb des existierenden löschen

============================================================

Delete subkey (including all contained values and subkeys)

so stehts in der Regclass. Werde es mal testen. Wird halt aufwändig.

Servus Hubert,

doch, ich will komplette Keys inkl. deren Werte löschen.

Hab das gleiche Problem, bei Möchte dort in einem Subkey einige Keys löschen mit
Key existiert.

Servus Otto,

mir war nicht bewusst, dass Du von Harbour schreibst. Ich hab halt stundenlang rumgetestet und wie immer den Fehler bei mir gesucht, Zeit ist eh immer zu knapp, mit anderen Worten: Sorry, wollte Dich nicht diffamieren.

Servus Hubert, danke, da stimme ich Dir 100%ig zu. Außerdem hat man mit den low-level-Funktionen auch die Möglichkeit, mit großen, den virtuellen Speicher übersteigenden Dateien umzugehen. Für mich ist die fixe und schlaue Lösung von Otto eigentlich nicht zu gebrauchen, weil die Dateien - wie die Üb...

Servus Hubert, ich hatte doch ein Beispiel gepostet :wink: Durch Deinen Code hab ich was entdeckt: Ich hatte doch geschrieben, dass das Öffnen einer shared-geöffneten Dbf mittels low-level-Filefunktion ebenfalls den Fehler 32 bringt. Bei Deinem Beispiel war das ja nicht. Habs gefunden, es liegt am F...

Servus Georg,

an der Größe liegt es nicht, das hatte ich schon getestet. Da käme auch eine andere Fehlermeldung.

Deshalb nochmal die Frage: Hat das so schon mal jemand getestet, ein Erfolgreiches memoread() auf die shared-geöffnete Dbf wie oben beschrieben?

Dann hätte der Code ja keinen Sinn! Es geht um eine schnelle Suche in einer geöffneten DBF. Memoread liest read-only, die DBF ist shared geöffnet, es müsste gehen. Bei azzo funktioniert es ja offensichtlich.

Hat jemand mal den Code von azzo selber getestet? Selbst das geht bei mir nicht:
Der Pfad passt.

azzo hat geschrieben:Hallo Werne,
sicherheitshalber die Frage:
Schreib-/leserechte hast du?

Ja. Steht eigentlich alles in meiner Nachricht.

ja
nein

Servus Otto, Dein Code hat mich sehr interessiert, deshalb hab ich ihn sofort getestet. Was ich aber nicht verstehe, die dbf ist bei mir local shared geöffnet, das memoread ist dann aber erfolglos, auch mittels low-level-file Funktionen bekomme ich den Filefehler 32: Der Prozess kann nicht auf die D...

Servus Hubert,

danke. Nein, brauchst es nicht zu übersetzen. Ja, den Syntax hab ich mir auch schon in der ppo-Datei angesehen und deshalb auch entschieden, dass ich es so mache, weil ich diese kryptischen Strings für mich als nicht aussagekräftig empfinde.

Ich nehme an, dass der unerwartete Rückgabewert eigentlich einen Fehlercode markiert, denn eine DLL, die keinen per Referenz übergebenen Parameter besetzt (was eigentlich der Normalfall ist - und auch leichter zu behandeln), muss als Rückgabe die erwarteten Werte und Fehlercodes mischen. Wahrschein...