 |
Documentation
Latest release
ZapRedraw Contact Download |
 |
 |
 |
|
This website is no longer maintained. Source is now available on Github.
This FAQ covers common issues raised by the current version of Zap only - it is not intended to be a general Zap FAQ. Answers to many of the frequently asked questions about Zap are addressed in the relevant !Help files. This document does not attempt to address questions such as "Can I get a program like Zap for other operating-systems?" either.
It normally resides at http://zap.tartarus.org/documentation/faq and it is included in the main distribution as !Zap.Docs.FAQ.
http://zap.tartarus.org/ is the main Zap web site. http://zap.tartarus.org/downloads/ is Zap's download site.
If you tick Options.Misc.Be Tolerant in Zap's icon bar menu then it will work. This is necessary because Fresco supports a slightly unorthodox variant of the OLE protocol.
They're as unobtrusive warnings as is possible. It is felt that some kind of warning is necessary otherwise programmers might not notice that their programs have problems which will cause them to fail to work properly with some existing OLE clients.
It should do, but you have to make sure that you save files in the same spot that ArcWeb told Zap to load them from. If you save them elsewhere, Zap dutifully informs ArcWeb of this, but it doesn't appear to become aware that the file has moved.
When Zap gets booted by the filer it no longer claims shift-double-clicks on files, text files, task windows, OLE, or 'external edits', if these have been claimed by another application.
The simplest solution to the problem of Edit loading is simply not to boot Edit in the first place. Unfortunately, on machines with Edit in ROM, this may not be a simple process.
As a consequence of this difficulty in uninstalling Edit, an 'Obey' file is provided which 'unboots' any other editors which the filer has seen.
There is a call to this file at the top of ZapUser:Config.!ZapBoot. It is commented out by default.
Some applications have been known to start up the resident text editor manually and the method used does not always work with this version of Zap. Sometimes contacting the author of the application can resolve such matters.
There are no known problems with ZapRedraw; however, since v1.40 of Zap, bitmap fonts have lived in the !ZapFonts resource application rather than within the !Zap application itself, and older programs may not recognise this change. It has been in place for a while now, so recent programs should be fine.
There appear to have been some problems with people using multiple copies of ZapFonts on their system - sometimes the one which gets booted first does not contain all the expected fonts. ZapFonts is intended to be a central resource and it is best to ensure that you maintain a central copy of it; $.!Boot.Resources is a good place to put it.
In the ZapUser:Config directory. All files which might need to be edited are now stored there. The idea is that you keep your copy of !ZapUser, and upgrade Zap simply by using in the new !Zap application instead of the old one (and probably upgrading !ZapFonts at the same time).
Currently, it is not possible to configure the fonts that Zap uses from the iconbar menu. If you wish to configure the fonts, you should change the relevant variables in ZapUser:Config.Settings. For more information, please see the relevant section in the manual.
If you were previously using v1.40 of Zap, you can keep on using your !ZapUser configuration. Note, however, that you won't get all the benefit of the latest version unless you upgrade your configuration at the same time as Zap; see here
If you are upgrading from version v1.35 or earlier, you will need to use the copy of !ZapUser supplied with the new version of Zap, and merge your old configuration with it. See here for more information on how to do this. Note also that information about extensions does not need to be added by hand any more; and also, that extensions from v1.35 almost certainly won't work with v1.45. (However there are no extensions we know of that do not have recent versions that will work with v1.45.)
From v1.40 onwards, all configuration lives in ZapUser:Config. In general, most of these files do not change from version to version, and so you don't need to worry about updating them. For v1.40 to v1.45, the following changes need to be made:
!ZapBoot has changed substantially; it is suggested that you copy the new version over and make any changed you need. In practice, you are unlikely to have changed anything, except perhaps the file type claims (lines such as ZapRunType FFF).
!ZapRun has changed substantially to support internationalisation; it is suggested that you copy the new version over and make any changes you need. In practice, the only parts you are likely to have changed are the templates set, and perhaps the file type claims. Note that some template sets haven't been updated for v1.45, and so aren't supplied any more (and see here). In addition, note that the old system variables Zap$HelpPath_<mode> are no longer required.
!ZapBooted has been added to complete the Zap boot sequence.
Country has been added to support internationalisation; it can be used to override your system country. You should copy this file over, and edit it if you need to set your country explicitly.
Settings has had two variables added. &322 can be used to specify a command to execute on startup, and &323 specifies the default mode. See the manual for more information.
A directory TMFs has been added. You should copy this across. TMFs are files that set per-mode variables, used to make some commands and operations more configurable. See the manual for more information.
The Keys file has changed significantly; firstly, the method of specifying alternate keymaps has changed from using &400 variables in a block, to using &800 variables immediately before the keymap in question, to declare them. Secondly, support for country-specific Keys files has been added; instead of a single file, you should have a directory, ZapUser:Config.Keys, containing a file for each country (eg: ZapUser:Config.Keys.UK, ZapUser:Config.Keys.France).
Unless you made significant alterations to your keys file, we suggest that you copy in the new keys directory and make any changes you need. Alternatively, move your current ZapUser:Config.Keys to ZapUser:Config.Keys.UK (or another country name, as appropriate), and edit it to use the new file format.
See the manual for more information about internationalisation, and about the new Keys file format.
Two files, FileIdHigh and FileIdLow, have been added to support auto-detection of file types based on theirs contents.
The Menus file has also become internationalised, in the same way. In addition, we now generate menus files from a source format which allows you to name menus instead of referring to them by number. Further, areas of the source file can be made optional - the idea is that more or less everyone can use the same source file, while still being able to configure things a fair amount. We strongly suggest that, if you don't like the new default menus, you copy the new menus directory, look at, and possibly edit, the appropriate source file (they are supplied in the directory ZapUser:Config.Menus.Source), and generate your menus file from that.
See the manual for more information about internationalisation, and about the new Menus source format, and the method for generating the final file from source.
Up to version 1.35, configuration of Zap lived in three files: !Zap.!Config, !Zap.Menus, and !Zap.Keys. Since then, all configuration has lived inside a new application directory, !ZapUser. We strongly advise that you try the new configuration as it stands, simply copying !Zap.!Config to ZapUser:Config.!Config, to preserve editing and display configuration.
(Note that if you do this, however, many of Zap's newer features will not be enabled - you would be advised to spend some time looking through the menus and playing with the new options, or to browse either the Changes file, supplied as ZapResources:Docs.Changes, or the entire manual, to get an idea of what Zap is now capable of.)
If you choose to copy your configuration across, you will need to install the !ZapUser application directory that comes with the new version of Zap, and then copy individual files. Note, however, that the old Keys file has been split into several different files: Keys, Settings, TypesHigh and TypesLow; and that many things have changed - in particular, many path checks (&500 variables) and filetype checks (&1xxx variables) no longer live in the user configuration, but are stored with the extension that they use.
Upgrading configuration by hand from v1.35 or earlier to v1.45 is a long and difficult process. It is far easier to take a fresh v1.45 configuration and adapt that to your needs.
Note also that brackets in key definitions are treated slightly differently from Zap 1.35 - they no longer act as comments.
Because it's not universally popular. Loading it automatically is an option available from the Options.Misc.Autoload menu.
There's no SoftWrap mode any more because soft-wrap is now a wrap option for most modes. As Text mode can now perform soft-wrap, there's no longer any need for a separate SoftWrap mode.
If it is a extension from v1.40, then it should be available in a version for v1.45 (although most v1.40 extensions will work with v1.45 anyway). Older extensions probably won't work.
Zap must wait until it is told about the keypress before it can attempt to distinguish between various different key combinations which produce the same character codes, eg. Ctrl-A and Shift-Ctrl-A, Return and Shift-Return, Ctrl-H and Backspace.
If an application decides that it needs to single-task for even a few seconds, it may happen that you release the keys fractionally too early (Zap thinks that they're not being pressed) or that you press another key before Zap has processed the previous one.
(It's worth mentioning that Zap doesn't check for ambiguities where there can be none, eg. when it's told that you've pressed a function key.)
The problems can be fixed, for Zap at least, by using the DeepKeys module, which logs Shift, Ctrl and Alt keypresses and also the key to which they apply. If you have problems with this module, we'd like to hear about them :-)
Before Zap started using DeepKeys, it used another module named KeyboardExtend; this provided much the same functionality but would suffer from synchronisation problems (applications which do not correctly process the key up/down event, upon which KeyboardExtend relies, do not help here...). To fix any such problems, simply issue *RMReinit KeyboardExtend. (The problem apps need to have a more recent claim on EventV in order to be able to cause this problem, which is why that *command fixes the problem; it forces KeyboardExtend to have the more recent claim.)
Known problem applications and modules:
| Module: | 386Support 1.90 (14 Sep 1995) |
| Location: | !PC.DivaRM |
| Fix: | Load into Zap, goto address &3E4 (LDMFD R13!,{R0-R4,R14,PC}^), press Return, delete the ,R14, press Return, then save.Other versions may be similarly affected. |
For some reason, the UniversalKey module is active. Disable it with *UKeyboard_Off. (This module is only meant to be active when an application which uses it has the input focus.)
You can't. Perhaps one day...
The changes since the version 1.40 release are covered in the ZapResources:Docs.Changes file.
Yes and no. Version 1.45 and older versions aren't; version 1.46 is.
A7000+s (and possibly some other computers), appear to have corrupt versions of some of the ROM fonts, notably Homerton.Medium.Oblique. Viewing this can cause the desktop font to be reset to the system font.
The template set 'OldStyle' uses some of these, and previously was the default template set for Zap. The default set does not have these problems.
|
© Copyright Zap Developers 1992-2008. All rights reserved. Updated: 2004/10/27 11:35:41. [email protected] |
 |