With thin client is it possible to force an activeX to run on the server not the client?

We have a point of sale application that uses an activeX for SSL communication which works fine in a normal install. However, we have some stores who use thin client  for a remote point of sale set up. They have to install and register the activex on the client and it works but is MUCH slower. Also they will periodically get what appears to be a file error but instead of "File error xx on somefile" the first line says "The operation completed successfully." and the rest of the error message is as you would expect "COBOL error at 000304 in SOMEPROG" and the called from chain after that.

What I would really like to do is find a way to force the activex to run on the server and not the client. Is there a way to force an activex to run on the server and not the client?

Thanks, Steve.

  • Does the ActiveX control have a UI ... is it displayed?? ... if the answer is yes, then no you cannot run the control on a server. If the answer is no, that the ActiveX control does not have a UI .. it is not displayed .. it uses the CREATE verb in the COBOL program then yes, you can run it on the server. You'd have to have the ActiveX in it's own program so that it can be called, once you have programmed it that way, your standard programs can call it using AcuConnect distributed processing and have the control and process occur on the server.

  • The control does not have a visible UI but I do use the "DISPLAY" verb in the procedure division. I have tried it with the "CREATE" verb but it does not work. this is the way I call it:

                  display SSLSocketWizard

                    handle in SSLSocketWizard1

                     line 1 col 1 lines 2 size 10

                  visible 0

                  EVENT PROCEDURE IS SSL-EVENT.

    or

                 CREATE SSLSocketWizard

                  HANDLE in SSLSocketWizard1

                  EVENT PROCEDURE IS SSL-EVENT

    I am not sure why I would need to use "DISPLAY". Am I doing something wrong with "CREATE"?

    Thanks,

    Steve

  • I'm not sure what version you have, however the create verb should work in a similar way to the display verb.

    I would raise an incident with customer care .. as the create verb should allow you to execute the COM object on the server (without AcuConnect Distributed Processing)

    CREATE object-name creates a COM object.  

    CREATE object-name  

    HANDLE { IN } object-handle      

    SERVER-NAME { IS } server-name

    Server-name identifies a remote machine on which to create and execute the COM object. It can be specified as a UNC, DNS name, or IP address. Server-name must be the name of a Windows machine. CREATE cannot create objects on non-Windows servers. When a server-name is provided - the COM object's interface is instantiated on the machine where the application is executing and the back-end is instantiated on the specified server where the work is done and resources can be accessed. In this case the COM object must be registered on both machines.

  • Before testing the thin client part I was just trying to switch from DISPLAY to CREATE in a non-thin client environment but CREATE does not seem to work.

    I will raise an incident with customer care and see if they can shed any light on the situation.

    Thanks,

    Steve

  • Before testing the thin client part I was just trying to switch from DISPLAY to CREATE in a non-thin client environment but CREATE does not seem to work.

    I will raise an incident with customer care and see if they can shed any light on the situation.

    Thanks,

    Steve