Wrench value from your Creo Investments Home Measure the benefits Simple Automation can bring Why
Automate?
A personal way to do PDM Peer to Peer
PDM
3D Drawings Model Based
Design
Smooth out unwanted sharp edges Other
Articles
www.proetoolbox.co.uk - Simple Automation made Simple

Having to use Mozilla Based Browser

For years I've been able to write my simple automation apps with the knowledge of being able to use Internet Explorer. However during the last few months I had to rewrite a substantial number of Apps to work with Creo 2's mozilla based browser. This article describes the various obstacles that presented themselves as the journey unfolded.

 

Issue #1: Utility Functions

My utility functions didn't work properly with Mozilla Based Browser. Worse yet, if you've read my book, you'll notice that I always code my apps using a single page mentality; all my code including styling, utility functions and the like is in one *.html file. I don't like to split apart my utilities into seperate files because I dislike file management. I knew that should a fundamental peice of the puzzle break at some point, I'd suffer having to edit the same function over and over again. So it was to be my first hurdle, that the utility functions were not optimized for Mozilla. Note the browser inside Creo 2 when running the config.pro option of windows_browser_type mozilla_based_browser is approximately firefox 4 vintage.

I found out that the browser interogation calls that were in my pfcCreate and pfcIsWindows calls were not working nicely with both IE11 and Mozilla Based Browser. I chose to reimplement like this...

//=============
//Utility Functions
//=============
function libCheckEnvironment()
{
	//Setup base global variables
	try
	{
		if (!pfcIsIE())
		{
			netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
		}
		
		window.mGlob = pfcCreate("MpfcCOMGlobal");
		window.oSession = mGlob.GetProESession();
		window.WLAvailable = true;
		oSession.CurrentWindow.SetBrowserSize(50);
	}
	catch(er)
	{
		window.WLAvailable = false;
		//Web.Link isn't available
		//alert (WEBLINKNOTWORKING);
	}
	//Check for ActiveX abilities
	try
	{
		if (pfcIsIE ()==false)
			 throw "ACTIVE X NOT AVAILABLE ON NON-MICROSOFT PLATFORMS";

		//Will fail if security not setup to allow it
		var MAKEACTIVEXAPPEAR = new ActiveXObject("Scripting.FileSystemObject");

		ActiveXAvailable = true;
	}
	catch(er)
	{}
}

//Standard utility Functions
function pfcIsIE ()
{
	
	//IE8,9,10
	if (navigator.appName.indexOf ("Microsoft") != -1)
	{ 
		return true;
	}
	else
	{
		//IE11
		if (navigator.userAgent.indexOf("Trident")!=-1)
		{
			return true;
		}
		else
		{
			return false;
		}
	}
}

function pfcCreate(className)
{
	if (!pfcIsIE())
	{
		netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
		ret = Components.classes ["@ptc.com/pfc/" + className + ";1"].createInstance();
		return ret;
	}
	else
	{
		return new ActiveXObject ("pfc."+className);
	}
}

I was hoping that this would be the end of it. However I had to do quite a bit more, the next issue was I had fallen into the age-old javascript programmer trap of writing a lot of IE specific code...

 

Issue #2: IE Specific DOM Scripting

I have relied for the longest time on IE's automatic expando property capability. That meaning I found my code regularly added custom properties to HTML tags to make UI parsing a little bit easier. That's a bit of a mouthfull, what I mean is, I had done this a lot.

//BEFORE METHOD
for (var i=0;i<Files.Count;i++)
{
	var fileName = Files.Item(i).substring(Path.length);
	//IE was capable of injecting with automatic custom attributes on HTML tags
	//Moz and IE11 cannot do this now
	Out +="<TR>"+
		"<TD>"+fileName+"</TD>"+
		"<TD align=center><INPUT type=checkbox id=OpenCB whatfile=\””+ fileName +”\”></TD>"+
		"</TR>";
}

What I should have been doing of course is using proper standards based programming. In fact the code above started breaking when folks upgraded to IE11 not just the enforced switch to Mozilla Based Browser. So instead of the above, I would in hindsight have used the principle of hidden controls to hold these values and used standardized DOM accessing javascript commands to interrogate them.

//AFTER METHOD
for (var i=0;i<Files.Count;i++)
{
	var fileName = Files.Item(i).substring(Path.length);
	//...so while it's possible to add custom attributes post HTML tag creation,
	//I think it's easier to just add a hidden control to hold the custom value
	Out +="<TR>"+
		"<TD>"+fileName+"</TD>"+
		"<TD align=center><INPUT type=checkbox name=\”OpenCB\”>"+
		"<input name=\”OpenCBValue\” type=\”hidden\” value=\””+ fileName +”\”></TD>"+
		"</TR>";
}

So the first two hurdles were principally of my own making. I then noticed that Mozilla requires permissions setting in any function scope that called the Pro/Web.Link API's.

 

Issue #3: Mozilla Security needs granting per function scope

I still don't really understand this one. Nevertheless it's quite easy to deal with. All you have to do is call the permissions command once at the start of each function scope.

/*=========================
Global Variables and 
initialization commands
=========================*/
//Have to add this at every function block scope including Global
if (!pfcIsIE())
{
	netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
}
libCheckEnvironment();
...

I think this requirement could be an issue for writing easy to read code that needs to recurse or loop a lot. I suspect the command is a slow one and so while so far I've not tried to write optimized versions of the above, I suspect folks using the API for larger things may want or need to explore that.

 

Issue #4: Mozilla API is very slow in Creo Parametric 2.0

I was feeling so pleased with myself by this point to be honest. Then I found out, PTC's programmers had not noticed how crappy slow this API was. They have fixed it post MXXX see href this. But of course switching out buildcode isn't something companies of size do just because PTC made a mistake. The result for me was that some apps which were coded with an abundance of loops within loops became unuseable with the 100 times lower performing Mozilla based API. This was tougher to fix, principally because the whole guts of some apps had to be rewritten. I have some apps I labelled, 'broke until further notice' due to this situation. Simple Automation apps need to be obvious to the user, some of ours such as ECAD board fixing were so slow to execute that the users assumed they were not working and started clicking the model. As the Mozilla based browser calls are somewhat asynchronous compared to IE (in process) what we experienced is that any app which was 'slow' was prone to the user not waiting and clicking additional Creo commands. The results of this of course were unpredictable. I had to recode to present the user with warning labels regarding this undesirable way of working.

 

Issue #5: Mozilla API requires a pretty cryptic procedure to allow it to operate

While our Creo scripts actually deploy windows registry changing code, we only did this because our IT groups constant patching of IE led the userbase to have to more regularly than desired manually allow ActiveX controls. The procedure in IE itself is actually quite straightforward and has a UI for every step. When editing the Mozilla browser, we felt users were practically programming it. See PTC's tech support article on signed.applets.codebase mozilla preference which you can access and set like this:

 

Issue #6: Mozilla Security is saved in the same place as the Mozilla Cache

Making issue #5 worse was that we found many users would run multiple sessions of Creo simultaneously without making special provisions for seperating the caches. The outcome was that many times we had to delete a cache (C:\Users\YOURUSERNAME\AppData\Roaming\ptc\.ptcm1912\ptc-browser\prefs.js) with the result that we'd receive a further issue to resolve of the automations not working. We decided enough was enough and figured out, using the information from PTC's tech support article on signed.applets.codebase, how to script these tweaks into the Mozilla cache directly at Creo startup.

I like to use AutoIT for Creo's startup scripts, as it . The logic is the same in any language however. We look for the file, if the file is populated (which implies Creo has been started and shut down once) then we add the appropriate security lines into the prefs.js file.

 

Issue #7: Mozilla doesn't allow me to run ActiveX commands

This issue means that I can't build an Excel spreadsheet directly from my App. It means I can't tell PowerPoint to automatically import and resize a bunch of screendumps I've just had Creo make. It means I can't read or write text files such as relations files. Basically it means I don't have access to a wide variety of usefull abilities.

I've chosen to write a seperate article about making a simple J.Link 'helper' app to get around the reading and writing of text files limitation.

 

Conclusion

Mozilla works, it's not as hackable as IE, I didn't want to do it but it can be made to work in most cases.


 

J.Link Helper>>