Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Register Log in

JLink vs PRO/TOOLKIT

A

apilikov

New member
Good day and gentlemen!


There is a question that I want you to ask.


I want your opinion about how large the functionality of JLink now is.


is it equal to pro/toolkit or less?


As I know the functionality of jlink is something about 40% from functionality of pro/toolkit.


please your comments ))
 
this is beside your question. WF4 will have Visual Basic capability. Kind of like VBA behind Excel, I think.

before you invest your money and time into PTK or Jlink..see if VB is your advantage because it's easier for .NET structure.
 
VB.NET and as I think and C#.NET - good idea.


But will .NET API have enough power to replace PTK and JLink?


and my main question is still open )))))
 
very likely, not now in the beginning but in the future VB.NET will mass produce better robustness and higher reused codes, and scalability

I think...
 
I believe that Pro/Toolkit will always have more API's.....J-link (and for that matter VB ) will only be a subset of Pro/Toolkit.
 
I've always heard of j-link as a wrapper around protoolkit. Being that it is perceived as being slower, but I think the slowness would be unnoticeable. I've heard jlink had 80% of the functionality of toolkit, but it could be 90% now in WF3, I don't use that yet. One killer for me was that in j-link you cannot regenerate a layout. The cost of jlink is a strong point. No extra maintenance, no expensive compiler software.
 
J-Link, WebLink, and the VB API are all built upon the same pfc (Parametric Foundation Classes) code. The pfc is, and will always be, a subset of the functionality of Pro/TOOLKIT. I don't think you should pick the tool based upon how much functionality overall it provides. I would suggest examining the tool based upon the problem you are trying to solve. If J-Link can doit then pick that tool rather than spending the $20k on the license for Pro/TOOLKIT. For more in depth information on J-Link I would suggest emailing JD Felinks from Felco Solutions (www.felcosolutions.com).
 
williaps said:
J-Link, WebLink, and the VB API are all built upon the same pfc (Parametric Foundation Classes) code. The pfc is, and will always be, a subset of the functionality of Pro/TOOLKIT. I don't think you should pick the tool based upon how much functionality overall it provides. I would suggest examining the tool based upon the problem you are trying to solve. If J-Link can doit then pick that tool rather than spending the $20k on the license for Pro/TOOLKIT. For more in depth information on J-Link I would suggest emailing JD Felinks from Felco Solutions (www.felcosolutions.com).[/QUOTE]


ok it's clear for me, but I'm afraid to get a following problem. Ok, I decided to use jlink and everything works. But with pro/toolkit I know that any problem that can be potentially resolved with any proe api can be resolved with toolkit.


Is it right for jlink or new VB.NET API?
Click to expand...
 
If you encounter a problem that cannot be solved with J-Link but you have already invested a lot of time into your program, all is not lost. J-Link has the ability to execute a function in a dll written with Pro/TOOLKIT. All you need is someone to develope the Pro/TOOLKIT dll for you. Look up the J-Link package com.ptc.pfc.pfcProToolkit.
 
So you want to say that I can call any toolkit function from JLink?


andi have another question. Is there any user's guide to new API, I mean VB.NET API?
 
And if some functionality is missing you can write a mapkey which do the job. and run this in your program. of course you need to update sometimes mapkeys for new proe versions
 
apilikov,


It wouldn't make sense to just call one Pro/TOOLKIT function from a J-Link application. You would want to perform a specific task in the Pro/TOOLKIT dll such as creating a simple feature which requires several Pro/TOOLKIT functions. As conteyor said if Pro/TOOLKIT can't do something then there is always the mapkey option which I would STRONGLY urge you not to do unless there is no other option.


There is not a User's Guide to the VB COM Server API yet because it is not yet released. It will be released with WF 4.0. You can read about it here.


[url]http://www.ptc.com/appserver/wcms/relnotes/note.jsp?&im_ dbkey=51392&icg_dbkey=826[/url]
 
apilikov,


A mapkey is a recording of mouse clicks that a user makes using the Pro/ENGINEER UI. These mouse clicks get recorded in the trail file that corresponds to the current session of Pro/ENGINEER. You can execute a mapkey from Pro/TOOLKIT using the functions ProMacroLoad and ProMacroExecute. The reason I do not suggest using a mapkey is because PTC may change their UI selections which will in turn make your mapkey recording unusable.
 
williaps,


You said that tool choice depends on problems which I want to solve. Of course I agree with that.


And let me ask you a question. If a want to write a library which incapsulates the functionality of proe api forthose who doesn't want to know how PTK, JLink or any other api works. And the functionality of my library must be very compelete or something near that.
 
apilikov,


You WILL spend years developing such a library that wraps the functionality of Pro/TOOLKIT, J-Link, or WebLink. I would not suggest undertaking that task. There are several thousand API functions in Pro/TOOLKIT alone. I don't think it would be worth your time to do this activity. But, if you like chasing the wind then I will not stop you
smiley2.gif
.
 
williaps,


this library is CAD unified. And its benefits are in this unification.


and inthe contextof unifications this library must have interface to proe too.


I got a mistake saying that functionality must be compelete. Really the functionality must be on the requisite level for the customer of this library.
 
apilikov,


If I understand correctly you are going to create a library of functions that execute operations on more than one CAD system (ex: Pro/ENGINEER and AutoCAD). From my experience with different CAD systems I don't think you could create a library such as this with a high degree of success.The simple creation of a cube in two different CAD systems can vary greatly. Therefore trying to create an API wrapper for two CAD API's seems like a daunting task. However I don't know your customer requirements or goals so I may be incorrect.
 
williaps,


You understood me quite correctly. But my library has more then 2 interfaces. It has interfaces to proe, unigraphics, solidworks, solidedge, inventor, autocad and russian cad system Kompas may be you heard something about it. And this library really is a wrapper, it is simplest explanation of what is it. And it works!


So, I'll try to explain why our company decided to develop such a library. We have a lot of products which working with cads and each of them must support different cad systems. And in context of evolution of our production we decided to concentrate usage of cad APIs in one big product in the form of library. And other products thus will use this library to perform operations with cad. Besides that there are several products of our partners who also need unified cad interface. Here are prerequisities for development of this library.
 
You must log in or register to reply here.

Sponsor

Articles From 3DCAD World

Back
Top