Showing posts with label Perl. Show all posts
Showing posts with label Perl. Show all posts

Wednesday, June 18, 2008

Pro/E VB API: Not Just for Visual Basic Anymore

In a previous article entitled "WebLink: What is it anyway?", I discussed Pro/WebLink and how it's not exactly a Javascript interface. Now it's the VB API's turn. The VB API is newly released by PTC with Wildfire 4. It is billed as a Visual Basic interface to PTC's PFC libraries, which is the same core that J-Link and Pro/WebLink are built upon.

While this is true, it's not that limited. Don't let the name scare you away from using your favorite COM accessible programming or scripting language to write Pro/Engineer applications. This is a good thing because it opens the API to a much wider range of applications.

In this article, I'll walk through sample applications written in Visual Basic, VBScript (using Windows Script Host), Perl, and Javascript (in a HyperText Application), all using the VB API. The sample application will connect to a Pro/Engineer session, obtain the session object, display the name of the current model, then disconnect from the Pro/Engineer session. Each program will display the model name in a different way.

Suggested reading is the section on the importance of disconnecting from Pro/Engineer in Pro/E VB API: A First Look.

Excel Macro

This is the standard and documented approach to the sample program. Objects are declared up front, the connection to Pro/Engineer is made, then the session object is obtained. The model name is displayed both in cell A1 and in a MsgBox.

Sub Macro1()

Dim asynconn As New pfcls.CCpfcAsyncConnection
Dim conn As pfcls.IpfcAsyncConnection
Dim session As pfcls.IpfcBaseSession
Dim mdlname

Set conn = asynconn.Connect("", "", ".", 5)
Set session = conn.session

mdlname = session.CurrentModel.Filename
Range("A1").Select
ActiveCell.FormulaR1C1 = mdlname
MsgBox ("Name: " & mdlname)
conn.Disconnect(2)

End Sub
 

VBScript

The VBScript code is almost identical except that VBScript doesn't seem to allow for the type declaration of the objects. As a result, the CreateObject() call is used to instantiate a pfcAsyncConnection object.

The program is executed using the following command line:
  cscript vbapi_script.vbs
 

Dim asynconn
Dim conn
Dim session
Dim mdlname

Set asynconn = CreateObject("pfcls.pfcAsyncConnection")
Set conn = asynconn.Connect("", "", ".", 5)
Set session = conn.session

mdlname = session.CurrentModel.Filename
MsgBox ("Name: " & mdlname)
conn.Disconnect(2)
 

Perl

As with most COM applications, the Perl syntax is also very similar to the VBScript code, but with Perl's own syntactical flavor. Win32::OLE->new() is the Perl equivalent to VBScript's CreateObject(). The Perl program outputs the model name to the command prompt (or standard output).

use Win32::OLE;
$asynconn = Win32::OLE->new("pfcls.pfcAsyncConnection");
$conn = $asynconn->Connect( "", "", ".", 5 );
$session = $conn->Session;
$mdlName = $session->CurrentModel->FileName;

print "mdlName: $mdlName", "\n";
$conn->Disconnect(2);
 

Javascript

Pro/WebLink applications can finally break out of the embedded browser jail using the VB API. This example uses a "Hypertext Application", which is a web page with a special HTA tag and with a file extension of ".hta" instead of ".htm". The pfcUtils.js file cannot be used as-is because it tries to use COM objects with "pfc." prefixes, instead of those associated with VB API which have "pfcls." prefixes.

Other than those differences, it's essentially a Pro/WebLink application. As with the other examples, because it's an asynchronous application, the code must connect to the Pro/Engineer session. This is a step that embedded browser based Pro/WebLink applications don't have to worry about.

<html>
<head>
<title>VB API Test</title>

<HTA:APPLICATION
ID="vbapi-test"
APPLICATIONNAME="VB API Test"
SCROLL="auto"
SINGLEINSTANCE="yes"
>
</head>

<body>

<SCRIPT LANGUAGE="JavaScript">

function HitMe ( ) {
var obj = null;
var elem = document.getElementById("mesg");

if (obj == null) {
try {
obj = new ActiveXObject("pfcls.pfcAsyncConnection");
}
catch (e) {
elem.innerHTML = "Failed to create object";
return;
}
}

var conn = obj.Connect( "", "", ".", 5 );
var session = conn.Session;
var mdlName = session.CurrentModel.FileName;

elem.innerHTML = "mdlName: " + mdlName;
conn.Disconnect(2);
}

</SCRIPT>

<form name="f">
<INPUT name="a" type=button value="Hit me!" onclick="HitMe()">
<br><a id="mesg"></a><br>
</form>

</body>
</html>
 

These are just a few of the possibilities. As you can see, there is nothing really Visual Basic specific about the VB API. It's just an API.

Tuesday, April 8, 2008

WebLink: What Is It Anyway?

A discussion of what WebLink is, and is not

WebLink is one of the two free API's (JLink being the other) provided by PTC to create Pro/Engineer applications. According to PTC's documentation, WebLink is a Javascript based library for use within the embedded web browser.

That's sounds great, but it's about as accurate as describing a car as a pothole creator. Well, here in Detroit that's more true than not, especially on Van Dyke ... but I digress.

Truthfully, WebLink isn't really Javascript based at all. It's based on Microsoft's COM/ActiveX/OLE objects on Windows, and Mozilla's XP-COM on Unix. You don't even need to use Javascript. On Windows, you can use VBScript, Perl, Python, or any one of your favorite languages that can access COM objects.

Here's an example of using VBScript in a WebLink application:

<HTML><BODY>
<SCRIPT type="text/vbscript">
function HitMe ()
dim mdlname
Set pfccomglob = CreateObject("pfc.MpfcCOMGlobal")
mdlname = pfccomglob.GetProESession.CurrentModel.FileName
Document.getElementById("mdlname").innerHTML = "Name: " & mdlname
msgbox("Name: " & mdlname)
end function
</SCRIPT>
<form name="f">
<INPUT name="a" type=button value="Hit me!" onclick="HitMe()">
<div id="mdlname"></div>
</form>
</BODY></HTML>

To make matters worse, you don't even need to use the web browser! A Pro/Toolkit DLL can access the WebLink COM objects using C/C++ and can do so completely outside the confines of the web browser. The Pro/Toolkit DLL could also go as far as hosting your favorite scripting engine. The web browser is just one of many environments in which a WebLink application can run.

Here's the same example using Perl to access WebLink COM Objects from within a Pro/Toolkit DLL:
use Win32;
use Win32::OLE;
$pfccomglob = Win32::OLE->new('pfc.MpfcCOMGlobal');
$mdlName = $pfccomglob->GetProESession->CurrentModel->FileName;
Win32::MsgBox("Name: $mdlName");

To summarize, WebLink requires neither Javascript nor a web browser. That clears things up, right? Why is it called "WebLink"? Well, you can use it in a web browser, and all PTC software has to have the word "Link", as a result: WebLink!

Can you imagine the response had they called it Pro/COM, or ActiveXLink, or COM.Link? A resounding "huh?" would have echoed through the halls on Kendrick Street. I think the marketing guys got it right this time.

Anyway, using whatever language in whatever environment you desire, the huge benefit to WebLink is that it's a rapid prototyping system for Pro/Engineer applications. The code-test-code-test cycle can be repeated as quickly as you can refresh the web browser. Whether you intend to migrate the application to JLink, or leave it in the web browser, you can get a complex application written very, very quickly. That's what makes WebLink very powerful.

Learn it, you won't regret it.