Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

> ## Using the getManagerHandle function

> The handles of the basic managers are available as global variables defined in `src/adm2/globals.i`. New managers and other useful handles should not be defined in this way, to avoid the unnecessary proliferation of global variables and the need to recompile every procedure in the framework, and also in your application, when one is added.

> For all managers, the Configuration File Manager supports a function that returns the handle based on the manager’s name, or more precisely, the `Manager` `Type` `Code` from the Manage Type maintenance utility under the Session menu. If you look at all the existing managers, you can see the `Manager` `Type` `Codes` for them, and also note the value of the `Static` `Handle` field.

> The first thing to note is that the Configuration File Manager itself is not on the list. This is because it’s always the first thing started and always starts everything else, so only other managers are listed in the configuration information for a session.

> Look at the `Static` `Handle` field in Figure 6–6 and note that all the basic managers, except for the Connection Manager, have a two- or three-letter symbol for the handle name. This indicates that there is a static handle for the manager. The Connection Manager has a `Static Handle` code of `NON`, short for none, meaning no static handle available.

> Figure 6–6: Static Handle field of the Manager Type Control wIndow

> If you edit the `Manager` `Type` for one of the other managers, a `Static` `Handle` name such as `gshSessionManager`, is shown. Figure 6–7 shows that there is no static handle for the Connection Manager.

> Figure 6–7: Manager Type Maintenance - Connection Manager

> This is because the Connection Manager was created after the other basic Progress Dynamics managers, and observes the policy of not creating new handles for new managers. To obtain its handle, use the `getManagerHandle` call, as shown:

>     hManager = DYNAMIC-FUNCTION(‘getManagerHandle’, pcManagerTypeCode).

> You can reference the API calls in the Configuration File Manager as if they were in your application procedure, but because no function prototypes for the functions are included, you must use the `DYNAMIC-FUNCTION` syntax to avoid a compile-time error message that the compiler does not recognize the function name.

> Here is an example of using this call:

>     /* testManagerHandle.p -- test the getManagerHandle function. */
>         DEFINE VARIABLE hConn AS HANDLE     NO-UNDO.
>         DEFINE VARIABLE hSess AS HANDLE     NO-UNDO.
>         hConn = DYNAMIC-FUNCTION('getManagerHandle', 'ConnectionManager').
>         hSess = DYNAMIC-FUNCTION('getManagerHandle', 'SessionManager').
>         MESSAGE "The Connection Manager is running " hConn:FILE-NAME SKIP
>                 "and the Session Manager is running" hSess:FILE-NAME.

> Note that because you do not use the global handle variables in globals.i, you do not need to reference the include file unless your code elsewhere references one of the other manager handles directly.

> Run this code to see the Message window, as shown:

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095