Develop Pro/TOOLKIT applications

Download: Develop the Pro/toolkitapplication. docx

Develop the Pro/toolkitapp Development

1. Running Mechanism of Pro/TOOLKIT applications

The standard method for integrating a Pro/Toolkit program into a proe program is to use a dynamic link library. When you compile your Pro/toolkit c code and establish a link with the Pro/TOOLKIT library, a binary library file (DLL) is generated. When proe is started, it will be integrated into proe. This method is called the DLL mode.

Pro/Toolkit also supports another integration mode: multi-process mode or derived mode. In this mode, the Pro/TOOLKIT program is compiled and linked to an independent executable file. It is derived from the PROE program and runs as a subprocess of proe. In DLL mode, information exchange between the Pro/TOOLKIT program and proe program is implemented through direct function calls. In multi-process mode, function calls between the two processes need to pass necessary information to identify which function is called and the parameter value of the function. This simulates the same effect as that in the DLL mode.

Compared with the DLL mode, the multi-process mode has a higher communication cost (Note: communication time and amount of information), especially when the Pro/TOOLKIT program frequently calls the functions of the Pro/TOOLKIT library, because the implementation of function calls between processes is more complex. However, it also has the following advantages: You can use the source code debugger to debug programs without loading the entire proe executable file into the debugger.

Without changing the source code of Pro/toolkit c, you can compile the program and link it to the DLL mode or multi-process mode. You can also run multiple Pro/TOOLKIT programs in the same proe process, and these programs can use different modes together.

If you use the multi-process mode to facilitate debugging when writing a Pro/TOOLKIT program, you should switch to the DLL mode when installing and using the program for the end user, because in the DLL mode, the program runs better. After switching to the DLL mode, be careful to thoroughly test your toolkit program and then release it. In different modes, any programming error that causes memory corruption in proe and Pro/TOOLKIT may be different. Therefore, after switching to the DLL mode, a new bug may occur.

Although the multi-process mode can trigger Parallel Running of proe and Pro/TOOLKIT programs, they are not actually parallel running. Another mode that integrates the Pro/TOOLKIT program can implement this function, which is called asynchronous mode. We call the DLL mode and multi-process mode the synchronization mode. The Pro/TOOLKIT program in asynchronous mode and the program in synchronous mode are completely different in the program architecture. Therefore, you must select one of them before writing code. In general, the synchronization mode should be selected by default, unless there is an irresistible reason, because the asynchronous mode is more complex than the synchronous mode.

 

2. Use VC to Develop Pro/TOOLKIT applications

For detailed environment configuration and steps, see related articles.

 

3. register the Pro/TOOLKIT Program

The registration file is used to provide proe with the basic information to form the Pro/TOOLKIT program. Proe loads the Pro/TOOLKIT program by registering the information provided by the file.

Proe will search for registration files in sequence from the following locations:

(1) In the PROE configuration file (config file), the absolute path specified by protkdat, prodevdat, toolkit_registry_file is used.

(2) The protk. Dat or prodev. dat file in the current directory.

(3) The protk. Dat or prodev. dat file in the <Pro/ENGINEER>/<machine>/Text directory.

(4) The protk. Dat or prodev. dat file in the <Pro/ENGINEER>/Text directory.

Where:

<Pro/ENGINEER> indicates the installation path of proe.

<Machine> a subdirectory specified by the computer platform name, such as the i486_nt subdirectory.

If multiple registration files with the same name exist in path (2) (3) (4. dat or prodev. dat, then proe will take the first registration file with the same name as the standard, and ignore the subsequent registration file with the same name. For example, if protk exists in the current directory and the <Pro/ENGINEER>/Text directory. if the DAT file is registered, proe ignores the protk in the <Pro/ENGINEER>/Text directory. DAT file. If you change the latter name to prodev. dat, because the names are different, both registered files will be read.

Note: (1) when the registration file name of the specified absolute path conflicts with (2) (3) (4), there is no impact.

For example, in the config. Pro file, specify

Protkdat D: \ wangyao \ istudy \ proe \ protoolkit \ testtk \ test_2 \ protk. dat

Protkdat D: \ wangyao \ istudy \ proe \ protoolkit \ testtk \ test_3 \ protk. dat

If protk. dat exists in the current directory, all three registration files will be read.

When developing the Pro/TOOLKIT program, we usually place the registration file protk. dat under a specific directory, so that only when proe is started under this directory will the Pro/TOOLKIT be loaded. When you finally install and use the Pro/Toolkit, The protk. the dat registration file is placed in the <Pro/ENGINEER>/Text directory. This ensures that no matter from which directory proe is started, the registration file can be read to load the Pro/TOOLKIT program.

A registration file is a simple text file. Each line contains a predefined keyword followed by a specific value.

In DLL mode, the standard format of a registration file is as follows:

Name toolkittest

Startup DLL

Exec_file D: \ toolkit \ dll \ testtk. dll

Text_dir D: \ toolkit \ DLL

Revision wildfire

Allow_stop true

End

The specific meaning is as follows:

Name --- the name ID specified by the Pro/toolkt program. The name must be unique.

Startup --- specify the communication mode between proe and the Pro/TOOLKIT program. In this example, specify the DLL mode.

Exec_file --- specifies the complete path of the Pro/TOOLKIT program to be loaded

Text_dir --- specifies the directory containing the Pro/TOOLKIT program menu and message file.

Revision --- specifies the Pro/Toolkit version used to create the application. Set the value to wildfire for programs developed for proe3.0 and 4.0.

End --- end mark

If you want to run in multi-process mode, you must make the following changes to the registration file.

(1) modify the startup statement to startup spawn.

(2) modify the value of exec_file to point to the executable file of Pro/Toolkit.

 

4. Start and Stop the Pro/Toolkit Application 

Pro/TOOLKIT supports stopping and restarting a synchronization application in a proe task, which is useful when developing the Pro/TOOLKIT program, because it allows you to not restart proe, you can modify the program source code and reload the test after compilation.

In proe, you can use the auxiliary application dialog box to stop and restart the Pro/TOOLKIT application. As shown in

 

However, you must add the following statement to the registration file:

Allow_stop true

If this statement is not added or the statement is allow_stop false, you cannot manually restart or stop the program. The program is not displayed in the pop-up application dialog box unless you click the info button.

In proe, click the auxiliary applications sub-menu under the Tools menu to bring up the auxiliary application dialog box. In the dialog box, the list of Pro/TOOLKIT program names specified by the name statement in the registration file and the current state of the program are displayed.

In the pop-up application dialog box:

Start is used to start the Pro/TOOLKIT application.

Stop is used to terminate the Pro/TOOLKIT application.

Register is used to load the Pro/TOOLKIT application.

Delete is used to uninstall the Pro/TOOLKIT application from.

Info is used to list basic information about all current Pro/TOOLKIT applications.

If you want to start proe and do not want to run the loaded Pro/TOOLKIT application immediately, add the following statement to the registration file:

Delay_start true

You can use the start button in the pop-up application dialog box to start running.

 

5. Unlock the Pro/TOOLKIT Application

You must unlock your Pro/TOOLKIT application before you release it to the end user. This ensures that you can still run your Pro/TOOLKIT application without installing the Pro/Toolkit.

To unlock the Pro/TOOLKIT application, enter the following command in the CMD window:

<Pro/ENGINEER loadpoint>/bin/protk_unlock.bat Pro/TOOLKIT complete path

TIPS: drag the protk_unlock.bat file and the Pro/TOOLKIT program to the CMD window, so you don't have to enter them manually.

The displayed information is as follows:

To unlock a Pro/TOOLKIT application, you must use the Pro/TOOLKIT license. Each time a Pro/TOOLKIT application is successfully unlocked, it will take up to 15 minutes to use the Pro/TOOLKIT license. That is, the Pro/TOOLKIT license cannot be used within 15 minutes. Therefore, if you only have one Pro/TOOLKIT license, you will no longer be able to unlock other Pro/Toolkit applications within 15 minutes after a Pro/TOOLKIT application is successfully unlocked, this is because the Pro/TOOLKIT license will be used for 15 minutes and will be ready for use later.

 

6. Structure of the Pro/Toolkit Application

In the source file of each Pro/TOOLKIT application, the header file protoolkit. h must be included and the first header file must be included. Because it defines the wchar_t, And this type is used by many other Pro/Toolkit header files. Pro/TOOLKIT. H also contains the following standard header files:

Stdio. h

String. h

Stddef. h

Stdlib. h.

In synchronization mode, the Pro/TOOLKIT application must contain the user_initialize () and user_terminate () functions, which are compiled by the Pro/TOOLKIT application developer, proe calls the PROE when you start and end the Pro/TOOLKIT application.

Note: (1) the Pro/TOOLKIT application code must contain at least one call to the Pro/TOOLKIT function; otherwise, an error occurs when the PROE loads the Pro/TOOLKIT application.

(2) If C ++ is used to compile the Pro/Toolkit program, add the extern "C" before the user_initialize () and user_terminate () functions ".

The user_initialize () function must return 0, indicating that the Pro/TOOLKIT application has been initialized successfully. Other returned values are considered to be incorrect, and the system will notify the PROE User: initialization of the Pro/TOOLKIT application fails.

The following code is required at the beginning of each new Pro/TOOLKIT synchronization mode application:

# Include "protoolkit. H"

Int user_initialize ()

{

Return (0 );

}

Void user_terminate ()

{

}

 

7. multithreading in Pro/TOOLKIT applications 

The Pro/TOOLKIT application also supports multithreading. However, you must call the Pro/TOOLKIT function in only one thread. Otherwise, an error occurs.

To use multiple threads in DLL mode in synchronization mode, call the proengineermultithreadmodeenable () function in the user_initialize () function, this function notifies proe to run in multi-threaded mode. However, the performance of programs running in this mode is reduced. Therefore, this function is called only when multithreading is required in the Pro/TOOLKIT program.

 

8. Compatibility Between Pro/Toolkit and proe

In many cases, you cannot guarantee that the PROE used by the user of your pro/TOOLKIT program and the PROE used when you compile and link the Pro/TOOLKIT program is a version. When proe and Pro/Toolkit are used together, the compatibility rules are as follows: (the release version is the official version. This version refers to the version number of the PROE upgrade product, such as wildfire3.0 and wildfire4.0. A bulid version is an upgraded version of the same official version, such as f000 and M230 .)

1. the PROE release version is earlier than the Pro/TOOLKIT release version.

This is not supported.

2. the PROE release version is newer than the Pro/TOOLKIT release version.

This works normally in most cases, but not all. The communication method between Pro/toolkit and proe is fully compatible with all release versions. However, in some cases, modifications to the PROE kernel may need to change the source code of the Pro/Toolkit application to make the program work normally. Whether the modification is required depends on what features are used in your Pro/Toolkit program and whether the features have changed in proe and Pro/Toolkit. PTC minimizes the possible impact. The official version of Pro/TOOLKIT details all possible changes to which version.

3. The release version is the same, and the PROE build version is earlier than the Pro/TOOLKIT build version.

This is not supported in Pro/Toolkit release 20 and Pro/Toolkit release 2000i. From release 2000i2, you can basically do it unless your Pro/TOOLKIT program calls the Pro/Toolkit function added or modified in the new build version. Beginning with release 2000i2, PTC will avoid modifying the definition of the previous Pro/TOOLKIT function and minimize the number of new functions.

4. The release version is the same. The proe build version is newer than the Pro/Toolkit build version.

Always supported.

 

9. cross-platform features of Pro/Toolkit and proe

In some cases, you cannot guarantee that the computer running your Pro/TOOLKIT application and the computer used to create your Pro/Toolkit program have the same operating system and system architecture. One possible scenario is that your Pro/TOOLKIT program uses a third-party library, which can only be used on 32-bit computer systems, however, your Pro/TOOLKIT program must run on a 64-bit computer with the same operating system. Pro/TOOLKIT provides limited compatibility with asynchronous and multi-process mode programs running in this situation. For a Pro/Toolkit application in DLL mode, you must always ensure that the computer used to create the application and the computer used to run the program, has the same operating system and system architecture.

The Compatibility rules are as follows:

1. Create a computer for the Pro/TOOLKIT application and a computer for running the Pro/Toolkit application. The computer has the same operating system and system architecture.

This is always supported.

2. The computer that creates the Pro/TOOLKIT application has a smaller number of data digits than the computer that finally runs the Pro/Toolkit application. For example, the Pro/TOOLKIT program created on a Windows 32-bit system needs to run on Windows 64-bit proe.

In this case, only asynchronous mode and multi-process mode are supported.

3. A computer that creates a Pro/TOOLKIT application has a larger number of data digits than the computer that finally runs the Pro/Toolkit application. For example, the Pro/TOOLKIT program created on a Windows 64-bit system needs to run on proe of Windows 32.

This is not supported.