OpenCascade

[Raible]

Hallo zusammen,

ich versuche gerade OpenCascade von Delphi aus anzusprechen.
Bisher gelingt es mir die OCC Quellen mit VS-2015 zu übersetzen,
und eine eigene Wrapper.dll zu erzeugen. Die Wrapper.dll besitzt
bislang nur zwei C Funktionen zum erzeugen und löschen eines
C++ Objekts (WNT_Window).

Wenn ich die Wrapper.dll in einem Delphi aufrufe egal ob dynamisch
oder statisch gebunden erscheint die Meldung

--------------------------------
Debug Assertion Failed!

Programm: X:\<Pfad ...>\OCC_Test.exe
File: minkernel\crts\ucrt\scr\appcrt\lowio\lseek.cpp
Line: 74

Expression: ("Invalid file descriptor",0)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
----------------------------------

Nachdem diese Meldung vier mal mit der Taste "Ignorieren"
bestätigt wurde startet das Programm ganz normal.
Meine beiden Funktionen können dann auch aufgerufen werden.

In VS-2015 Aufgerufen ergibt sich die unten beigefügte Aufrufliste.

Hat jemand einen Tipp für mich wie ich da weiter kommen kann?

[Jens01]

Gibt es nicht fertige Dlls?!

Gibt es hier nicht welche?

Der Autor hat anscheinend auch ein Wrapper für Python erstellt.

[Fritzew]

Ich würde sagen Du versuchst irgendwo auf die console zu schreiben.
Sind da debugprints oder so etwas in Deiner Source?
Wir haben hier eine Wrapper Dll zu Opencascade die auch mit VC2015 compiliert ist.
Läuft ohne Probleme

[Raible]

In meiner Source ist nur die zwei Funktionen um mal Testweise ein C++ Objekt zu erzeugen und wieder zu löschen. Wenn dann sind die debugprints in den Original Quellen.
Laut Aufrufliste sind noch nicht einmal OCC DLLs involviert (sofern ich das richtig interpretiere).

Gibt es denn einen Schalter um debugprints zu deaktivieren?

Habt ihr eure Wrapper DLL selber erzeugt?


die tpaviot Quellen auf die Jens01 verweist werde ich mir mal genauer anschauen. Vielen dank für den Tipp.

[Fritzew]

Ja wir haben die Dll selber gemacht. Ist aber sehr speziell an unsere Bedürfnisse angepasst.
Aber um bei Deinem Problem zu bleiben, nur mit der Grafik vom Stacktrace is das schwer zu sagen.
Warum versuchst Du nicht einfach mal die Dll im Debugger laufen zu lassen?

[Raible]

Debuggen habe ich nun endlich hinbekommen.

In "UnitsAPI.cxx" werden vier Parameter gesetzt.

Code:

static OSD_Environment env1("CSF_UnitsLexicon");
static OSD_Environment env2("CSF_UnitsDefinition");
#ifdef _WIN32
static OSD_Environment env3("CSF_CurrentUnits");
static OSD_Environment env4("CSF_MDTVCurrentUnits");

Jede Zeile verursacht jeweils die beschriebene nichtssagende Fehlermeldung.


OSD_Environment ist ein Object mit folgenden Feldern:

Code:

...
private:
  TCollection_AsciiString myName;
  TCollection_AsciiString myValue;
  OSD_Error myError;

Der Constructor weist myName zu.
Dabei wird wohl Speicher reserviert die Textlänge hinterlegt
und der übergebene Parameter in den reservierten Speicher kopiert.


Möglicherweise stimmt etwas mit der Speicherverwaltung nicht.

Hat jemand eine Idee wie ich da weiterkommen kann?
Gibt es in Delphi Stellschrauben die ich verwenden könnte
irgend eine Konfiguration oder einbinden einer
spezieller Unit(Speichermanager)?

[Fritzew]

wenn Du magst häng doch mal dein c++ Source hier an dann schaue ich rein. so bringt das nichts

[Raible]

vielen Dank schon mal im voraus.



was meinen eigenen C/C++ Code anbelangt habe ich zunächst
ein Win32 Projekt mit Anwendungstyp DLL erstellt.
Die dabei erstellten Dateien
dllmain.cpp
stdafx.cpp
stdafx.h
targetver.h

sind unverändert.

zusätzlich erstellte ich die Datei "C_WNT_Window.cpp" mit folgendem Inhalt:

Code:

#include "stdafx.h"
#include <WNT_Window.hxx>

#define EXPORTCALL __declspec(dllexport) 


typedef WNT_Window *WNT_WindowHandle;

extern "C"
{
   WNT_WindowHandle EXPORTCALL NewWNT_Window(
      const Aspect_Handle aHandle,
      const Quantity_NameOfColor aBackColor = Quantity_NOC_MATRAGRAY)
   {
      WNT_WindowHandle handle = new WNT_Window(aHandle, aBackColor);
      return handle;
   }


   void EXPORTCALL DeleteWNT_Window(WNT_WindowHandle handle)
   {
      handle->Unmap();
      delete handle;

   }



}// extern "C"

Damit wollte ich testen ob es mir überhaupt gelingt ein C++ Object
aus Delphi heraus zu verwenden.

Die Fehler ereignen sich aber bereits bei der Initialisierung der OCC DLLs.
Obiger Code ist da noch nicht involviert.

auf der Delphi Seite binde ich die DLL Dynamisch ein

Code:

unit OCCWrapper;

interface
uses
  WinApi.Windows;

const
  LibName = 'OCCWrapper.dll';

var
  OCCLibHnd: THandle;

implementation

initialization
  OCCLibHnd := LoadLibrary(LibName);
finalization
  FreeLibrary(OCCLibHnd);
  OCCLibHnd := 0;
end.

Möglicherweise genügt es nicht, nur #include <WNT_Window.hxx> einzubinden?

[Fritzew]

Hallo also mit dem include von

Delphi-Quellcode:

#include <WNT_Window.hxx>

bindest Du quasi das ganze OCC mit ein.
das ist zum testen wohl kaum optimal.

Auch das mischen von c++ Windows und Delphi Forms würde ich lassen.... Damit fällst Du 100% auf die Nase.

Opencascade ist auch mehr eine Geometrie Library als ein Viewer. Mit den reinen Geometrie Klassen klappt das super.

Was willst Du eigentlich genau machen?

[Raible]

Zitat:

Auch das mischen von c++ Windows und Delphi Forms würde ich lassen.... Damit fällst Du 100% auf die Nase.

Opencascade ist auch mehr eine Geometrie Library als ein Viewer. Mit den reinen Geometrie Klassen klappt das super.

OK. Dann werde ich mal kleinere Brötchen backen und mit einfachen Geometriedaten beginnen.
Wobei laut Stacktrace diese Meldungen aus TKernel.dll heraus aufgerufen werden,
Und TKernel.dll werde ich wahrscheinlich immer benötigen.

Habt ihr denn eine Konsole mit laufen auf der Ausgaben stattfinden?
Eine Vermutung ist dass OCC bei der Initialisierung etwas ausgeben
möchte dies aber nicht kann weil ein wie auch immer gearteter Ausgabekanal
nicht eingerichtet ist.


Nur so Interesse halber, für was setzt ihr den OCC ein?

Ich für meinen Teil entwickle für einen Behälterbauer
einen Produktkonfigurator auf der Basis eines
regelbasierten Expertensystems.

Damit kann man automatisch sehr nützliche Dinge erstellen
Arbeitspläne, Stücklisten, Maschinenansteuerungen, 2D Zeichnung ...

Nun möchte ich prüfen ob auch 3D möglich ist.
Die Geometriedaten könnten automatisch erstellt werden.
Die Anzeige der Daten wäre natürlich ganz nett,
und das Speichern in einem gängigen CAD Format auch.

[Fritzew]

Also wir setzen OpenCascade als Volumen Generator ein.
Wir machen Tools für Holzbearbeitung bis hin zur Maschinenansteuerung.
Wir erzeugen Parameterisierte Volumen wodurch jederzeit etwas geändert werden kann.
es gibt also verschiedene primitive und bearbeiten die dann so nach dem Schema
Quader Länge / Breite Höhe erzeugen. Dann kommen die Bearbeitungen dran. Abschneiden an Ebenen, abrunden / fasen, Öffnungen einschneiden etc.
Das Ergebnis holen wir uns dann von Opencascade in verschiedenen Formaten für Rendering Zeichnungen etc.
Funktioniert klasse. Das einzige was stört ist die Geschwindigkeit von Opencascade im Vergleich zb zum ACIS Kern oder ähnlichem.
Mit der V7.0 von OCC ist das allerdings etwas besser geworden da die Boolschen Funktionen und auch der Mesher / Hiddenline Generator jetzt auch multi-thread unterstützen.

Auch benutzen wir den Step Import recht häufig für Verbindungsmittel etc.

[Jens01]

Zitat:

Wir machen Tools für Holzbearbeitung bis hin zur Maschinenansteuerung.

Wer seid Ihr denn? IMOS?

[Raible]

Ich habe nun eine Lösung für das Problem gefunden.

Beim Laden der Wrapper DLL werden auch diverse OCC DLL
geladen und Initialisiert.
Dabei werden Daten an StdErr ausgegeben.
In einem VCL Programm sind die Standardausgaben aber
nicht vorhanden.
Der Aufruf aus einem Delphi Konsolenprogramm
funktioniert hingegen ohne Probleme.

Als Lösung binde ich die DLL nun dynamisch ein, und setze
vorher aber die Standardausgaben.

Delphi-Quellcode:

unit OCCWrapper;

interface
uses
  System.Classes,
  WinApi.Windows;

const
  LibName = 'OCCWrapper.dll';

var
  prevStdOutputHandle : NativeUInt;
  prevStdErrorHandle  : NativeUInt;

  OCCLibHnd: THandle;
  StdFileStream: TFileStream;

implementation

initialization
  prevStdOutputHandle := GetStdHandle(STD_OUTPUT_HANDLE);
  prevStdErrorHandle  := GetStdHandle(STD_ERROR_HANDLE );

  StdFileStream := TFileStream.Create('C:\Temp\output.log', fmCreate);

  SetStdHandle(STD_OUTPUT_HANDLE, StdFileStream.Handle);
  SetStdHandle(STD_ERROR_HANDLE , StdFileStream.Handle);

  OCCLibHnd := LoadLibrary(LibName);

finalization
  FreeLibrary(OCCLibHnd);
  OCCLibHnd := 0;

  SetStdHandle(STD_OUTPUT_HANDLE, prevStdOutputHandle);
  SetStdHandle(STD_ERROR_HANDLE , prevStdErrorHandle );

  StdFileStream.Free;
  StdFileStream:=nil;
end.

prevStdOutputHandle und prevStdErrorHandle sind gleich Null,
und nur der Form halber mit GetStdHandle abgefragt.

[schand99]

Ich will jetzt nicht Werbung machen.
Im Betrieb nutzen wir seit Jahren eine (gekaufte) 3D-Cad Komponente. Mit der kann man enorm viel Tipparbeit einsparen.
Guck mal da http://www.eastwindsoft.com/de/index.htm
Ist aber eine ActiveX, mit den typischen Vor- und Nachteilen. Und sie strauchelt beim Export von STEP-Dateien, wenn zu viele "Entities" enthalten sind.