Calling Web Browser from Thin Client

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

Thanks for all that thought about an answer...we did figure out our issue.

Thanks.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

Thanks for all that thought about an answer...we did figure out our issue.

Thanks.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

Thanks for all that thought about an answer...we did figure out our issue.

Thanks.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

I was wondering if you cared to share what your solution was so that if I or others had the same problem in the future, we could look to this post for some answers. Thanks!

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

We needed to add the following line before the CALL to shell32.dll:

SET ENVIRONMENT "DLL-CONVENTION" TO 1.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

There is another way as well that worked for us. I cannot remember where it was suggested whether on the forum here or in an incident report, but doing the call to load the dll with the @WINAPI at the end like so:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll@WINAPI".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

works very well for us and gets rid of the need to set DLL_CONVENTION to a 1. It also seemed to be a bit more reliable as well.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

There is another way as well that worked for us. I cannot remember where it was suggested whether on the forum here or in an incident report, but doing the call to load the dll with the @WINAPI at the end like so:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll@WINAPI".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

works very well for us and gets rid of the need to set DLL_CONVENTION to a 1. It also seemed to be a bit more reliable as well.

I have the below in a project:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

When this logic is called from a desktop application (minus the @[DISPLAY]:) it works perfectly, logic hits and web browser is opened to the correct page. Once we add the @[DISPLAY]: to the statements and call this program using Thin Client it will pull up the web browser to the correct page, but the application hangs and never gets to the first CANCEL statement.

Does anyone have any clues as to what might be the issue?

There is another way as well that worked for us. I cannot remember where it was suggested whether on the forum here or in an incident report, but doing the call to load the dll with the @WINAPI at the end like so:

77 SW-SHOW   USAGE IS UNSIGNED-INT VALUE IS 5.
01 OPEN-COMMAND.
     05 FILLER           PIC X(04)   VALUE IS "OPEN".
     05 FILLER           PIC X(01)   VALUE IS X"00".

01 WS-ADDRESS PIC X(250) VALUE "http:\\\\www.google.com".

-----------------------------------------------------------------------------

           CALL "@[DISPLAY]:shell32.dll@WINAPI".
           CALL "@[DISPLAY]:ShellExecuteA" USING
                BY VALUE 0,
                BY REFERENCE OPEN-COMMAND,
                BY REFERENCE WS-ADDRESS,
                NULL,
                NULL,
                BY VALUE SW-SHOW.
           CANCEL "@[DISPLAY]:ShellExecuteA".
           CANCEL "@[DISPLAY]:shell32.dll".

works very well for us and gets rid of the need to set DLL_CONVENTION to a 1. It also seemed to be a bit more reliable as well.

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded