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

[lococnc]

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???

[lheller]

You are not alone. I was thrown into working with Pro/Toolkit and man... what a learning curve. Especially without any formal training on Pro/E, Pro/Toolkit, or C.

I am currently attempting to port the C Toolkit codeover to VB, and the VB API documention isfairly sparse in parts. Google isn't your friend either, since most searches return only two hits: the WF4 and WF5 VB API PDFs.

Ah well... weforge ahead, because when it works, it's cool.

[pwilliams-3]

If you're looking for Pro/TOOLKIT training I found this on the net.

[Cosmo]

Try Sigmaxim's SmartAssembly tool. It has all the capabilities of tooolkit and then some. But it's designed for non-programming proe users to use.

[jkent]

We are right there with you. We have a lot invested in Java, J-Link, and
the Windchill API. We've developed some pretty cool applications using
these technologies. I wish PTC would figure out a way to give us a
complete set of methods for J-Link and not just a sub set. I understand
that being able to license Toolkit and charge $20k pays a lot more bills
than giving away J-Link for free. Surely someone could come up with a
solution. Are you a member of the technical committee? Might be worth
joining to get your voice heard by PTC and let them know that there are
J-Link users out there.

[pwilliams-3]

The Customization TC has discussed this very topic at length with PTC and
basically it comes down to Joe's point. Pro/TOOLKIT and it's advanced
capabilities over the PFC APIs is a revenue stream of license purchases
and maintenance which amounts to a significant dollar figure. However;
this argument will soon be over. With the CREO product, PTC is changing
it's direction on APIs and they won't be supporting the 4 APIs that
currently exist today (Pro/TOOLKIT, J-Link, WebLink, VB API). They will
only be supporting a single API which will reduce and consolidate their
efforts of development and support. There are two sides to this coin.

1) User's who extensively use the APIs that are going away will have to
migrate their programs and possibly be paying for new licenses of the
supported API.
2) The community will get much better support and development activities
because of the consolidation of effort.

I, for one, am in favor of this move because the TC has for years
complained about the lag of support in the APIs for functionality that was
readily available in the standard UI. Hopefully with the CREO
architecture, ALL of the applications will be built on top of this API
much like a .NET Framework or JRE. It definitely coincides with the claim
that CREO is open, per Brian Shepard in the CREO launch webcast.

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.

[lococnc]

That is a huge problem. We won't pay for a toolkit like product. It is hard
enough to keep the Solidworks advocates at bay, if the free API's go away
that will suck.

PTC, if you are listening, pick a language, any language (but might I
suggest Java or VB) and be sure Creo supports it for free. Otherwise, why
would we move to it again>?

On Thu, Nov 11, 2010 at 4:35 PM, Patrick S Williams <
-> wrote:

> The Customization TC has discussed this very topic at length with PTC and
> basically it comes down to Joe's point. Pro/TOOLKIT and it's advanced
> capabilities over the PFC APIs is a revenue stream of license purchases and
> maintenance which amounts to a significant dollar figure. However; this
> argument will soon be over. With the CREO product, PTC is changing it's
> direction on APIs and they won't be supporting the 4 APIs that currently
> exist today (Pro/TOOLKIT, J-Link, WebLink, VB API). They will only be
> supporting a single API which will reduce and consolidate their efforts of
> development and support. There are two sides to this coin.
>
> 1) User's who extensively use the APIs that are going away will have to
> migrate their programs and possibly be paying for new licenses of the
> supported API.
> 2) The community will get much better support and development activities
> because of the consolidation of effort.
>
> I, for one, am in favor of this move because the TC has for years
> complained about the lag of support in the APIs for functionality that was
> readily available in the standard UI. *Hopefully* with the CREO
> architecture, ALL of the applications will be built on top of this API much
> like a .NET Framework or JRE. It definitely coincides with the claim that
> CREO is *open*, per Brian Shepard in the CREO launch webcast.
>
> *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* [image: YouTube]<">http://www.youtube.com/user/raytheoncompany>
> [image: Facebook] <">http://www.facebook.com/Raytheon> [image: LinkedIn]<">http://www.linkedin.com/companies/raytheon>
> [image: Dual Band podcasts] <">http://www.raytheon.com/newsroom/podcasts>
>
> [image: Raytheon Sustainability]
> *
> 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.*
>
>
> From: Joe Kent <jkent@rdleverage.com> To: Michael Gamber <
> ->, ProE Customization List <
> -> Date: 11/11/2010 03:23 PM Subject: [proecus] -
> RE: Worried that I am on the edge of the universe all alone

[pwilliams-3]

I understand your frustration but I think the train has already left the
station on the decision as to what language should be used. PTC must have
been working on CREO for quite some time. By the time the community hears
about the change of direction I'm sure much of the decisions have already
been made.

I just hope that the API is a much better implementation of Pro/TOOLKIT or
PFC. My complaints about Pro/TOOLKIT is that it's a C API versus a C++ OO
API. Pro/ENGINEER is written in C++ for sure (it has to be fast, can't be
Java) so why can't those classes be available in some form to users. PFC
is slow and complicated to work with. The programmer has to know what
factory class to use and how to cast the results properly to get the
object handle they want. Both APIs could use a lot of work in the
documentation dept. as well. The person in charge of the API at PTC,
IMHO, should take the experience of the user into account first rather
than the experience of their internal developers who are supporting it. I
know it takes some balancing but I really think they could do a better job
than they have in the past.

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.

[lococnc]

If the train has indeed left then it would be nice if PTC would announce it
so those of us that are going down the customization road will know if we
are wasting our time or not.

I have some pretty powerful stuff already developed and it will be a deal
killer for us to move to CREO if I can't do the same things I have already
done.

On Thu, Nov 11, 2010 at 5:06 PM, Patrick S Williams <
-> wrote:

> I understand your frustration but I think the train has already left the
> station on the decision as to what language should be used. PTC must have
> been working on CREO for quite some time. By the time the community hears
> about the change of direction I'm sure much of the decisions have already
> been made.
>
> I just hope that the API is a much better implementation of Pro/TOOLKIT or
> PFC. My complaints about Pro/TOOLKIT is that it's a C API versus a C++ OO
> API. Pro/ENGINEER is written in C++ for sure (it has to be fast, can't be
> Java) so why can't those classes be available in some form to users. PFC is
> slow and complicated to work with. The programmer has to know what factory
> class to use and how to cast the results properly to get the object handle
> they want. Both APIs could use a lot of work in the documentation dept. as
> well. The person in charge of the API at PTC, IMHO, should take the
> experience of the user into account first rather than the experience of
> their internal developers who are supporting it. I know it takes some
> balancing but I really think they could do a better job than they have in
> the past.
>
> *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* [image: YouTube]<">http://www.youtube.com/user/raytheoncompany>
> [image: Facebook] <">http://www.facebook.com/Raytheon> [image: LinkedIn]<">http://www.linkedin.com/companies/raytheon>
> [image: Dual Band podcasts] <">http://www.raytheon.com/newsroom/podcasts>
>
> [image: Raytheon Sustainability]
> *
> 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.*
>
>
> From: Michael Gamber <-> To: Patrick S Williams
> <-> Cc: Joe Kent <jkent@rdleverage.com>,
> ProE Customization List <-> Date: 11/11/2010 03:41
> PM Subject: [proecus] - RE: Worried that I am on the edge of the universe
> all alone

[dandersonjr]

Just a couple of thoughts,



On soap box

Just like all Microsoft apps, there needs to be a free api dev environment.
Look at excel and word vb macros.
Pro/e macros don't even come close to the power of theses macros. And that
environment needs to be open source.
If it's not PTC will take a hit just like Microsoft will in the upcoming few
years. Android, first cell phones then PC's.



Our company went with a non PTC pdm system a few years ago. I was pro PTC at
the time.
Having dealt with PTC not quickly responding to our needs and incorporating
functionality that would save us time and money.
They seem to just want to milk things out. I like how they say features are
new when they have been in the software
for a year or two and they just make a minor tweak to the function L



PTC

Give us the real tools we needed yesterday, today, and tomorrow to us today.
Not 2 years or 10 years milking out things you have been.
Look at what ptc's a cad system with fea, mechanism, surface, pdm cost to
day if you were to buy it as an individual and the maintenance cost.
Trying to compete with some off shore houses is not fun with what you are
doing today.

So Shape Up or Ship Out.
I have no problem moving to another software manufacture to stay competitive
and get the tools I need today.
It's a very weak economy and I don't see it getting any better soon,
Possibly worse.





Off soap box



Don A
on pro/e since release 11 or earlier it's been a long time

[bfrandsen]

As the whole Windchill suite of products are Java based a Creo Java API seems obvious as well as the C++ API.

Not sure about the VB. Might have been thrown in due to PTC's close relations with Microsoft. Only runs asynchronous.

The WebLink API is only valid in the embedded browser running in the same memory space. So the new options in Creo elements/Pro to run the browser in seperate memory space or use Firefox effectively disables WebLink.

I see VB and WebLink as very weak candidates for surviving the Creo transition and only have a few WebLink applications to reinvent.

If PTC want to licens the Java API they definately have to throw in the full functionality as we have in Pro/TOOLKIT today and even extend it to cover much more of the functionality availablethrough the interactive UI.

Perhaps these new APIs could be role based as well, so you only get the functionality availble in the apps you use.

Bjarne Frandsen

In Reply to Patrick Williams:

The Customization TC has discussed this very topic at length with PTC and
basically it comes down to Joe's point. Pro/TOOLKIT and it's advanced
capabilities over the PFC APIs is a revenue stream of license purchases
and maintenance which amounts to a significant dollar figure. However;
this argument will soon be over. With the CREO product, PTC is changing
it's direction on APIs and they won't be supporting the 4 APIs that
currently exist today (Pro/TOOLKIT, J-Link, WebLink, VB API). They will
only be supporting a single API which will reduce and consolidate their
efforts of development and support. There are two sides to this coin.

1) User's who extensively use the APIs that are going away will have to
migrate their programs and possibly be paying for new licenses of the
supported API.
2) The community will get much better support and development activities
because of the consolidation of effort.

I, for one, am in favor of this move because the TC has for years
complained about the lag of support in the APIs for functionality that was
readily available in the standard UI. Hopefully with the CREO
architecture, ALL of the applications will be built on top of this API
much like a .NET Framework or JRE. It definitely coincides with the claim
that CREO is open, per Brian Shepard in the CREO launch webcast.

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]

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]

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]

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]

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

[FV]

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]

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]

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]

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]

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]

Dave,



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

[ptc-687089]

Patrick,

Perhaps it is my limited IT educational background - I am a mechanical engineer who does programming.But the only accessibility to MS Office is through VSTO (Visual Studio Tools for Office), which I was planning to study next. If there is another way to do this, I don't know about it, and I don't know where to go to learn about it.

Regards,

Dave Rosenbaum

[ptc-687089]

Joe,

As for JExcel, I looked that up, and it is a hook to the .com framework version of Excel. This product, like Excel VBA, is doomed to obsolesence, because it uses the old .com framework. I need access to the Excel object model, and I need to take programming variables (primarily dimensions) calculated in an Excel program, presumably running through Visual Studio, and pass them to the Pro/E object model somehow. I had planned to use the Pro/E Visual Basic API, which was accessible, through the connection mechanism, from Visual Studio. What can I use now, if PTC eliminates this?

As for Apache POI, I don't really know what that is. Can it work through Visual Studio?

Regards,

Dave Rosenbaum

[jkent]

Dave,



I feel your frustration. You start heading in one direction and then the
rug gets pulled out from under you. I wish PTC would share some info on
where they are heading with the API. It would be nice to start planning
for the future. With Creo out of the bag they should start giving us
some more detailed information.



Apahce POI is basically a Java API for Microsoft Documents. You can read
more about it here.

[dandersonjr]

What are PTC plans for more tightly integrating MathCad into Pro/E Creo?
Not having to create parameters in pro/e just to exchange values would be a
big help,
along with a VBA type programming environment.



Don A

[TylerJ.Nielsen]

We are hoping for the same thing.