1-Visitor

Question

Worried that I am on the edge of the universe all alone

Forum|Forum|15 years ago
November 11, 2010
25 replies
4351 views

I have been doing a lot of customization of Pro/E lately using J-Link and EFX.

It seems that there are not very many people doing this. I say that
because whenever I have a problem there are very few people that
answer questions on the mailing lists and more worrysome is that PTC
can't fix the problems either.

Anyone out there???

Jlink

Show previous replies

jkent

1-Visitor

I think PTC is missing the boat completely with the customization issue.

Our custom applications are all Java based using a combination of Java,
J-Link, and Windchill. We also use other 3rd party API's such as JExcel,
Apache HSSF, etc. and they work extremely well for us. With Windchill
being Java based it only makes sense to have a Java API for Pro E. It
will be interesting to see what happens when Creo ships.

Guess I an open source nut. I just think of the possibilities of having
an app store or community that shares their custom applications.

BrianKrieger

10-Marble

Now that (app store) sounds nice (although my company would likely balk
at that type of sharing).

I'm very selfish, so I hope they stay with an open source platform. If
we have to pay for it, it would almost assuredly get put back into our
IT umbrella (love our IT group, but response/reaction time is not
normally their strong suit). One would think that the Windchill
interface would drive to a java-based interface, but that could be the
underpinnings with a ui written for the development (think Eclipse,
perhaps). I, too, would love to see/know what the development
environment is for Creo(r) (I am just now beginning to start to attempt
a first look investigatory evaluation of the Windchill customization, so
maybe I should stop now......).

And, just to make a quick comment on training, no matter what you do for
training (PTC, Felco, other), invest in learning the language first.
For me, I wish I had known the java language better prior to taking a
JLink course. Now that I am more comfortable with java, things come a
little easier to me, but I'm by no means an expert (I still do casts
without ensuring object type....gasp! ;-). That said, there are a ton
of resources out there, but I really got a lot out of:

ptc-687089

1-Visitor

When will the language decision be released?

I am finishing an Intro VB.net course this semester, and was planning to move on to the next, more-advanced course next semester. I don't want to be wasting my time. My plan was to update my Excel VBA die design program, which communicates with Pro/E through text files, to VB.net, and communicate with Excel and Pro/E directly through Visual Studio using VSTO.

How can anyone make reasonable plans with PTC jerking them around like this?

jkent

1-Visitor

How about it PTC any comments. Users are looking for answers.

FV_01

Hi all,
Great discussion...
I think it would be a good idea to take a survey of our needs for the upcoming January TC meeting.

The first question would be: what applications are we developing? And the second question would be: who are we?

Since we are indeed are lonely people in our respective places of employment we need at least to have some understanding of what our brethren does.

To start... who we are? Some of us are engineers/designers/drafters/analysts/nc-programmers who are trying to speed up design process and really got sick and tired of ten million clicks required to accomplish quite a large number of interactive tasks, some of us are database application developers mostly dealing with the data extraction from pro/e models or PDM databases, some of us are interactive application developers who are dealing with geometry of pro/e models as well as the non geometric data as well as end user interactions with the Pro/E and some of us are system administrators dealing with the tasks of mass processing of the vast amount of pro/e models and/or PDM related data. ( please, add as needed...)

From my point of view, C/C++ programming with Pro/Toolkit and dealing mostly with Pro/Engineer and not as much with Windchill, application types fall into several major categories:

- Data extraction from pro/e models, storing it into databases, retrieving data from databases into pro/e models, something which could be dealt by ODBC and its descendants, back-end could be anything from oracle db to excel files or text files. This type of programming mostly deals with parameters, dimension values, part properties, annotation text values, BOMs, PDM revisions and submissions and so on. Synchronous or asynchronous does not really mater, speed is not an issue (relatively speaking). Those tasks do not require an interactive session of Pro/Engineer. My observation is that the majority of those applications are written in Java. IMHO, the challenges of functionality could be simply solved by PTC providing some type of ODBC (ADO, etc...) connector for pro/e file types (free or otherwise) which would address retrieval/storage of metadata directly to/from Pro/E file types... No special or specific IDE is needed, development languages could be anything from C++,C#, Java to Perl, Ruby... Pro/E data file structure would have to be modified though...

- Catalog / Configurator type of applications, which is automatic modification of predefined or designated parameters/dimension/annotations using some kind of custom developed GUI which leads to geometry modifications of the Pro/E models. It is somewhat related to database type of applications but surely requires Pro/E session either in a background or in a full interactive state. Currently it is handled reasonably well by Pro/Toolkit or J-Link or WebLink...

-Pro/Engineer and PDM system administration tasks, which is mostly related to mass updates/changes of zillions of models, drawing format replacements, drawing option file replacement, relations modification, pro/program mass editing, family table updates, UDF libraries, global editing of pattern tables, file system changes and so on, something for which a frustrated sysadmin would hire summer interns to do a lot of typing... Currently handled by sysadmins, interns, IT people and occasionally by Pro/Toolkit or J-Link applications. It requires either an interactive Pro/E session or a background session or metadata extraction and/or modification... Custom GUI are almost never got used. Speed ,very often, is an issue, and in those occasions synchronous dlls are better suited for the task...

- interactive applications for Pro/E design/modeling/nc-programming process, process ‘wizards’, automation utilities. The type of applications which requires a user input as well as interactive Pro/E session and run as synchronous libraries in real time, dealing with the geometry and metadata creation and modification, custom GUIs and workflows, where the speed is the major issue. Most of them developed with Pro/Toolkit and, probably, C or C++ is appropriate language... The existing Pro/Toolkit functionality is quite adequate for model data access and modification and interaction with some black holes in API which are constantly filled and eliminated by Pro/Toolkit API development team. Pro/Toolkit falls short in GUI development and it is a hassle for synchronous application programming... If an application runs asynchronously than it could rely on its own GUI. There are hacks for synchronous dlls to spawn its own process which handles GUI elements...

- Pro/E interactive automation tasks, custom GUI and workflow, this is the most underdeveloped and neglected area of customization... Countless number of engineers and designers are struggling with the simple automation tasks which could be taken care by built-in scripting language. Ironically, Pro/E as it was prior to 2001 version was way better of handling such tasks. I could only speculate why, but it seems that Pro/E used to have a well defined command processor linked with the GUI elements ( screen menu items). When dialog boxes were introduced those links were replaced by dialog box element names and values which drastically affected in a negative way the robustness of scripting. The old command processor did have a mechanism for custom menu creation albeit it was not fun to work with.

Side note
The same problem exists for custom GUI development for scripting as with the Pro/Toolkit or J-link and the problem is that the Pro/E uses an internally developed window system manager which probably could be traced back to X-Window X11 system. That precludes the use of-the-shelf GUI elements and IDEs in case of scripting or synchronous dlls. There was a glimpse of hope with WebLink - web browser handling GUI elements and a browser process seemed to be synchronous with the Pro/E session so it was running substantially faster comparing to J-link. But it did not become a popular choice...

Thanks.
Feliks Veysman.

ptc-687089

1-Visitor

Hi all,

Sorry, I did not mean to start a new thread with my email post. I thought my email would be appended to this thread. Whoever is in charge, please move it here. My post was:

Can we get back to the point here? You guys who have access to Toolkit are all set. Those of us who do not (and could never get our administrations to ante up $20K - probably not even $20) are the ones who are really on the edge of the universe all alone. The Pro/E free APIs gave us at least some entry into the game, to construct our modest applications. Now PTC wants to take even that away from us. They only provided the free APIs to answer the challenge from Solidworks and Inventor, which provided free MS VBA APIs (akin to Excel VBA, the most popular engineering programming API in the world). And the Java Jlink API seemed like a viable alternative, until one considers that it does not work with the MS Office applications via Visual Studio. And there is no literature base for Java in conjunction with Visual Studio - there is no market for it. Microsoft has discontinued J# (their interim version of Java) according to Wikipedia, so those of us who work with Excel (and most engineering programmers do), have no alternative.

If PTC wanted to consolidate their languages, why didn't they provide a free C# API? I have heard that it is a virtual copy of Java (which would be similar to supporting Jlink), and it is a native, supported language within Visual Studio, which works with MS Office (and, obviously, Excel) through VSTO.

Regards,

Dave Rosenbaum

pwilliams-3

13-Aquamarine

Dave,
PTC has to ask themselves a few questions when making a language choice.
Consider these...

1. What is a language that a lot of people in the community know? (What
language has been around a long time)

2. What language is easy to implement as an API that abstracts from the
core product language implementation?

3. What language executes fast enough for those users who need to perform
complex mathematical/geometry calculations?

4. What language is versatile enough to interface with many other
systems/languages?

I'm sure there are other questions they have to ask themselves but these
are a few off the top of my head. So here are my suggested answers...

1. C/C++ has been around much longer than than Java, C# (.NET languages),
Ruby, Python, <your favorite=" language=" here=">. There are tons of C/C++
programmers out there today therefore the learning curve should be
relatively short. Just the time it takes to learn the API vs. the API +
a new language.

2. To provide the ability to automation Pro/ENGINEER with Java for
instance, requires the spawning of a message passing interface as well as
spawning the JRE. This results in slower performance over a C/C++ API.
This increases the complexity of the implementation of the API and the
ability to support it.

3. The core of Pro/ENGINEER is written in C/C++ because it is no secret
that code compiled into binary for a specific architecture blows away an
interpreted language that executes on some sort of run-time environment
like many of the new languages (.NET, Java, Perl, etc). Pro/ENGINEER has
to perform a significant amount of mathematical calculations that just
doesn't lend itself well to these other languages.

4. I do concede that with IDE's from Oracle or MS it is easier with the
new interpreted languages to interface with web services, databases, and
other systems however that doesn't mean it's impossible with the C/C++
language. The Platform SDK has the C/C++ APIs available to create these
interfaces. It may be a bit more work but it's possible.

Now comes the questions of how the API is presented to the community. IMHO
"open" means FREE, NOT HIDDEN, NOT LIMITED. Here is my utopia...

1. CREO applications all share the same core engine aka Granite.
2. PTC creates an API that abstracts from the core engine.
3. PTC writes ALL CREO applications with the abstracted API.
4. PTC releases the abstracted API (untouched) to the community for FREE.

This would result in the community being able to create an "App Store"
where any kind of application could be shared for free or for a price. Any
vendor company could choose to create much larger solutions much like they
do today. This model, in my opinion, follows much of what other products
are doing today. MS gives away it's APIs (Platform SDK. the IDE was not
free but even now there are Express versions of that) and what
happened???? The software development community created thousands of
small to large applications and now the desktop is "owned" by MS. It's
like freedom vs. slavery. Give the people freedom, freedom of choice
(freedom to program) and the people/society will flourish.

PATRICK S WILLIAMS
Information Technology
Mechanical Engr Solutions
Missile Systems
Raytheon Company

+1 520.545.6995 (office)
+1 520.446.0244 (pager)
+1 520.545.6399 (fax)
-

6221 S Palo Verde Rd
Tucson, AZ 85706-5093 USA
www.raytheon.com

Follow Raytheon On

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this
message in error, please so advise the sender by reply e-mail and delete
this message. Thank you for your cooperation.

ptc-687089

1-Visitor

Patrick,

The point is not the language choice - it is accessibility to Excel (and the other Microsoft Office products)via Visual Studio through VSTO. If Pro/E provided a free C++ API, I would be taking a course in C++ right now, instead of VB.net. VB.net was more advantageous, I'll admit, because my existing Excel VBA code is more easily converted. But I would have settled for C++, because C++ is a supported, native language within Visual Studio, accessible to the MS Office products via VSTO.

I get that Microsoft provides these freebies as a hook, but I don't have the luxory of battling Microsoft. I need something that works for my situation.

But the point is that I can't get access to Toolkit. If Pro/E provides a free C++ API, which is accessible through Visual Studio, then, of course, I would compromise for that. But you haven't said that, as far as I can understand your post.

Regards,

Dave Rosenbaum

pwilliams-3

13-Aquamarine

Dave,
I was trying to explain my point that PTC can't choose the VB API because
of the questions that needed to be answered. VB is not a viable option
because it's interpreted plus a run time environment (CLR) is needed to
execute the code. It's too complex if the goal is to narrow down the API
offering to a single API. It remains to be seen what choice will be made
regarding how the API is presented to the public once the language is
chosen.

As for the interoperability to Office apps, that is readily available
through standard MS libraries. However; I do see your point that you want
a free API to access Pro/ENGINEER data and then transfer it to Office
applications.

PATRICK S WILLIAMS
Information Technology
Mechanical Engr Solutions
Missile Systems
Raytheon Company

+1 520.545.6995 (office)
+1 520.446.0244 (pager)
+1 520.545.6399 (fax)
-

6221 S Palo Verde Rd
Tucson, AZ 85706-5093 USA
www.raytheon.com

Follow Raytheon On

This message contains information that may be confidential and privileged.
Unless you are the addressee (or authorized to receive mail for the
addressee), you should not use, copy or disclose to anyone this message or
any information contained in this message. If you have received this
message in error, please so advise the sender by reply e-mail and delete
this message. Thank you for your cooperation.

jkent

1-Visitor

Dave,

Have you tried using JExcel or Apache POI. We use Apache POI in
combination with JLink to read and write to excel files.

Show more replies

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded