Support Process

We support you every step of the way.

  1. When a customer reports a bug to SMS, it can be sent via our online Request Support Form or it can be sent to support@smlib.com. The SMS support staff is usually able to do the initial investigation within 24 hours.
  2. The initial investigation is to verify that we can duplicate the problem. So, in most cases, the user should submit input data and if possible the section of code that calls the failing function.
  3. The support person that is working on the reported bug may then go back and forth directly with the user that reported the bug, usually by email, sometimes by phone, until the problem is resolved.
  4. Once the problem has been resolved, if the fix required code changes, we immediately send the developer the revised code and that code will then be in all future releases.
  5. This process has worked very well and our goal is to continue to supply first class support to all our customers.

Bug reporting tips (by using either our online Request Support Form or via email)

In the effort to support our customers better, we have listed a few guidelines to help make the process go smoothly and to help us help you. Outlined below are several ideal methods or tips by which to describe bugs and to communicate with support. We realize that many bugs are unique and they must be handled individually, but the notes below provide a good guideline.

Please provide us the following information:

  • Specify version of SMLib you are using
  • Specify operating system
  • Specify if issue occurs 32/64
  • Specify if issue occurs MultiByte/Unicode
  • Address issues to support@smlib.com
  • One issue per e-mail. Do not refer to several issues with the same e-mail.
  • The subject line should describe the contents of the current e-mail. It is easy to reply to older e-mails.
  • Supply test program to reproduce the issue.
  • The test program should be written in c++. Please try to avoid code snippets copy and pasted into the contents of the e-mail. The test program should compile and be ready to included in ui_test
  • Test programs should be named CompanyNameMonthDay.cpp
  • For example: MyCad0925.cpp
  • Function names should have the same name as the file name
  • For example: MyCad0925 ()
  • Supply commented example test programs
  • Make use of file i/o functions.
  • Please check if input data is valid

It is strongly suggested that SMLib users compile and run the ui_test utility program (Smlib/ui_test/ui_test.sln) to aid in testing and bug reporting. This is a valuable visualization tool that allows users to understand SMLib code implementation and test specific examples. By testing or reproducing a bug in ui_test, a user can be sure the issue exists in SMLib. In other words, the user’s application will not be needed to reproduce the bug. This method also ensures that the user and SMS support are running the same code with the same input parameters (tolerances, etc). This method also makes it easier for us to include the issue in our regression test suite.

Once compiled, ui_test can perform many tasks without recompiling. Besides reading object files and displaying them with rotate, pan, zoom, etc., ui_test can tessellate objects, repair objects, run scripted demonstrations, and redisplay objects shaded or with a control polygon, etc. Ui_test can also boolean two objects.

We have a number of example test programs under Smlib/Examples. These example functions simplify a test case or a bug report by testing only one smlib function at a time. For example, they might read object 1, read object 2, and perform an operation. These not only provide useful example code, but each one can be included in the ui_test project to demonstrate results. The file “Template.cpp” is shipped with ui_test as a very basic example. Users are encouraged to substitute “Template.cpp” with their own “Test” functions by copying example code or their own application code and reading smlib objects from native files that can then be used as input into smlib functions.

Although, it is possible to provide support with geometry data in other file formats (iges, step, etc), it is preferred to send smlib native ASCII files. This practice will eliminate the possibility that the issue occurs during translation. Please use WriteToFile() on any smlib object to create a file with the file extensions listed below:

IwPart – .iwp
IwBrep – .iwb
IwFace – .iwf
IwSurface – .iws
IwCurve/IwBSplineCurve – .iwc
Array of IwCurves – .iwcs

Please do not use .txt nor .dat

When writing individual smlib objects, the header should not be written to file. This can be accomplished by passing in “true” for bSkipHeader.

Prog_test is a way of testing for regressions. Most users will not need or use prog_test except possibly as code examples.