Open topic with navigation
This topic includes the following sections:
To access an ActiveX control from your application, you’ll need to do the following:
|1.||Register the file that contains the ActiveX control. See Registering an ActiveX control.|
|2.||Write a routine that loads and processes the ActiveX control and call the routine from your program. For example, you might write a hyperlink method, a drill method, or a subroutine to process a menu entry, depending on how the user will access the ActiveX control.|
|3.||Modify your user interface to allow access to the ActiveX control. For example, you might add a hyperlink prompt, drilldown button, or menu entry.|
You could combine steps 2 and 3 and make your hyperlink or drill method (for example) the routine that loads and processes the ActiveX control.
Let’s say that we want users to be able to display a calendar to enter a date in a Renewal date field. We’ll use an ActiveX calendar control called AXCalendar, and the user will click on a drilldown button to display it, as shown below.
To process the control, we write the routine ax_date_drillmethod, which includes a drill method that calls the ActiveX routine.
.subroutine ax_date_drillmethod .include "DBLDIR:ActiveX.def" .include WND:tools.def record tkwid ,i4 ;Toolkit window ID axwid ,i4 ;ActiveX container ID axid ,i4 ;ActiveX control ID method_id ,i4 ;Window event ID group a_date ,a day ,d2 month ,d2 year ,d4 endgroup .proc tkwid = %ax_tkwin("tkdate",12,40, axwid) ;Create toolkit container axid = %ax_load(axwid, "MSCAL.Calendar.7") ;Load control xcall ax_bind(axid, "DblClick", "OnDblClick") ;Bind double-click event ;Create and assign toolkit container window close event method_id=%u_wndevents(D_CREATE,,D_EVENT_CLOSE,'OnClose') xcall u_wndevents(D_ASSIGN,method_id,tkwid) xcall u_window(D_PLACE, tkwid, 10, 20) ;Place Toolkit window xcall ax_input(tkwid) ;Process control if (g_entnam.eq.'DONE') ;Check for menu entry begin a_date.day = %ax_getint(axid, "Day") a_date.month = %ax_getint(axid, "Month") a_date.year = %ax_getint(axid, "Year") xcall i_force(a_date) end xcall u_window(D_DELETE, tkwid) ;Delete Toolkit container clear g_select xreturn .end .subroutine OnDblClick .proc xcall m_signal('DONE') xreturn .end .subroutine OnClose .proc xcall m_signal('CLOSE') xreturn .end
Finally, we need to modify the script file entry for the Renewal date field to add the drilldown button. The entry will look something like this:
.field c_rd, d8, date, pos(3, 38), prompt("Renewal date"), fpos(3, 52),- bzro, help("h_rd"), info("DDMMYY"), drill_method("ax_date_drillmethod")
Before an application can use an ActiveX control, the control must be registered with the Windows operating system. Once the file is registered, it should not be moved or renamed. You can register a control manually or programmatically:
You can also use the Synergy DLL API to register ActiveX controls. Use the DLL API to open the .ocx file as a DLL, and then call the DllRegisterServer routine within it. For example,
hndl = %dll_open("OCXDIR:mycontrol.ocx") xcall dll_call(hndl,,"DllRegisterServer") xcall dll_close(hndl)
To avoid doing this every time the control is loaded, trap an error on the load and register the control only if the load fails. This method is particularly useful for shared server installations where controls may be added to the existing application without performing an installation script on each workstation. See Synergy DLL API for more information.
We recommend you always check the loading of your ActiveX control with the ActiveX Diagnostic Utility before accessing the control from your application.
You can trap exceptions generated by ActiveX controls as you load them or use them in your Toolkit application. The EXITE mechanism is used to generate errors from these exceptions. These errors can be trapped by ONERROR statements if they are in effect when the ActiveX subroutine that loads or uses the control is called. When an error is trapped, control is transferred to the code for the error if the error is in the error list for the ONERROR statement (or there’s a catch‑all label).
If the error isn’t trapped by the ONERROR statement, or if no ONERROR statement is in effect, any exception generated by the ActiveX control will cause a fatal runtime error at the line where the ActiveX subroutine was called.