This post is a humble request to all Pro/ENGINEER developers out there to help me solve an extremely irritating problem. First let me begin by explaining my problem.
Unlike most CAD vendors, PTC does not give away their SDK (Software Development Kit) for free. So if you want to customize Pro/ENGINEER by means of plug-ins you need to purchase a license of something known as Pro/TOOLKIT, basically a C API used to develop what PTC calls auxiliary applications, or plug-ins. As a PTC partner I have a Pro/ENGINEER and Pro/TOOLKIT license on my development computer and only a Pro/ENGINEER license on a second testing computer. Now the thing is that plug-ins that I develop on my development computer will work only on a computer that has a Pro/TOOLKIT license. In order that they work on the testing computer, or for that matter, any other computer with just a Pro/ENGINEER license, I need to “unlock” the plug-in DLL. No other CAD vendor I know has such a system, but I guess PTC has a good reason for doing so. One obvious reason for locking the plug-ins is that someone without a Pro/TOOLKIT license should not be able to develop plug-ins.
My problem is that the unlocking program works in a weird way. When you start the program and supply it with a DLL file name to unlock at the command line, it just sits there for 15 mins and does nothing. After 15 full minutes, it unlocks the DLL within a fraction of a second. Yes, you read that right. But I will repeat anyways. The unlocking program sits idle for 15 (fifteen) minutes before it eventually unlocks the DLL. So if I make a change in my plug-in and want to see how it works on the testing computer, I need to wait 15 minutes between each and every change I make. Also, if I have ten plug-ins (I am developing 14 actually), I need to spend a total of two and a half hours doing nothing before I can unlock all of them and proceed to build my installers.
Obviously, developers found this extremely irritating and probably let PTC know about it. I say this because in Wildfire 3.0 or 4.0 (not sure), PTC changed the way the unlocking program worked. Now the program immediately unlocks the plug-in DLL, but ties up the Pro/TOOLKIT license for 15 minutes thereafter, thereby preventing another unlocking operation for the next 15 minutes. Same difference. The only advantage here is that the person testing the plug-in can do so immediately, and not have to wait 15 minutes. But he will still have to wait 15 minutes before testing the next change to the plug-in.
In my opinion, this new arrangement has the same nuisance value as the earlier one. A plug-in that I was developing was working perfectly fine on my development computer (they normally do) but was crashing on the testing computer. So while debugging I had to wait 15 minutes before I could change my code to see if the change that I made stopped the crash on the testing computer. I took three hours to find and fix the bug, something which would have been done in ten minutes had this weird 15 minute lockout not been there.
So why exactly does this 15 minute lockout exist? I have no damn clue! When PTC changed the unlocking program they also added a feature whereby you could supply multiple plug-in DLLs to unlock at once. Earlier you could unlock only one DLL at a time. So if I have a thousand plug-in DLLs, I can now have them all unlocked at one go in a few minutes. Of course, I will not be able to unlock another DLL for the next 15 minutes. But that does not really matter anymore because I could have added it to the list of thousand DLL’s that I had just previously unlocked. So if the reason for the 15 minute lockout was to limit the number of DLL’s that could be unlocked in an hour, a day or some time interval, the new unlocking program offers a way of bypassing that limitation. But as I found out the hard way, tying up the Pro/TOOLKIT license for 15 minutes after every unlocking operation poses serious problems while debugging a plug-in.
Instead of speculating I decided to ask PTC for the reason for the 15 minute lockout. When I was at their headquarters in Needham, I put the question across to a few people there. To my surprise none of them knew the reason for the 15 minute lockout. So maybe I was asking the wrong people. After I returned to India I logged a technical support call. The engineer who responded to my call was frank enough to admit that he did not know the reason either, but promised to find out and let me know. I never ever heard back from him. I have since asked a few other developers but none of them know the reason.
I have resigned to the fact that as a Pro/ENGINEER plug-in developer I have to live with the 15 minute lockout. What I cannot live with is not knowing why the lockout exists in the first place, especially since it can be such a pain while debugging. I would be extremely grateful to the person who enlightens me with the reason for the 15 minute lockout. Its killing me not to know.
I hope that there is a very good reason for the 15 minute lockout and not that some wise guy put it there decades ago and now nobody knows why it is still needed.