Every now and then, a CoCreate Modeling user needs some functionality which isn't in the product
yet, or at least not precisely in the shape and form she needs it. For example, in a recent
forum discussion, someone
asked for a way to batch-convert CoCreate Modeling package files into STEP format.
The
CoCreate Task Agent provides
such functionality, but since it is an add-on module
at extra cost, only some customers have it available to them. But that's no reason for despair,
as it's pretty simple to add new functionality to the product.
Here's my take on the problem. My solution doesn't have any kind of glitzy UI,
it doesn't handle errors, it's not optimized for performance - but it shows how the
approach works, and that's all I wanted to accomplish.
;; (C) 2009 Claus Brod
;;
;; Demonstrates how to convert models into STEP format
;; in batch mode. Assumes that STEP module has been activated.
(in-package :clausbrod.de)
(use-package :oli)
(export 'pkg-to-step)
(defun convert-one-file(from to)
(delete_3d :all_at_top)
(load_package from)
(step_export :select :all_at_top :filename to :overwrite)
(undo))
(defun pkg-to-step(dir)
"Exports all package files in a directory into STEP format"
(dolist (file (directory (format nil "~A/*.pkg" dir)))
(let ((filename (namestring file)))
(convert-one-file filename (format nil "~A.stp" filename)))))
To use this code:
- Run CoCreate Modeling
- Activate the STEP module
- Load the Lisp file
- In the user input line, enter something like
(clausbrod.de:pkg-to-step "c:/allmypackagefiles")
For each package (
*.pkg
) file in the specified directory, a STEP file will be generated in the
same directory. The name of the STEP file is the original filename with
.stp
appended to it.
In
pkg-to-step
, the code iterates over the list of filenames returned from
(directory)
. For each package file,
convert-one-file
is called, which performs
the actual conversion:
Step |
Command |
Delete all objects in memory (so that they don't interfere with the rest of the process) |
delete_3d |
Load the package file |
load_package |
Save the model in memory out to a STEP file |
step_export |
Revert to the state of affairs as before loading the package file |
undo |
For each of those steps, we use one of the built-in commands, i.e.
delete_3d
,
load_package
,
step_export
and
undo
. (These are the kind of commands which are captured in a recorder
file when you run CoCreate Modeling's recorder utility.) Around those commands, we use
some trivial Common Lisp glue code - essentially,
dolist over
the results of
directory. And that's all, folks
Astute readers will wonder why I use
undo
after the load operation rather than
delete_3d
the model.
undo
is in fact more efficient in this kind of scenario, which is
an interesting story in and of itself - and shall be told some other day.
This weekend, I finally bit the bullet: I went over all
CoCreate Modeling pages
on the site, and fixed most references to the old product
name "OneSpace Modeling". John Scheffel, who maintains the International
CoCreate Users Group
site at http://www.cocreateusers.org, had sent me a friendly note about all those dated
names on my site - precisely the kind of kick in the behind
that I sorely needed to finally get the job done. Thanks, John!
And by the way, John, thanks as well for all your work
to keep the user group site going strong! When you, dear reader, stop by at the
CoCreate user group forum next time, drop
John a line to say "thank you". He deserves it.
I'm not done with all the renaming on the site yet; for example, there are a number
of pages which I called "OsdmSomething" (silly me). "Osdm" is the abbreviation for
"OneSpace Designer Modeling", which is yet another older name for what we now
know as "CoCreate Modeling"...
As you can see, "CoCreate Modeling" was rechristened a lot in the past:
Official name | Colloquial | Versions | When |
HP PE/SolidDesigner | SolidDesigner | 1-7 | 1992-1999 |
CoCreate OneSpace Designer Dynamic Modeling | ? | 11 | 2001-2002 |
CoCreate OneSpace Designer Modeling | OSDM | 11.6-14 | 2002-2006 |
CoCreate OneSpace Modeling | OneSpace Modeling | 15 | 2007 |
PTC CoCreate Modeling | CoCreate Modeling | 16 and later | 2008- |
CoCreate SolidDesigner | SolidDesigner | 8-9 | 2000-2001 |
This is from memory - corrections most welcome. CoCreate users out there, what's your
favorite product name?
I'm not a creative marketeer - just a lowly engineer and therefore not too
imaginative. You see, I call my apples apples, my typos typos, and my bugs features. Simple and
straightforward, that's what
us engineers are like.
So personally, I would never have fiddled with the product name at all.
Granted,
some name changes were inevitable. After all, we separated from HP in 1996 and
became independent as CoCreate, and so we couldn't use the "HP" prefix anymore, of course.
And in late 2007, PTC acquired us, and our products needed to be integrated into PTC's portfolio.
My own - way too simplistic - engineering approach to branding would have been:
- HP PE/SolidDesigner (colloquially: SolidDesigner)
- CoCreate SolidDesigner (colloquially: SolidDesigner)
- PTC CoCreate SolidDesigner (colloquially: SolidDesigner)
In fact, many of our customers still call the product SolidDesigner; apparently,
that name stuck with people. And not quite incidentally, the name of the main executable
on disk is
SolidDesigner.exe
Anyway - I'll have to admit that I start to like "CoCreate Modeling" as well. It's reasonably
short, simple to remember, alludes to what the product does, and it reminds users of our
past as CoCreate - which is a nice nostalgic touch for old f*rts like me who've
been with the team for almost two decades now...
Both at work and on this site, I use TWiki as my wiki engine of
choice. TWiki has managed to attract a fair share of plugin and add-on writers,
resulting in wonderful tools like an add-on which integrates KinoSearch,
a Perl library on top of the Lucene search engine.
This month, I installed the add-on at work. It turns out that in its current state,
it does not support Office 2007 document types yet, such as
.docx
,
.pptx
and
.xlsx
,
i.e. the so-called "Office OpenXML" formats. That's a pity, of course, since
these days, most new Office documents tend to be provided in those formats.
The KinoSearch add-on doesn't try to parse (non-trivial) documents
on its own, but rather relies on external helper programs which extract
indexable text from documents. So the task at hand is to write such
a text extractor.
Fortunately, the
Apache POI project just released
a version of their libraries which now also support OpenXML formats, and
with those libraries, it's a piece of cake to build a simple text extractor!
Here's the trivial Java driver code:
package de.clausbrod.openxmlextractor;
import java.io.File;
import org.apache.poi.POITextExtractor;
import org.apache.poi.extractor.ExtractorFactory;
public class Main {
public static String extractOneFile(File f) throws Exception {
POITextExtractor extractor = ExtractorFactory.createExtractor(f);
String extracted = extractor.getText();
return extracted;
}
public static void main(String[] args) throws Exception {
if (args.length <= 0) {
System.err.println("ERROR: No filename specified.");
return;
}
for (String filename : args) {
File f = new File(filename);
System.out.println(extractOneFile(f));
}
}
}
Full Java 1.6 binaries are
attached;
Apache POI license details apply.
Copy the ZIP archive to your TWiki server and unzip it in a directory of your choice.
With this tool in place, all we need to do is provide a
stringifier plugin to
the add-on. This is done by adding a file called
OpenXML.pm
to the
lib/TWiki/Contrib/SearchEngineKinoSearchAddOn/StringifierPlugins
directory in the TWiki server installation:
# For licensing info read LICENSE file in the TWiki root.
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details, published at
# http://www.gnu.org/copyleft/gpl.html
package TWiki::Contrib::SearchEngineKinoSearchAddOn::StringifyPlugins::OpenXML;
use base 'TWiki::Contrib::SearchEngineKinoSearchAddOn::StringifyBase';
use File::Temp qw/tmpnam/;
__PACKAGE__->register_handler(
"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", ".xlsx");
__PACKAGE__->register_handler(
"application/vnd.openxmlformats-officedocument.wordprocessingml.document", ".docx");
__PACKAGE__->register_handler(
"application/vnd.openxmlformats-officedocument.presentationml.presentation", ".pptx");
sub stringForFile {
my ($self, $file) = @_;
my $tmp_file = tmpnam();
my $text;
my $cmd =
"java -jar /www/twiki/local/bin/openxmlextractor/openxmlextractor.jar '$file' > $tmp_file";
if (0 == system($cmd)) {
$text = TWiki::Contrib::SearchEngineKinoSearchAddOn::Stringifier->stringFor($tmp_file);
}
unlink($tmp_file);
return $text; # undef signals failure to caller
}
1;
This script assumes that the
openxmlextractor.jar
helper is located at
/www/twiki/local/bin/openxmlextractor
; you'll have to tweak this path to
reflect your local settings.
I haven't figured out yet how to correctly deal with encodings in the stringifier
code, so non-ASCII characters might not work as expected.
To verify local installation, change into
/www/twiki/kinosearch/bin
(this is
where my TWiki installation is, YMMV) and run the extractor on a test file:
./ks_test stringify foobla.docx
And in a final step, enable index generation for Office documents by adding
.docx
,
.pptx
and
.xlsx
to the Main.TWikiPreferences topic:
* KinoSearch settings
* Set KINOSEARCHINDEXEXTENSIONS = .pdf, .xml, .html, .doc, .xls, .ppt, .docx, .pptx, .xlsx
So the graphics driver for your graphics card seems to be really buggy, and you cannot get it work at all
with CoCreate Modeling. What can you do?
First, check the latest driver versions provided by the graphics card vendor. If you already have the
latest version, try a version which was previously certified either by PTC/CoCreate or one of the
other large CAD vendors. Also, remember to switch the graphics driver into
"CoCreate Modeling" mode if the driver has such an option.
If the problem persists, and the graphics card is supported by PTC, contact PTC for help. They will work with
the graphics card vendor to fix the problem. If the card is unsupported, contact the graphics card
vendor directly.
But if all this fails, or if you want to take a quick stab at the problem,
you can also have CoCreate Modeling ask the graphics driver to turn off hardware
acceleration for 3D graphics. This will often bypass the buggy parts in the graphics driver,
and the problem will go away. Things will also slow down, of course, i.e. 3D viewing operations
won't be as snappy as before. On most systems, however, you will still be able to work
with small to medium assemblies just fine.
All you need to do to disable hardware acceleration in CoCreate Modeling is set an environment
variable called
SDPIXELFORMAT
, and give
it a value of
SOFTWARE
. To set the environment variable, use the System Control Panel.
Click sequence in Windows XP:
- Start/Control Panel
- Run
System
control panel
- Select the
Advanced
tab
- Click "Environment Variables".
Click sequence in Vista:
- Start/Control Panel
- Click
System and Maintenance
, then System
- Click
Advanced System Settings
; this may pop up a user-access control dialog which you need to confirm
- Click
Environment Variables
Now create a new environment variable
SDPIXELFORMAT
and set the value to
SOFTWARE
.
At this year's Java forum in Stuttgart,
I was one of 1100 geeks who divulged in
Suebian Brezeln and presentations on all things Java.
After a
presentation on Scala,
I passed by a couple of flipcharts which were set aside for birds-of-a-feather (BoF)
sessions. On a whim, I grabbed a free flipchart and scribbled one word:
Clojure. In the official program, there was no presentation
covering Clojure, but I thought it'd be nice to meet a few people who, like me,
are interested in learning this new language and its concepts!
Since I had suggested the topic, I became the designated moderator for this session. It
turned out that most attendees didn't really know all that much about Clojure or Lisp - and so
I gravitated, a bit unwillingly at first, into presentation mode. Boy, was I glad that right
before the session, I had refreshed the little Clojure-fu I have by reading an
article or two.
In fact, some of the folks who showed up had assumed the session was on clo
sures
(the programming concept)
rather than Clo
jure, the language
But the remaining few of us still had a spirited
discussion, covering topics such as dynamic versus static typing, various Clojure language
elements, Clojure's Lisp heritage, programmimg for concurrency, web frameworks, Ruby on Rails,
and OO databases.
To those who stopped by, thanks a lot for this discussion and for your interest.
And to the developer from Bremen whose name I forgot (sorry): As we suspected, there is
indeed an alternative syntax for creating Java objects in Clojure.
(.show (new javax.swing.JFrame)) ;; probably more readable for Java programmers
(.show (javax.swing.JFrame.)) ;; Clojure shorthand
Previous month: Click
here.
to top