---

Hallo,

ich bin nun komplett auf die NXOpen++ API umgestiegen und bin recht begeistert, vieles fehlt zwar noch aber DAS ist zum ersten Mal der rechte Weg, die alte UGOPEN API dagegen ist wirklich eine Katastrophe, freundlich ausgedrückt. Doch nun stelle ich verdutzt fest, die neue API akzeptiert manch alte Features (wie zB. das SWP104 Feature) nicht und die alte API nicht manch neue (wie zB. die NX5Extrusion).   

Verlangen die da wirklich, dass man seine Applikationen daraufhin auslegt, also alles DOPPELT schreibt?!

Ich hoffe jemand sagt mir, dass ich komplett daneben liege.
Und falls nicht, gibt es ein offizielles Statement dazu?

Liebe Grüsse,
   

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Warum ist die UGOpen C API eine Kater-Strophe? 
Schliesslich wurde UG in C entwickelt und es war über Jahrzehnte die einzige Hochsprache in UG!
Neu-Entwicklungen fliessen ab NX3 nun mal eher in die NXOpen ein, da die Common API nun richtungsweisend ist.

Aber schau Dir mal das folgende Beispiel an:

Zitat:

---

"NX 6.0\UGOPEN\SampleNXOpenApplications\C++\InteropNXOpenWithUFunc"

---

Man kann problemlos NXOpen C++ und UG/Open C miteinander mischen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Overcast,
Ich mag C, aber daran solls nicht liegen. Vielmehr ist deren alte Schnittstelle ein irres Gewusel aus zigtausen über Jahre hinweg überarbeiteten Krumen die alle ihren eigenen Willen kennen und so garnicht zusammenpassen wollen, das stört mich dann schon eher. Also habe ich mich über deren neue C++ API gefreut, die sehr elegant ist wie ich finde. Aber man kann diese API lediglich auf neue Bauteile anwenden, alles was davor kam ist kaum unterstützt. Es scheint also, man ist gezwungen alle Schnittstellen zu benutzen bzw. fast jedes Feature im Programm doppelt zu schreiben.

Und das schon bei simplen Aufgaben. Stell dir vor du schreibst ein Programm, dass alle Bauteile aus einem Verz. auslesen soll um daraufhin die Extrusionsrichtungen anzupassen. UG/Open alleine - geht nicht mehr. NX/Open++ alleine - geht nicht mehr. Du musst also den Code doppelt schreiben. Bei grösseren Projekten nervt es einfach nur.      

Zur Zeit benutze ich also drei Schnittstellen im selben Projekt, UG/Open, UG/Open++ und NX/Open++ ( UF_initialize( ); UgSession::initialize( ); Session::GetSession( ); ). Alleine die Ladezeit ...       

[Diese Nachricht wurde von moles are coming am 07. Okt. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Für mich war UG/Open++ die einzige Kater-Strophe und ein damaliger kläglicher Versuch, C++ zu implementieren.
Den Kram konnte man wirklich nicht gebrauchen.

Gut, die Initialisierung ist doppelt, aber wieso kann man keine alten Bauteile damit verwenden?
Das alte Extruded (SWP104) und das neue Extrude sind halt 2 völlig verschiedene Formelemente.
Bei einer Fallunterscheidung nimmt man dann halt entweder die alte oder neue Funktionalität.

GRIP und die C API wird nicht weiterentwickelt, weil vermutlich schlichtweg die Resourcen fehlen, um alle Interfaces noch weiterhin parallel zu bewerkstelligen (GRIP, OpenC, OpenC++, NXOpenC++, VB.NET, CS.NET, C++.NET, JAVA).

Es scheint, dass die Common API ab NX3 nach dem aktuellen Stand der interaktiven Software ausgerichtet wurde.
Für alles davor gibt es bei .NET VB/CS/C++ die Wrapper-Klassen, bei NXOpen C++ gibt es die C API als Ergänzung für alte Features.

Der Übergang von alt nach neu ist momentan vielleicht etwas aufwendiger, aber ca. ab NX10 wird sich der Aufwand relativieren 

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP