Discovering a bug in one of the libraries you are using is never an enjoyable experience: you either need to find a workaround, or get a patch release with a bug fix. No matter what you decide, you now need to spend time fixing something that was supposed to just work. Typically, you will also have to contact the Support Desk services.

Access to our product support desk is a service included in your Product Maintenance agreement or in your Subscription.

At Hexagon, we try to be as responsive and helpful as possible on the support desk. Before we can help you deal with a bug, though, we need to understand:

  • What you are trying to achieve

  • Why you are trying to achieve it

  • How you are trying to achieve it, so that we can reproduce the steps triggering the bug.

If you provide all that information in your initial problem report, we can get around to fixing your issue more quickly, without having to ask you for more context first.

The ideal bug report contains

Steps to reproduce the issue locally

If we need to investigate a bug, it is essential that we can reproduce it locally. For that, we rely on the information you can provide us with:

  • A stand-alone unit test: this is considered the holy grail of bug reporting. If you can write a failing test case that illustrates the bug and that we can run locally, you can be sure that we have all the information we need.

  • A modified version of the sample code: writing a unit test to illustrate a bug is not always possible. The next best thing is a modification of one of the included product samples to illustrate the bug.

  • Code snippets: if you have trouble with a certain class, send us a code snippet illustrating how you are interacting with it.

  • A detailed list of steps: if you run into an issue while interacting with an end user or demonstration sample, such as the COP sample, provide us with a full list of steps. Try to be as precise as possible. For example, say "Drag-and-drop data set xxx onto the application" instead of just "load data set xxx".

  • Sample data: if the bug occurs with just one data set, send us the data. We can set up an FTP account if needed. If you cannot send us the data for some reason, try to provide us with as much information about the data set as possible. For example, for raster data, you could include the output of the gdalinfo command.

Before you send your support ticket, consider that our support engineers have no knowledge of your application. To understand and reproduce the problem, they need as much context information as possible.

A clear description of the actual behavior versus the expected behavior

Make sure that your support ticket clearly describes what the actual behavior is, what behavior you are expecting, and why you are expecting it.

Add a screenshot or a short video to your description. They can be very helpful to illustrate a visual problem.

A high-level description of your use case

We can provide the best support if we understand the use case you are trying to solve:

  • We might have a class that is better suited for the task, and that does not trigger the bug you are trying to solve.

  • We might be able to add extra API functionality that facilitates your use case. *The class you are using might not have been designed for your use case.

  • We can suggest workarounds if we understand your end goal.

Version and system information

  • Product name and full version number: for example LuciadRIA 2018.1.04 .

  • Browser version: include the browser version, for example Firefox version 40.0.3.

  • GPU information: include the output of the WebGL support sample if you are using a view/WebGLMap.

  • OS: for example Windows 10, 64 bit

  • Device type: when you are running an application on a smartphone or other handheld device, provide at least the brand and model type of the device you are using, for example, LG Nexus 5X

All relevant logging output

  • The full stack trace: when an exception is thrown, there is a stack trace on the console or in the log file. Include the full stack trace in your message.

  • Logged warning or error messages: add all the warning or error messages you got to your support ticket.

General support ticket guidelines

Create a ticket for each unrelated question

If you have multiple unrelated questions, or multiple questions on distinct topics, open a ticket for each question. All support desk agents have a specific area of expertise. As such, each of your questions may be handled by a different support engineer. Separate tickets for unrelated topics make ticket assignment much easier.

Create a new ticket for a new question

If a new question occurs to you while you are working on a ticket, open a new ticket instead of adding the question to the current ticket. All support desk agents have a specific area of expertise. As such, each of your questions may be handled by a distinct support engineer. Separate tickets for unrelated topics make ticket assignment much easier.

Refer to related tickets by their number

Each of your tickets may be handled by a distinct support agent. The agent working on your current ticket may have no knowledge of any of your other tickets. Therefore, if you want to mention another ticket, refer to it by its ticket number. This allows all support desk agents to retrieve it and familiarize themselves with it.