Designer Questions

WinAppxD was replaced by the APPX Login Manager in Release 5.0.0. See this page for installing & configuring the Login Manager.

3.1) How do I 'RUN' an external command on the server?

Just like you would under UNIX, but make sure that you use the
backslash character rather than forward slash character as a path
separator. Also make sure that you DOUBLE the backslashes.

For example, you could use:
SET --- TEMP 80 = X:\\APPX\\...\\PROGRAM.EXE
RUN --- TEMP 80

If you want to run an MS-DOS batch file, you could use:
SET --- TEMP 80 = C:\\WINNT\\SYSTEM32\\CMD.EXE /C BT.BAT
RUN --- TEMP 80

This opens up a 'DOS Shell', from which you can then run the
batch file. Note that the NT command interpreter is named
'CMD.EXE'. If you have done other APPX for Windows development
on Window, s 95 or Windows 3.1, you may be used to referencing
'COMMAND.COM' in RUN statements. That won't work in NT.

If your batch file is in a different directory (which it
probably is), note that to specify a full path to the batch
file, you must use double backslashes, \\, as the path
separator, not just single ones. See the CMD.EXE path above
for an example of what a path used anywhere in the RUN
statement needs to look like.

Note: Since this program will execute on the server, make sure
that the drive and path specified in the command line are
accessible on the server (as opposed to the client).

Compatibility note: Some customers report that they can use
UNIX-style single forward slashes, instead of double
backslashes, as a path separator. We're not sure why this
works, because the Windows function used to call external
programs is not documented as accepting them, and it's not
"normal Microsoft convention" for this to work, so consider
it unsupported.

3.2) How do I 'RUN' an external command on the client?

There is currently no official or supported way to do this.

The following is provided as a hint for desperate consultants
and end-user sites, and APPX does not endorse, support or
troubleshoot the, use of such a technique. If you do this, you
are on your own.

&nbs, p; If you are desperate and willing to take responsibility for your
own actions, you can probably find out the client's IP address,
then use a combination of programs like Ataman Software's
rshd.exe and rsh.exe, to remotely call a client program from the
server. Ataman Software can be found on the web at
http://www.ataman.com . This technique is probably only
appropriate for intranet use, since it requires 'rshd.exe' to
be installed on all clients. Internet users would see it as
extremely 'not good' for you to be invoking local commands on
their machines from across the Internet. Unless the client and
server are separated by a firewall, you can probably make this
work on your intranet, but you have to understand a bit about
TCP/IP networking and rshd/rsh, and be willing do some coding
and to fight with a few configuration issues. PLEASE do not
even think of doing this if you are not familiar with TCP/IP
security issues.

3.3) How do I 'RUN' a DOS command like 'copy file1 oldfile1' on the server?

Many common DOS commands are actually part of the DOS command
shell, not separate executables. To run them, you need to invoke
the command shell. Use a double backslash as the path separator.

For example, you might use:
SET --- TEMP 80 = C:\\WINNT\\SYSTEM32\\CMD.EXE /C "COPY FIL1 OLD1"
RUN --- TEMP 80

Note that this command line IS NOT portable between Windows NT
and other Windows OS's (95 and 3.11). The command interpreter
on Windows 95 and 3.11 is 'COMMAND.COM', and on Windows NT it is
'CMD.EXE'.

If your files being copied are a different directory (which they
probably are), note that to specify a full path to the files,
you probably have to use double backslashes, \\, as the path
separator, not just single ones. See the CMD.EXE path above
for an example of what a path used anywhere in the RUN
statement needs to look like.

Compatibility note: Some customers report that they can use
UNIX-style single forward slashes, instead of double
backslashes, as a path separator. We're not sure why this
works, because the Windows function used to call external
programs is not documented as accepting them, and it's not
"normal Microsoft convention" for this to work, so consider
it unsupported.

3.4) A process I wrote under UNIX using rt_read_stream() or rt_write_stream() doesn't work under NT. Why?

UNIX text file lines are delimited by a hex '0A' (new line)
character. MS-DOS text files lines are delimited by hex '0D'
then hex '0A' (carriage return and new line) characters.
Therefore, if you had a text file containing 80 character lines,
your process probably expects to see 80 characters plus a 1-char
line delimiter. This worked fine on UNIX, but under Windows,
your process should be looking for 80 characters plus a 2-char
line delimiter.

3.5) I designed some screens under UNIX. They look different under Windows. Why?

The process of GUI-izing APPX screens causes columns to shift
slightly, because of the shadow and button effects used.

In addition to that, the GUI versions draw row/column borders
'between' the rows/columns, while borders occupy a physical row/
column on the text based versions. This means your carefully
planned screens (under the text version), look wrong under
Windows. Pop up windows, in particular, look wrong because the
underlying information (which was obscured under the text version)
now shows thru. If you go the other way (design under GUI, run
under text), then the borders will likely now obscure information
that used to be visible under the GUI.

3.6) How can I get the network IP address of the client's PC?

The following ILF code will do it. Be warned that there can
be multiple records for a given user, if that user has more
than one APPX session running (or if they got disconnected and
their old LUSER record has not been cleaned up yet). This code
sample retrieves only the first record for a given user ID.

SET 0SA LUSER UID = --- USER ID
READ 0SA LUSER HOLD 0 FAIL 0 KEY IS LUSER UID
SET --- TEMP 80 = 0SA LUSER TERM ID

--- TEMP 80 now contains the client IP address.

3.7) How can I programmatically determine what platform my application is running on?

For reasons of application maintainability, a designer may want to
develop one version of an application that runs on both UNIX and
Windows platforms. However, the designer may use OS-dependent
features like the rt_* functions to process text files, or the RUN
command, which require different handling on UNIX than on Windows.
So, they need a reliable way to detect at run-time, which version
of those OS-dependent features to invoke.

As documented in ECR 3842, you can code the following in Start
of Process (or wherever it makes sense to put it):

PASS 0AD VERSION FILE SHARE? Y
CALL ,RT_VERSION RESIDENT? N END? N FAIL 0
*
SET 0AD VERSION TYPE = Operating System Type
READ 0AD VERSION HOLD 0 FAIL 0 KEY IS VERSION TYPE
SET 0AD VERSION DATA = 0AD VERSION DATA

Note: You will have to use OPT-88 to save a READ statement
referencing the VERSION file.

VERSION DATA contains either 'VMS', 'UNIX', 'WINDOWS' or 'DOS'.
You can store that to your favorite WORK field and test that
value against 'WINDOWS', 'UNIX' or whatever other platform you
care about.

3.8) The comma-delimited update process generated by APPX does not work under Windows. Why, and what can I do about it?

Auto-generated APPX processes created by the APPX "Comma Delimited
Update" utility process do not work correctly under Windows. The
APPX process that auto-generates ILF for Comma Delimited file
creation uses a hex '0a' character (line feed) as a record
delimiter. This is correct for UNIX, however Windows requires the
hex '0d' then hex '0a' character combination (carriage return,
line feed).

Workaround: The designer must go into the ILF for each generated
update process after the fact and make sure that a hex '0d' is
appended before each hex '0a' is appended.

3.9) How do I get special fonts and printer attributes to print under Windows printing?

Some customers are successfully using a package called "Forms
and Fonts" which is available from LBM Systems, at
http://www.lbmsys.com.

However, APPX Software has not used this third-party package
in-house and thus does not specifically endorse or support
its use. There may be other packages offering similar
functionality (which we have not heard of), as well.

It is also possible to use the "-font=", "-pitch=" and
"-orientation=" printer and/or form options, which you can enter
from within System Administration / Configuration / Forms or
Printers, if you are using the APPX-provided Winprint without
any third party printing software. Any combination of orientation,
font and point size that works in Windows (for example, when
printing from a simple program like Notepad) should work for APPX
as well. Test it to be sure, because sometimes obvious things
don't work -- not all fonts are installed on all systems, in the
same point sizes and orientations, and unfortunately some printer
drivers may ignore these parameters. Also, be warned, "-pitch"
is a Microsoft misnomer. It's really point size (which is sorta
the reverse of pitch), as far as I can tell. An example set of
form options for a 132-column landscape report on a DeskJet might
be something like:
-orientation=landscape,-font="Courier New",-pitch=10

3.10) How can I programmatically tell which Windows platform I am running on?

One can look in the VERSION file to find out that one is running
under WINDOWS or UNIX. If running under UNIX, one can use the
HOST TYPE information to determine which flavor of UNIX is being
used. However, no similar capability exists to determine
whether one is running under Windows NT or Windows 95.

A designer may want to know this because they want to call
an external command that has different switches on 95 and NT,
or because they wish to invoke a 'DOS' command using the
command shell, which has different names on 95 and NT.

One way to do this is to ,rt_getenv the value of the COMSPEC
environment variable, which contains the path to the command
interpreter. Once you have this, you can either start your
DOS command path with it (if running a command like 'copy'
which must be prefixed with the path to the DOS command shell)
or inspect it to see if it contains "COMMAND.COM" (which means
it is a Windows 95 system) or "CMD.EXE" (which means it is a
Windows NT system). Note that you may have to pre-process
the path, adding double backslashes, before using it as part
of a RUN statement.

Note: COMSPEC's value may be more than "C:\COMMAND.COM". For
example, it may be "C:\COMMAND.COM /E:14350 or something like
that, because the user needed to increase the size of the
environment area . Similarly, the path to the command shell
will vary depending on where Windows 95 (or Windows NT) was
installed. Therefore, please be sure to look for "COMMAND.COM"
or "CMD.EXE" in the string without relying on an exact match
for the entire string.