A discussion of what WebLink is, and is not
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.
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");
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.