DesignerQuestions < Main

Tags: view all tags
---+ Designer Questions

*WinAppxD was replaced by the APPX Login Manager in Release 5.0.0. See <a href="APPXLoginManagerForWindows" target="_self">this page</a> for installing & configuring the Login Manager.*

%TOC%
---++ 3.1) How do I 'RUN' an external command on the server?

<br /> Just like you would under UNIX, but make sure that you use the<br /> backslash character rather than forward slash character as a path<br /> separator. Also make sure that you DOUBLE the backslashes.<br /><br /> For example, you could use:<br /> SET --- TEMP 80 = X:\\APPX\\...\\PROGRAM.EXE<br /> RUN --- TEMP 80<br /><br /> If you want to run an MS-DOS batch file, you could use:<br /> SET --- TEMP 80 = C:\\WINNT\\SYSTEM32\\CMD.EXE /C BT.BAT<br /> RUN --- TEMP 80<br /><br /> This opens up a 'DOS Shell', from which you can then run the<br /> batch file. Note that the NT command interpreter is named<br /> 'CMD.EXE'. If you have done other APPX for Windows development<br /> on Window, s 95 or Windows 3.1, you may be used to referencing<br /> 'COMMAND.COM' in RUN statements. That won't work in NT.<br /><br /> If your batch file is in a different directory (which it<br /> probably is), note that to specify a full path to the batch<br /> file, you must use double backslashes, \\, as the path<br /> separator, not just single ones. See the CMD.EXE path above<br /> for an example of what a path used anywhere in the RUN<br /> statement needs to look like.<br /><br /> Note: Since this program will execute on the server, make sure<br /> that the drive and path specified in the command line are<br /> accessible on the server (as opposed to the client).<br /><br /> Compatibility note: Some customers report that they can use<br /> UNIX-style single forward slashes, instead of double<br /> backslashes, as a path separator. We're not sure why this<br /> works, because the Windows function used to call external<br /> programs is not documented as accepting them, and it's not<br /> "normal Microsoft convention" for this to work, so consider<br /> it unsupported.<br /><br />
---++ 3.2) How do I 'RUN' an external command on the client?

<br /> There is currently no official or supported way to do this.<br /><br /> The following is provided as a hint for desperate consultants<br /> and end-user sites, and APPX does not endorse, support or<br /> troubleshoot the, use of such a technique. If you do this, you<br /> are on your own.<br /><br /> &nbs, p; If you are desperate and willing to take responsibility for your<br /> own actions, you can probably find out the client's IP address,<br /> then use a combination of programs like Ataman Software's<br /> rshd.exe and rsh.exe, to remotely call a client program from the<br /> server. Ataman Software can be found on the web at<br /> <a href="http://www.ataman.com/" target="_blank">http://www.ataman.com</a> . This technique is probably only<br /> appropriate for intranet use, since it requires 'rshd.exe' to<br /> be installed on all clients. Internet users would see it as<br /> extremely 'not good' for you to be invoking local commands on<br /> their machines from across the Internet. Unless the client and<br /> server are separated by a firewall, you can probably make this<br /> work on your intranet, but you have to understand a bit about<br /> TCP/IP networking and rshd/rsh, and be willing do some coding<br /> and to fight with a few configuration issues. PLEASE do not<br /> even think of doing this if you are not familiar with TCP/IP<br /> security issues.<br /><br />
---++ 3.3) How do I 'RUN' a DOS command like 'copy file1 oldfile1' on the server?

<br /> Many common DOS commands are actually part of the DOS command<br /> shell, not separate executables. To run them, you need to invoke<br /> the command shell. Use a double backslash as the path separator.<br /><br /> For example, you might use:<br /> SET --- TEMP 80 = C:\\WINNT\\SYSTEM32\\CMD.EXE /C "COPY FIL1 OLD1"<br /> RUN --- TEMP 80<br /><br /> Note that this command line IS NOT portable between Windows NT<br /> and other Windows OS's (95 and 3.11). The command interpreter<br /> on Windows 95 and 3.11 is 'COMMAND.COM', and on Windows NT it is<br /> 'CMD.EXE'.<br /><br /> If your files being copied are a different directory (which they<br /> probably are), note that to specify a full path to the files,<br /> you probably have to use double backslashes, \\, as the path<br /> separator, not just single ones. See the CMD.EXE path above<br /> for an example of what a path used anywhere in the RUN<br /> statement needs to look like.<br /><br /> Compatibility note: Some customers report that they can use<br /> UNIX-style single forward slashes, instead of double<br /> backslashes, as a path separator. We're not sure why this<br /> works, because the Windows function used to call external<br /> programs is not documented as accepting them, and it's not<br /> "normal Microsoft convention" for this to work, so consider<br /> it unsupported.<br /><br />
---++ 3.4) A process I wrote under UNIX using rt_read_stream() or rt_write_stream() doesn't work under NT. Why?

<br /> UNIX text file lines are delimited by a hex '0A' (new line)<br /> character. MS-DOS text files lines are delimited by hex '0D'<br /> then hex '0A' (carriage return and new line) characters.<br /> Therefore, if you had a text file containing 80 character lines,<br /> your process probably expects to see 80 characters plus a 1-char<br /> line delimiter. This worked fine on UNIX, but under Windows,<br /> your process should be looking for 80 characters plus a 2-char<br /> line delimiter.<br /><br />
---++ 3.5) I designed some screens under UNIX. They look different under Windows. Why?

<br /> The process of GUI-izing APPX screens causes columns to shift<br /> slightly, because of the shadow and button effects used.<br /><br /> In addition to that, the GUI versions draw row/column borders<br /> 'between' the rows/columns, while borders occupy a physical row/<br /> column on the text based versions. This means your carefully<br /> planned screens (under the text version), look wrong under<br /> Windows. Pop up windows, in particular, look wrong because the<br /> underlying information (which was obscured under the text version)<br /> now shows thru. If you go the other way (design under GUI, run<br /> under text), then the borders will likely now obscure information<br /> that used to be visible under the GUI.<br /><br />
---++ 3.6) How can I get the network IP address of the client's PC?

<br /> The following ILF code will do it. Be warned that there can<br /> be multiple records for a given user, if that user has more<br /> than one APPX session running (or if they got disconnected and<br /> their old LUSER record has not been cleaned up yet). This code<br /> sample retrieves only the first record for a given user ID.<br /><br /> SET 0SA LUSER UID = --- USER ID<br /> READ 0SA LUSER HOLD 0 FAIL 0 KEY IS LUSER UID<br /> SET --- TEMP 80 = 0SA LUSER TERM ID<br /><br /> --- TEMP 80 now contains the client IP address.<br /><br />
---++ 3.7) How can I programmatically determine what platform my application is running on?

<br /> For reasons of application maintainability, a designer may want to<br /> develop one version of an application that runs on both UNIX and<br /> Windows platforms. However, the designer may use OS-dependent<br /> features like the rt_* functions to process text files, or the RUN<br /> command, which require different handling on UNIX than on Windows.<br /> So, they need a reliable way to detect at run-time, which version<br /> of those OS-dependent features to invoke.<br /><br /> As documented in ECR 3842, you can code the following in Start<br /> of Process (or wherever it makes sense to put it):<br /><br /> PASS 0AD VERSION FILE SHARE? Y<br /> CALL ,RT_VERSION RESIDENT? N END? N FAIL 0<br /> *<br /> SET 0AD VERSION TYPE = Operating System Type<br /> READ 0AD VERSION HOLD 0 FAIL 0 KEY IS VERSION TYPE<br /> SET 0AD VERSION DATA = 0AD VERSION DATA<br /><br /> Note: You will have to use OPT-88 to save a READ statement<br /> referencing the VERSION file.<br /><br /> VERSION DATA contains either 'VMS', 'UNIX', 'WINDOWS' or 'DOS'.<br /> You can store that to your favorite WORK field and test that<br /> value against 'WINDOWS', 'UNIX' or whatever other platform you<br /> care about.<br /><br />
---++ 3.8) The comma-delimited update process generated by APPX does not work under Windows. Why, and what can I do about it?

<br /> Auto-generated APPX processes created by the APPX "Comma Delimited<br /> Update" utility process do not work correctly under Windows. The<br /> APPX process that auto-generates ILF for Comma Delimited file<br /> creation uses a hex '0a' character (line feed) as a record<br /> delimiter. This is correct for UNIX, however Windows requires the<br /> hex '0d' then hex '0a' character combination (carriage return,<br /> line feed).<br /><br /> Workaround: The designer must go into the ILF for each generated<br /> update process after the fact and make sure that a hex '0d' is<br /> appended before each hex '0a' is appended.<br /><br />
---++ 3.9) How do I get special fonts and printer attributes to print under Windows printing?

<br /> Some customers are successfully using a package called "Forms<br /> and Fonts" which is available from LBM Systems, at<br /> http://www.lbmsys.com.<br /><br /> However, APPX Software has not used this third-party package<br /> in-house and thus does not specifically endorse or support<br /> its use. There may be other packages offering similar<br /> functionality (which we have not heard of), as well.<br /><br /> It is also possible to use the "-font=", "-pitch=" and<br /> "-orientation=" printer and/or form options, which you can enter<br /> from within System Administration / Configuration / Forms or<br /> Printers, if you are using the APPX-provided Winprint without<br /> any third party printing software. Any combination of orientation,<br /> font and point size that works in Windows (for example, when<br /> printing from a simple program like Notepad) should work for APPX<br /> as well. Test it to be sure, because sometimes obvious things<br /> don't work -- not all fonts are installed on all systems, in the<br /> same point sizes and orientations, and unfortunately some printer<br /> drivers may ignore these parameters. Also, be warned, "-pitch"<br /> is a Microsoft misnomer. It's _really_ point size (which is sorta<br /> the reverse of pitch), as far as I can tell. An example set of<br /> form options for a 132-column landscape report on a DeskJet might<br /> be something like:<br /> -orientation=landscape,-font="Courier New",-pitch=10
---++ 3.10) How can I programmatically tell which Windows platform I am running on?

<br /> One can look in the VERSION file to find out that one is running<br /> under WINDOWS or UNIX. If running under UNIX, one can use the<br /> HOST TYPE information to determine which flavor of UNIX is being<br /> used. However, no similar capability exists to determine<br /> whether one is running under Windows NT or Windows 95.<br /><br /> A designer may want to know this because they want to call<br /> an external command that has different switches on 95 and NT,<br /> or because they wish to invoke a 'DOS' command using the<br /> command shell, which has different names on 95 and NT.<br /><br /> One way to do this is to ,rt_getenv the value of the COMSPEC<br /> environment variable, which contains the path to the command<br /> interpreter. Once you have this, you can either start your<br /> DOS command path with it (if running a command like 'copy'<br /> which must be prefixed with the path to the DOS command shell)<br /> or inspect it to see if it contains "COMMAND.COM" (which means<br /> it is a Windows 95 system) or "CMD.EXE" (which means it is a<br /> Windows NT system). Note that you may have to pre-process<br /> the path, adding double backslashes, before using it as part<br /> of a RUN statement.<br /><br /> Note: COMSPEC's value may be more than "C:\COMMAND.COM". For<br /> example, it may be "C:\COMMAND.COM /E:14350 or something like<br /> that, because the user needed to increase the size of the<br /> environment area . Similarly, the path to the command shell<br /> will vary depending on where Windows 95 (or Windows NT) was<br /> installed. Therefore, please be sure to look for "COMMAND.COM"<br /> or "CMD.EXE" in the string without relying on an exact match<br /> for the entire string.
Topic revision: r2 - 2016-04-06 - JeanNeron