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?

  • Verified Answer

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

    Thanks.

  • Verified Answer

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

    Thanks.

  • Verified Answer

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

    Thanks.

  • 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!

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

              SET ENVIRONMENT "DLL-CONVENTION" TO 1.

  • 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.

  • 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.

  • 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.