Products

API Bugs

By jnewell

SpyForSolidEdge.pngFinding causes of bugs can be a daunting task. Spy for Solid Edge is a wonderful tool but it had an annoying issue in that it caused Solid Edge to display a “Read-Only Status Indicator” on documents. I have spent so much time thinking that it was a .NETCOM Interop issue. Countless hours debugging, head scratching and profanity filled screaming matches with myself. I’m so happy to tell you that the bug has been fixed in the latest release. I also wanted to share with you what caused the issue and how I went about finding it.

I’ve known about the Read-Only Status Indicator” issue for quite some time now. Actually, I knew about it when I released the application. I moved forward with the release because I felt like the benefits of the application outweighed the cons, issues and all. The following image shows the problem and skips ahead of my post to tell you what caused it.

Read-Only-Status-Indicator.png

That “Read-Only Status Indicator” icon on the top right is the problem and Spy for Solid Edge was seemingly causing it. Well, it was but indirectly. You see, Spy for Solid Edge is a very intrusive application in that it calls APIs that most normal people don’t. It works that way in order to display information to the user. What I found after hours and hours of debugging and thinking it was a bug in my code was that a call like this:

class Program
{
[STAThread]
static void Main(string[] args)
{
var application = SolidEdgeUtils.Connect();
object value = null;
var parameter = SolidEdgeFramework.ApplicationGlobalConstants.seApplicationGlobalOpenAsReadOnly3DFile;
application.GetGlobalParameter(parameter, ref value);
}
}

causes Solid Edge to display the “Read-Only Status Indicator”. As a sanity check, I verified the bug using native C++ as well. I have tested all of the ApplicationGlobalConstants and 


seApplicationGlobalOpenAsReadOnly3DFile is the only one that causes the bug. For now, Spy for Solid Edge will skip that particular global constant in order to avoid the issue.

One of the most common questions I get asked is how do I find the cause of bugs like this. This is a very real-world example of the types of issues that you all encounter every day when trying to automate Solid Edge. My single best tip for this kind of stuff is process-of-elimination. Spy for Solid Edge is a rather large and complex application. It has a lot of moving parts and is trying to do more than most automation type applications. My final solution for this particular problem was remarking out code and narrowing it down to the API call(s) that were leading to the issue. That may sound easy at glance but in a large application, where do you start? The answer is, it depends. Cliche I know but for me, experience gives me insight into where I think the problem is.

So what do we as users do when we find API bugs? I immediately filed an Incident Report (IR) with GTAC. Incident Reports are the proper approach for us, as users, to communicate with the Solid Edge development team. I will also receive status updates via email as they process the IR. Also, by communicating the bug to development, we’re saving future API users from having to experience the bug.

As a result, I have released Spy for Solid Edge 2.5 on CodePlex. If you already have the application installed, you should get prompted to upgrade on application startup. Happy coding!

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at https://blogs.sw.siemens.com/solidedge/api-bugs/