>>  <<  Ndx  Usr  Pri  JfC  LJ  Phr  Dic  Rel  Voc  !:  wd  Help  User

J OLE Automation Server

There are two servers:

  • JEXEServer is the J Front End J.EXE file (which uses J.DLL).

  • JDLLServer is the J Engine J.DLL file.
  • Any application with OLE Automation controller support (C#, Visual Basic, Excel, Visual C++,...) can use JEXEServer and JDLLServer.

    An EXE server runs as a separate application from the client. It is a local server. JEXEServer provides wd as well as the J Engine and can provide full IDE support. As a developer, you have full access to both client and J development and debug environments.

    A DLL is part of the client application and uses the same memory space. It is an in-process server. A client accesses DLL services almost as efficiently as it accesses its own native services. JDLLServer is not as convenient as JEXEServer for development purposes, but it is very efficient and is ideal for runtime applications that don't need wd services.

    You can develop your application with JEXEServer, and if appropriate run it in production with JDLLServer.

    J64 servers have not been tested and are not officially supported.

    J.DLL (J32 and J64) can be called directly (Calling J.DLL) without using OLE.


    JEXEServer and JDLLServer must be registered with your system before they can be used. To register, run jreg.bat.

    If there are problems later when accessing the J servers it may be because they are no longer properly registered. You can always run jreg.bat to register the servers again. In particular, you will need to do this if you move the J system files to another directory.

    Using JEXEServer and JDLLServer

    You should be familiar with both J and the client before tackling them in a client/server combination. In particular you should be familiar with using other OLE Automation servers from your client before working with J.

    J server methods:
       Do                     execute J sentence
       ErrorText/ErrorTextM   get error text
       Get/GetB/GetM          get value of a J variable
       Set/SetB/SetM          set value of a J variable
       Transpose              return array data transposed 
    JEXEServer only methods (no error and no effect in JDLLServer):
       Log                    ijx logging on or off
       Show                   ijx show or hide
       Quit                   causes close when last object released
    J Server methods that have no effect:

    Loading Profile

    No scripts are loaded when the J server starts. In some cases you may want to load the standard J profile. Run the following sentences with the Do method to load profile.
    (3 : '0!:0 y')<BINPATH,'\profile.ijs'
    The 1st sentence sets BINPATH_z_ as the path to the J.DLL file (standard J bin folder). Foreign 1!:46 in Windows returns j.dll full path and can be used by JEXEServer and JDLLServer clients to find the J folder. The result in unix is ''.

    The 2nd sentence sets ARGV_z_ as the commandline parameters used by profile. The -jijx is ignored by JDLLServer and causes JEXEServer to not create an ijx window. You can modify this as appropriate but ARGV_z_ must be a list of boxed strings.

    The 3rd creates an unnamed verb that loads profile.ijs from BINPATH.

    Creating an ijx window

    A JEXEServer ijx window can make development much easier. After you have loaded profile run the following sentence to create an ijx window.
    Use Show(0) to hide it and Show(1) to show it.


    Folder ~system\examples\ole has C++, VB, and Excel examples that use J servers.

    Folder ~system\examples\ole\cpp\p_jcl can be used in VC++ 6.0 and VS2005 C++ development environments to experiment with using J servers from C++. Open jcl.dsw in VC++ 6.0 and open jcl.sln in VS2005.

    BSTR treated as 8 bit values

    The original J server methods were implemented before J supported UTF8 or UTF16 data. BSTR data is transferred between the client and J by ignoring the top byte. This is fine for 7 bit ascii data but means that unicode 16 bit data is treated as if the top 8 bits were always 0.

    A future J release may treat BSTR data correctly in all the methods. In the meantime the following workaround is suggested.

    Use Get and Set methods to transfer the required unicode data as UTF8 bytes. This data will be a byte array on the client side and a UTF8 character array on the J side. On the client side there are classes (UTF8Encoding) that convert between BSTR and UTF8 byte arrays. And on the J side you can either use the UTF8 character array directly or use foreigns to convert to other formats (such as 16 bit character array).
    >>  <<  Ndx  Usr  Pri  JfC  LJ  Phr  Dic  Rel  Voc  !:  wd  Help  User