Mon, 01/15/2007 - 12:25
For anybody interested, there's an updated version of the (purely) Qt4 OpenCASCADE viewer available on
Thanks to the stirling late-night efforts by Marc Britten, the code has been now ported to one major Linux platform (Ubuntu Edgy).
Whilst the viewer can now load BREP, IGES and STEP files, the demo application is primarily still a test harness for the Qt4 view widget, and should be considered in that light.
If you have any comments, post them into this thread which I am monitoring.
Mon, 03/12/2007 - 13:15
Hi P Dolbey,
I am in need to retrieve dimensional information from STEP file can you help me how to do it.
Thanks and Regards,
Mon, 03/12/2007 - 17:38
Just a couple of points.
Your requirement is not very clear - is this an issue with displaying dimension objects or is it a question of measurements. You need to clarify.
This thread was originally an announcement of a new Qt4 viewer for OpenCascade. There's a lot of *really* clever guys who monitor this forum for queries like yours. They do this in their own time and receive neither remuneration nor very little thanks. Posting this type of request in a thread that may not be relevant to them isn't a good way to get their attention - and your particular problem isn't one I've had much experience with solving.
Your best bet is post a new thread with an explicit subject line and explain in slightly more detail what you are trying to do - then I'm sure the gurus will come rushing to your aid.
Fri, 04/13/2007 - 00:07
I'm attempting to build your viewer on Debian Etch, I had to add the following to the Makefile.Release DEFINES:
-DHAVE_LIMITS_H and -DHAVE_IOSTREAM_H
and add to INCPATH:
The compile bombs out with:
/usr/local/OpenCASCADE6.2.0/ros/inc/FSD_File.hxx:445: error: field ‘myStream’ has incomplete type
Also, what version of STLPort do you have installed?
Tue, 04/17/2007 - 02:45
Check out the code in Standard_Stream.hxx - you possibly need a -DHAVE_FSTREAM_H as well - the relevant code is shown below
#elif defined (HAVE_FSTREAM_H)
// Macro USE_OLD_STREAMS may be defined externally to command
// using old streams on Windows NT; otherwise new streams are used
using namespace std;
#endif /* USE_OLD_STREAMS */
Wed, 04/18/2007 - 18:45
Thanks for the info. I can now compile main.cpp, mainwindow.cpp and QtOCCViewerContext.cpp. The make now bombs out in QtOCCViewWidget.cpp with the following:
QtOCCViewWidget.cpp: In destructor `virtual QtOCCViewWidget::~QtOCCViewWidget()':
QtOCCViewWidget.cpp:102: error: ambiguous default type conversion from `Handle_V3d_View'
QtOCCViewWidget.cpp:102: error: candidate conversions include `Handle_Standard_Transient::operator const Standard_Transient*() const' and `Handle_Standard_Transient::operator Standard_Transient*()'
QtOCCViewWidget.cpp:102: error: type `class Handle_V3d_View' argument given to `delete', expected pointer
For what its worth I've tried g++-3.4 4.0 and 4.1 all
with the same result.
Any help would be appreciated
Wed, 04/18/2007 - 21:48
The "delete" operator for the Handle_V3d_View is explicitly defined in Handle_V3d_View.hxx - this should be included via the #include in QtOpenCascade.h but it looks like this isn't happening on your platform.
Fix 1 - try adding an explicit #include in QtOpenCascade.h
Fix 2 - try adding an explicit #include in QtOCCViewWidget.cpp
Fix 3 - comment out the offending line "//delete myView" - the object is about to trashed anyway in the Widget destructor.
Wed, 04/18/2007 - 22:14
Fix 1 and 2 didn't work, but fix 3 bypassed the
problem. Now I'm getting:
QtOCCViewWidget.cpp:849: error: `min' was not declared in this scope
QtOCCViewWidget.cpp:851: error: `max' was not declared in this scope
QtOCCViewWidget.cpp:857: error: `min' was not declared in this scope
QtOCCViewWidget.cpp:859: error: `max' was not declared in this scope
Possibly another include?
I wonder how mutch Ubuntu differs from Debian.
Wed, 04/18/2007 - 22:38
My min and max macros have come from windef.h on my works PC (using VS2003). They are simple defined as
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define min(a,b) (((a) < (b)) ? (a) : (b))
Try adding these to QtOpenCascade.h or in the QtOCCViewWidget.cpp. I've been rather remiss in keeping in contact with Marc Britten recently but that's because I've too busy at work (and too tired at home). He's probably the best at ansering your last query.
Wed, 04/18/2007 - 23:17
I definitly understand about the workload. Take
your time - I'm in no rush at all.
The viewer now compiles but has problems linking:
release/main.o:(.rodata._ZTV17Message_TraceFile[vtable for Message_TraceFile]+0x30): undefined reference to `Standard_Transient::ShallowDump(stlp_std::basic_ostream >&) const'
release/main.o:(.rodata._ZTV15Message_Printer[vtable for Message_Printer]+0x30): undefined reference to `Standard_Transient::ShallowDump(stlp_std::basic_ostream >&) const'
release/main.o:(.rodata._ZTV25StdSelect_SensitiveText2d[vtable for StdSelect_SensitiveText2d]+0x30): undefined reference to `Standard_Transient::ShallowDump(stlp_std::basic_ostream >&) const'
release/main.o:(.rodata._ZTV24Select2D_SensitiveEntity[vtable for Select2D_SensitiveEntity]+0x30): undefined reference to `Standard_Transient::ShallowDump(stlp_std::basic_ostream >&) const'
collect2: ld returned 1 exit status
make: *** [QtOpenCascade] Error 1
I wonder if this is a problem with StlPort - I'm using 5.0
Thu, 04/19/2007 - 01:40
According to the OCC docs, you don't need STLPort for supported Linux compilers, including gcc 3.4 and 4.0.1 and in my case VS2005.
The docs say
"Starting from Open CASCADE 5.1.2 Open CASCADE is certified with using STL implementation by the supported compilers. Nevertheless the source code can be rebuilt using other implementations (for example STLPort) but Open CASCADE S.A.S. did not undertake any certification actions on such implementations and therefore cannot guarantee reliable work with other implementations."
A couple of questions from a Linuxnoramous.
1. Have you recompiled the OCC libs with the same compiler as the app?
2. Have you tried compiling the app without STLPort?
The offending function is defined in fstandard_transient_proto.hxx as
Standard_EXPORT virtual void ShallowDump(Standard_OStream& ) const;
and Standard_OStream is defined as
#define Standard_OStream ostream
in standard_ostream.hxx. Now I find I'm almost coming back full circle to the -DHAVE_IOSTREAM_H you set in an earlier post, which leads to question 3.
3. Have you tried compiling with -DHAVE_IOSTREAM instead?
I have a feeling you're probably on target with STLPort - the app and libs seem to be at odds with each other. Its obviously easier to make the app compatible with OCC, rather than the other way round, but I don't know how OCC has been compiled on Debian. I'm guessing that mismatched STL versions are leading to different function signatures in the .o files. In essence I think the trick to success is to ensure that both OCC and your app have been compiled with the same compiler directives and STL implementation - but like I said I'm not a Linux developer - perhaps someone else could chip in!
Fri, 04/20/2007 - 20:11
First, to eliminate some variables I compiled both OCC and
the app with first gcc-4.0.4 and then gcc-3.4. Same problem occurred - so I think I can eliminate a version problem (I had previously been using gcc-4.1.1).
I have a definite STL mismatch between OCC and the app.
OCC builds cleanly without STLPort - In fact it won't
compile at all if I config it with STLPort.
The app however is just the opposite - It compiles cleanly
WITH STLPort and gives errors if I try and compile without it. A typical error is:
In file included from /usr/include/c++/3.4/vector:72,
/usr/include/c++/3.4/bits/stl_bvector.h: In member function `void std::vector::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)':
/usr/include/c++/3.4/bits/stl_bvector.h:522: error: expected unqualified-id before '(' token
The offending line in /usr/include/c++/3.4/bits/stl_bvector.h is:
const size_type __len = size() + std::max(size(), __n);
I am not a C++ guru so I don't have a clue whats going on.
Fri, 04/20/2007 - 22:47
Ray, there's 3 things to try
1. Add a new -DQT_NO_STL to the makefile (or DEFINES += QT_NO_DLL in the pro file and re-run qmake etc.)
2. A similar possibility is to add "config -= stl" to the pro file.
3. Finally, you could try a rebuild of qt4 with the -no-stl option added - you can always turn it back for projects with a config += stl in its pro file if needed.
Best I can come up with at the minute.
Fri, 04/20/2007 - 23:42
I've found the problem It was those max and min macros I added to QtOpenCascade.h. Eliminating them and compiling
without STLPort is successful.
I'm now trying to debug a run-time error (at last). Running
terminate called after throwing an instance of 'Aspect_GraphicDeviceDefinitionError'
Fri, 04/20/2007 - 23:50
Tue, 04/24/2007 - 17:09
I'm happy to announce that QtOpenCascade works fine on Debian linux. I've used all gcc versions (3.4, 4.0, 4.4.1) with good results.
For the record the required defines are:
In addition, define -D_OCC64 if building against a 64-bit OCC.
For linking, -ltk needs to be changed to the appropriate tk
version, in my case -ltk8.4
Mon, 04/23/2007 - 20:56
Do you have CASROOT defined? Thats about the only way I've ever ran into that exception. Of course I don't have a ton of experience either.
Tue, 04/24/2007 - 16:44
Having CASROOT defined doesn't help me here since I have the OCC libraries installed in /usr/local/lib. Instead, I
defined CSF_GraphicShr to be /usr/local/lib/libTKOpenGl.so and everyting is fine.
Tue, 04/24/2007 - 16:48
Does that mean its working?
Tue, 04/24/2007 - 17:13
Yes its working fine. See the message I posted above.
Tue, 04/24/2007 - 17:41
Brilliant news - I'm still awed when things likes this work, especially as the code was developed primarily on XP. If its possible, and you are willing, whould it be possible to load up a model snd send me a screen dump. I can be found at peter(at)dolbey(dot)freeserve(dot)co(dot)uk.
Tue, 04/24/2007 - 19:19
Screenshot sent. Let me know if wou get it.
Tue, 04/24/2007 - 20:34
Its in my inbox, but I'll pick it up tonight when I get home.
If you've got the Qt0CC-0.6 version you should be able to load in any of the shapes, BREP, STEP ot IGES from the OCC shape gallery at http://www.opencascade.org/showroom/shapegallery/. Use the "File-Open" menu. If you don't select a "File-New" between opens, each file read will merge onto the current model. This enables you to assemble the pump and shaver pieces. Note that I haven't got that version saving models - I'm currently re-factoring the entire class model (similar to http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/QtOCC-Classes.png but even that is out of data now), and am looking at using the exoTK code for managing i/o.
There's a number of other shapes in the Windows distro of OCC but I don't know if they're in the Linux distro. On your platform I'd expect to see them in /usr/local/OpenCASCADE6.2.0/data
Tue, 04/24/2007 - 22:28
Thanks for the info. I've downloaded a number of models.
I've encountered one problem with the app. The file open dialog
comes up blank, ie no model files are displayed. Entering the
filename manually works ok. Will try to track down.
Wed, 04/25/2007 - 01:46
My version of QTs QFileDialog function doesn't like semicolons between the filter specs ie. BREP (*.brep;*.rle)
Changing the semicolon to a space ( BREP (*.brep *.rle) )
fixes the problem.
Mon, 04/23/2007 - 20:50
min and max should be defined in STL's algorithm
the main problem I've always found with x-platform development is ensuring that you explicitly include everything you use. I tend to get lazy and use something then add the include it the compiler complains.
Wed, 04/25/2007 - 02:00
The X-Window includes had nothing to do with my problems. For some ungodly reason I thought I had to build
against STLPort. Things then when downhill.
The major thing was determining the needed DEFINES. When I built OCC the configure script handled that detail. Pete has chosen to use qmake whith which I am unfimiliar.
Wed, 04/25/2007 - 03:25
sorry I was being lazy again I just meant cross-platform.
Qmake is fairly easy to learn, I didn't know anything when I got the linux port going.
Its nice in that it will auto generate the makefile if you change any of the files associated with it. So all you have to do is edit and run make and it will create the updated make file and then compile as normal.
Fri, 05/29/2009 - 22:54
Do you have windows binaries ?
I would appreciate it very much.