Where:  

To detect whether or not you're actually working on a WindX PC in Command mode, look for the special prompt -} ... i.e., a hyphen with curly brace. In your applications, a test for one of the following indicators will tell you that your session is running under WindX:

DEC(MID(MSE, 22,1))>0
TCB(88)<>0

For more information, refer to the TCB( ) Function, and the MSE System Variable.

You can create a global variable in your WindX setup, and use it later to test for the presence of a WindX client PC connection; then, if WindX is running the session, you can use the [WDX] tag. In the following example, the user-defined variable %WDX below is only set when WindX is running, otherwise its value is null:

IF MID(MSE,22,1)>$00$ AND MID(MSE,22,1)<$FF$
        THEN %WDX$="[WDX]"

Use such a global variable in a statement like OPEN(30)%WDX$+"*WINPRT*" to bypass an Error#12:Filedoesnotexist(oralreadyexists) when WindX isn't running.

How ProvideX Detects WindX

ProvideX uses terminal type to detect a WindX session. In UNIX, ProvideX recognizes two terminal types as potential WindX stations (TERM="winterm" for the WindX client PC and TERM="ansi"). Since most UNIX systems and applications can't recognize or use the wintermtype, the ProvideX ansi device driver sends a special escape sequence to a terminal to test for a WindX client. If the terminal is a WindX PC, a special response is generated. If no response is generated before a time-out occurs, ProvideX assumes the device is ansi.

GUI Requests

Once the ProvideX session on the server recognizes the terminal as a WindX station, it changes the internal settings to allow graphical requests to be routed correctly. (Then, graphical requests are automatically tokenized and forwarded to WindX for processing. That is, you do not need the [WDX] tag.)

For instance, a server command to print a picture in a UNIX environment would automatically be sent to WindX for the client. ProvideX transmits standard mnemonics to WindX as an escape ($1B$) followed by the mnemonic in native form. Traffic from the host/server is minimized because the WindX client's ProvideX interpreter handles a lot of the functionality locally (on the client) for screen refreshing and graphical requests.

In WindX, your instruction to print is sent to the client, bundled as is. When you use mnemonics and/or graphics like .bmp’s, they must exist on the client or be accessible to the client. The following example uses a 'PICTURE' that is defined and shared on a common Windows server instead of being stored on each individual client machine: print 'picture'(10,10,10,10),"\\serv_name\driveshare\your_bmps\that.bmp"

IF WDX% <> $00$
    THEN EXECUTE "[WDX]MNEMONIC(LFO)'5X'=$1B+hex$"
    ELSE GOTO MY_LABEL

The following example sets the 'B0' System Parameter, on a WindX PC using a [WDX] command from a UNIX host:

EXECUTE "[wdx]SET_PARAM 'B0'"

CALL "[WDX]subprog",params

This format enables the server to CALL a subprogram that exists and runs remotely on the client. It is true distributed processing. The server's files and global variables are not accessible to your subprogram. Your remote call passes parameters back and forth, not data files. You can pass a maximum of 20 parameters/arguments, in a comma-separated list.

For example, you can call applications like special printer device drivers you have built on the client to handle print mnemonics:

CALL "[WDX]*dev/your_driver_name"

You can use a similar format to call the ProvideX *WindX.utl (utility) functions. For further information, see format 10 [WDX] and *WindX.utl,
[WDX]*WINDEV* Escape Sequences:.

OPEN (chan[,fileopt])"[WDX]filename"
OPEN (chan,OPT=settings$)"[WDX]port_id"

Use this format in programs running on your server when you're opening remote files or ports. That is, using [WDX] as a prefix to the pathname of your file (or port, etc.) tells WindX to open it remotely on the client. WindX automatically forwards requests (i.e., file I/O directives) for processing.
 

The following example opens a remote file,

OPEN (1)"[WDX]CLIENT_PATH\CLIENT_FILE"

Use a similar format to open a COM port for direct access to a serial device (e.g., ,a serial printer or weigh scale) on the client PC without going through a spooler,

LET SETTING$="9600,n,8,1,x"
OPEN (5,OPT=SETTING$)"[WDX]COM2"
or
OPEN (5,OPT="9600,n,8,1,x",ERR=OOPS)"[WDX]COM2"

OPEN (chan[,fileopt])"[WDX][tag]prog;[params]"

[WDX] can be used in conjunction with other file tags; e.g.,

0010 OPEN (1)"[WDX][DDE]excel;existing_worksheet.wk1"

OPEN [INPUT] (chan[,fileopt])"[WDX]*device*[;Q_name[;Q_options]]"

ProvideX opens the special device files *WINPRT* and *WINDEV* on the PC/server which issues the command. Except in UNIX (where it's done automatically), use [WDX] with OPEN [INPUT] directives for the two specialty files to direct any print jobs and dialogues to the WindX client PC, which will in turn use its Windows print subsystem API to deal with the jobs and send them to the given printer; e.g.,

OPEN (7,ERR=1500)"[WDX]*WINPRT*"

With a WindX client and an NT Server, if you do not use [WDX] in your OPEN directive, then the printer selection dialogue will appear on the server console, and any print queue you name directly must exist on the NT server in the Control Panel printers folder.

See also [WDX]*WINDEV* Escape Sequences:, *WINDEV* Raw Print Mode, and *WINPRT* Windows Printing.

NEW("[WDX]ClassName")
DEF OBJECT com_id,"[WDX]objname"

The [WDX] tag can be used to create OOP/COM objects and manipulate them across a WindX connection as if they existed locally.

Methods can be passed arguments and receive results; however, only the result of a method will be returned across a remote connection. Any changes to the arguments of a method by the remote object will not be returned across the connection. Arguments are therefore considered to be passed by value only. If you need to retrieve arguments as well as the result, you must place your code in a program on the WindX workstation and interact with that code.

Event handling is not supported across a remote connection. Event mapping must occur within the remote object. The remote object will not have access to any server resources. At most, the remote event could pass a CTL back to the local server for action. It is recommended that objects requiring event processing exist completely on the remote and interact only with the local WindX session on the remote.

CALL "[WDX]*WindX.utl;function",params

Use this format to call ProvideX utilities/functions in the WindX.utl utility program; e.g.,

call "[wdx]*windx.utl;Get_LWD",Station_dir$
call "*windx.utl;spawn",cmdline$,inifile$,appfid$

The following functions are built into WindX to simplify development tasks: