Skip to main content

We are in the process of implementing the 10.5 thin-client runtime.  One of the difficulties is getting event data from a web page. 

Currently, we use an ActiveX control linked to Internet Explorer, so C$GETEVENTDATA provides what we need.  We want to use WEB-BROWSER2 and get away from ActiveX.  How do I get event data using the new browser control?

We are in the process of implementing the 10.5 thin-client runtime.  One of the difficulties is getting event data from a web page. 

Currently, we use an ActiveX control linked to Internet Explorer, so C$GETEVENTDATA provides what we need.  We want to use WEB-BROWSER2 and get away from ActiveX.  How do I get event data using the new browser control?

Have you taken a look at the 10.5.0 sample web-browser2.cbl. 

03 wb-1 web-browser2
event procedure is browser-event-handler.

browser-event-handler.
evaluate event-type

   when MSG-WB-MESSAGE-RECEIVED

MSG-WB-MESSAGE-RECEIVED - a message was received from the web
  page. There are three types of messages: source, JSON, and
  string. The event-data-1 will be 0, and event-data-2 will
  be a flag saying which were received. This is a bitfield
  (because more than one type of message can be received at
  one time). W2F-HAVE-SOURCE (value 1) will be set if you can
  query the source, W2F-HAVE-JSON (value 2) will be set if you
  can query the JSON string, and W2F-HAVE-STRING (value 4)
  will be set if you can query the string. A value of 7 means
  you can query any of them, and a value of 5 means that you
  can query the source and the string, for example.

The docs have the valid events for web-browser2.

Have you taken a look at the 10.5.0 sample web-browser2.cbl. 

03 wb-1 web-browser2
event procedure is browser-event-handler.

browser-event-handler.
evaluate event-type

   when MSG-WB-MESSAGE-RECEIVED

MSG-WB-MESSAGE-RECEIVED - a message was received from the web
  page. There are three types of messages: source, JSON, and
  string. The event-data-1 will be 0, and event-data-2 will
  be a flag saying which were received. This is a bitfield
  (because more than one type of message can be received at
  one time). W2F-HAVE-SOURCE (value 1) will be set if you can
  query the source, W2F-HAVE-JSON (value 2) will be set if you
  can query the JSON string, and W2F-HAVE-STRING (value 4)
  will be set if you can query the string. A value of 7 means
  you can query any of them, and a value of 5 means that you
  can query the source and the string, for example.

The docs have the valid events for web-browser2.

I've looked at browser2.cbl which only references msg-wb-before-navigate, msg-wb-navigate-complete, and msg-wb-title-change.  I did not receive web-browser2.cbl.  I tried adding MSG-WB-MESSAGE-RECEIVED to BROWSER-1-EVENTS, but events are not being triggered when interacting with the web page.  The only event types recorded are 16429 (MSG-WB-BEFORE-NAVIGATE),16435 (MSG-WB-TITLE-CHANGE), and 16430 (MSG-WB-NAVIGATE-COMPLETE).

This is how the new browser is set up in the screen section:

This is how it is set up using the old browser control:

When I click on an icon, browser-1-events does not execute.


I've looked at browser2.cbl which only references msg-wb-before-navigate, msg-wb-navigate-complete, and msg-wb-title-change.  I did not receive web-browser2.cbl.  I tried adding MSG-WB-MESSAGE-RECEIVED to BROWSER-1-EVENTS, but events are not being triggered when interacting with the web page.  The only event types recorded are 16429 (MSG-WB-BEFORE-NAVIGATE),16435 (MSG-WB-TITLE-CHANGE), and 16430 (MSG-WB-NAVIGATE-COMPLETE).

This is how the new browser is set up in the screen section:

This is how it is set up using the old browser control:

When I click on an icon, browser-1-events does not execute.

Attaching a zipfile. Sample web page WebEvents.html has a Click me button. browser2.cbl loads that webpage (for my program I made a C:\\ftc directory and placed the htm file there. I added the  when MSG-WB-MESSAGE-RECEIVED
display message box event-data-2  and a screen shot showing that the program received the event and displayed the event-data-2 value.

community.microfocus.com/.../br2_2D00_event.zip


Attaching a zipfile. Sample web page WebEvents.html has a Click me button. browser2.cbl loads that webpage (for my program I made a C:\\ftc directory and placed the htm file there. I added the  when MSG-WB-MESSAGE-RECEIVED
display message box event-data-2  and a screen shot showing that the program received the event and displayed the event-data-2 value.

community.microfocus.com/.../br2_2D00_event.zip

I just changed my example -  define mystring in working -storage

when MSG-WB-MESSAGE-RECEIVED
inquire Wb-1, WEBMSG-STRING mystring
display message box mystring


I just changed my example -  define mystring in working -storage

when MSG-WB-MESSAGE-RECEIVED
inquire Wb-1, WEBMSG-STRING mystring
display message box mystring

What in this program triggers the MSG-WB-MESSAGE-RECEIVED event?

It's as if this browser control uses only buttons to decide how to respond to user input.  This is impractical for a page with 50 choices plus navigational functionality.  All kinds of events should be generated - mouse moved, mouse clicked, double-click, etc.  


What in this program triggers the MSG-WB-MESSAGE-RECEIVED event?

It's as if this browser control uses only buttons to decide how to respond to user input.  This is impractical for a page with 50 choices plus navigational functionality.  All kinds of events should be generated - mouse moved, mouse clicked, double-click, etc.  

Yes, let's define what you are trying to accomplish - the thread started as data in a web page and ActiveX and thin-client. Are you using the ActiveX thin-client to run your application within a web-page? Are you using a link within a web page to launch thin-client and run a program on the users's PC? I take it from the 50 choices of navigation - that is your app. A COBOL program that uses the Acu compiler and runtime. Are you looking to deploy that app on the web? If so, you should look at the AcuToWeb solution that is offered. AcuToWeb displays your COBOL UI in a browser (Safari, Firefox, Edge, whatever), the COBOL program runs on the back end (similar to using Thin client).  Browser2 is a UI control that replaces the original Acu browser control, they're meant to display HTML content within your COBOL app.


Yes, let's define what you are trying to accomplish - the thread started as data in a web page and ActiveX and thin-client. Are you using the ActiveX thin-client to run your application within a web-page? Are you using a link within a web page to launch thin-client and run a program on the users's PC? I take it from the 50 choices of navigation - that is your app. A COBOL program that uses the Acu compiler and runtime. Are you looking to deploy that app on the web? If so, you should look at the AcuToWeb solution that is offered. AcuToWeb displays your COBOL UI in a browser (Safari, Firefox, Edge, whatever), the COBOL program runs on the back end (similar to using Thin client).  Browser2 is a UI control that replaces the original Acu browser control, they're meant to display HTML content within your COBOL app.

Good idea.  What we want to accomplish is to replace an Active-X browser control (which requires the use of Internet Explorer) with a control that uses current browsers.  We produce a portal page from which almost every aspect of our application can be launched.  This is happening within an AcuCOBOL runtime session.  Part of what happens there involves calling objects; e.g. running the customer maintenance program.  When the user clicks on the 'Full Customer Maintenance" label, we need to know that ARCUSTMN.OBJ should be called.  Our current browser control returns a URL with 'swobj=ARCUSTMN' embedded in it.


Good idea.  What we want to accomplish is to replace an Active-X browser control (which requires the use of Internet Explorer) with a control that uses current browsers.  We produce a portal page from which almost every aspect of our application can be launched.  This is happening within an AcuCOBOL runtime session.  Part of what happens there involves calling objects; e.g. running the customer maintenance program.  When the user clicks on the 'Full Customer Maintenance" label, we need to know that ARCUSTMN.OBJ should be called.  Our current browser control returns a URL with 'swobj=ARCUSTMN' embedded in it.

Excellent. Now I want to see if I understand correctly. The user launches something (your app) which presents a COBOL UI with the original browser control and that control is displaying your App navigation (HTML), in the form are links. When a link is selected, that portion of the application is 1 ?? displayed within the browser control 2 a thin client alias (is ARCUSTMN an alias) that is launched and the particular app screen displays on the users desktop? 3 neither - please describe


Excellent. Now I want to see if I understand correctly. The user launches something (your app) which presents a COBOL UI with the original browser control and that control is displaying your App navigation (HTML), in the form are links. When a link is selected, that portion of the application is 1 ?? displayed within the browser control 2 a thin client alias (is ARCUSTMN an alias) that is launched and the particular app screen displays on the users desktop? 3 neither - please describe

Option two.  And it is not limited to thin client.


Option two.  And it is not limited to thin client.

Thanks, consider contacting your Sales rep and speak with a Technical Pre Sales consultant - for the U.S that would be https://www.microfocus.com/en-us/contact.  There will be some changes as Internet Explorer dealt with certain file extensions, and non IE browsers do not have automatic mechanisms like IE did.

For the first part, using browser2 to display your App navigation will be straight forward. It is each link that most likely to change - and your comment about not limited to thin-client ( possible VB app, C++, etc). In general, I think AcuToWeb will offer you a really good way to transition out of the ActiveX browser - what AcuToWeb won't do is - how to support launching the non thin client portions (aliases)  I'll stick with the COBOL portion, change the initial app ActiveX browser to browser2, displaying the HTML you have. Your App links change to something like this:

The ARCUSTMN link becomes http://127.0.0.1:3000?hostgw=127.0.0.1&portgw=8008&alias=ARCUSTMN basically server: port:alias  Each alias launches that portion of your app within the browser. Getting the COBOL that is accustomed to running under thin client should be straight forward to running under AcuToWeb.

 I hope this helps.


Thanks, consider contacting your Sales rep and speak with a Technical Pre Sales consultant - for the U.S that would be https://www.microfocus.com/en-us/contact.  There will be some changes as Internet Explorer dealt with certain file extensions, and non IE browsers do not have automatic mechanisms like IE did.

For the first part, using browser2 to display your App navigation will be straight forward. It is each link that most likely to change - and your comment about not limited to thin-client ( possible VB app, C++, etc). In general, I think AcuToWeb will offer you a really good way to transition out of the ActiveX browser - what AcuToWeb won't do is - how to support launching the non thin client portions (aliases)  I'll stick with the COBOL portion, change the initial app ActiveX browser to browser2, displaying the HTML you have. Your App links change to something like this:

The ARCUSTMN link becomes http://127.0.0.1:3000?hostgw=127.0.0.1&portgw=8008&alias=ARCUSTMN basically server: port:alias  Each alias launches that portion of your app within the browser. Getting the COBOL that is accustomed to running under thin client should be straight forward to running under AcuToWeb.

 I hope this helps.

Per the non thin client portions of your app - checkout the recently added WIN$SHELLEXECUTE library


Per the non thin client portions of your app - checkout the recently added WIN$SHELLEXECUTE library

Thanks for your help.  If you could provide one final confirmation.  Is it accurate to say that the web-browser2 control has basically the same functionality as the web-browser control, and that the most significant change is that it is not limited to use with Internet Explorer?


Thanks for your help.  If you could provide one final confirmation.  Is it accurate to say that the web-browser2 control has basically the same functionality as the web-browser control, and that the most significant change is that it is not limited to use with Internet Explorer?

Yes, that is correct. web-browser2 is a chromium based browser. What we have done is exposed the functionality of Microsoft's WebView2 to the set of Acu UI controls.