FAQ's

Older versions of the DOS shell allowed printer redirection of program output. For example:

sagerep test > prn
            

would send the output to the standard printer. Later version of the DOS shell supplied with windows do not support this. There are some commercial add-ons that can restore this functionality but the simplest thing to do is to make use of a power shell script.

For Sculptor 2 programmers still working with DOS who wish to continue using printer redirecton of sagerep output, the easiest thing to do is put the sagerep command in a Power Shell script and call Power Shell itself with the script as parameter from a DOS shell. It is not usually workable to dispense with a DOS shell altogether in favour of a Power Shell because the 'exec' command and command lines in menu files do not work. Sculptor attempts to call another DOS shell to execute commands.

The procedure then is:

1. Create a Power shell script, say test.ps1, and use the power shell printer redirect facility with optional command line parameters $args[]:

   # test.ps1 - send sagerep output to a named printer using three application level parameters
   sagerep test nullp $args[1] $args[2] $args[3] | out-printer -Name "HP14398D (HP DeskJet 2700 series)"
                   

   The -Name clause may be omitted if you want to use the default printer.
2. From an exec command in a Sculptor program call a power shell with test.ps1 as a parameter along with your own optional application parameters, eg:

   exec "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -File test.ps1 AAA BBB CCC"
                   

   This type of command executed by exec should also be used with menus.

With this example:

!temp x,,a3
!temp y,,a3

  x = ""
  y = "ABC"

  x = x + y
  prompt x

You need to use '/' not '+' The expression :

x = x /  y
prompt x

Add y onto x after the final trailing space. The expression x+y is three spaces followed by "DEF"

Sculptor allows only one instance of a key value, ie keys must be unique. However I have an example where the same key occurs twice. Eg assume I have a singe key field F1 and I scroll through the values of this field a few time I get:

F1 = "A"
F1 = "B"
F1 = "B"
F1 = "C"

In all cases where a data file looks strange, the first thing to do is run kfcheck on the file. If it is damaged then anything could happen and the index to the file must be rebuilt with kfri. If, however, the file is OK then the most likely reason for the problem is that F1 has some characters that do not display on a screen or a printer but are nevertheless present. An easy way to find them would be to send the output to a text file and then do a binary dump of the text file using, say, od on Linux or debug on DOS.

If a report is run with no parameters it is sent to a default window and Next and End options appear in the top line.

run report MyReport

But if the same report is run to a window nothing happened

run report Myreport to Window1

Output will go to the named window. In a report sent to a named window the output does go the window but there are not automatically created Next and End options. This is because you have full control of the named window and the system does not override any functionality put there by the programmer. If you require the Next and End options create buttons for them and attach event functions in the normal way.

If you are seeing nothing it may be because the program or window have been closed.

There is no difference. They are both shipped as binaries for the historic reason that srepw would only permit localhost or directly accessed data whereas srepwc allowed network connections in addition. The restriction of srepw as for licensing reasons. This restriction has now been lifted and srepw calls srepwc on entry.