Zeus Productions
Tech Alerts

These Tech Alerts are issued to keep you informed about possible issues with Zeus Products and their solutions.

zOpen Tech Alerts:

Alert #9 - Using zOpen, the application won't launch and the error code is "8".
Alert #8 - Using zOpen's zFindExe method does not find a file association.
Alert #7 - Using zOpen you encounter the error message "Can't find application to open document xxxxx".
Alert #5 - Using zOpen under Windows 95, if the user clicked repeatedly, it could hang the zOpenCover method.
Alert #4 - Using zOpen under Windows 3.1, zFindExe locates an executable, but the call to zOpenDoc fails.

zLaunch Tech Alerts:

Alert #12 - zLaunch for Macintosh - how do I eliminate or change the background cover screen?
Alert #11 - zLaunch for Windows fails using the INI file method to specify parameters.
Alert #10 - zLaunch for Windows crashes immediately when double-clicking its icon.
Alert #3 - Using zLaunch, the projector won't quit.
Alert #2 - Using the BACKGROUND=0 option with zLaunch for Windows under Windows 95, prevented the projector from restarting once the external application was finished.
Alert #1 - Using zLaunch for Windows under Windows 95, some applications create windows that disappear behind zLaunch's black cover window.

zWinVer Tech Alerts:

Alert #6 - Using zWinVer with a 16-bit projector under Windows NT, the Windows version is reported as "Windows, 3.10".

Alert #12 - How do I eliminate or change the background cover screen when using zLaunch for Macintosh?

There is an undocumented trick to removing the background when using zLaunch for Macintosh. The background is specified as a resource in zLaunch's resource fork. You can either remove it altogether, or change it to some custom tile pattern, using ResEdit. Be sure to make a backup copy of zLaunch first. If you are not familiar with ResEdit, contact Zeus Productions for more information.

Posted November 25, 1997

Alert #11 - zLaunch for Windows fails using the INI file method to specify parameters.

When using the INI file method, the INI file must be a valid Windows INI file, and its file name must with the ".INI" extension, such as "CONFIG.INI". The INI file must include an appropriate section heading in brackets, and refer to that section heading from your Lingo call to zLaunch. Failure to include a section heading in your INI file or refer to it properly in your call to zLaunch will cause zLaunch to crash. This is because it won't find any parameters, and it will fail without them.

Refer to the zLaunch documentation for details on using the INI file method.

Posted November 25, 1997

Alert #10 - zLaunch for Windows crashes immediately when double-clicking its icon.

You cannot just double-click zLaunch's icon, because it needs parameters. Without them, it will fail. Specify parameters using the parameterList method or INI file method. Refer to the documentation.

Posted November 25, 1997

Alert #9 - zOpen cannot launch an application, and the error code is "8".

An error "8" indicates that there is not sufficient memory to launch an application. This mis most likely to occur under Windows 3.1, and less likely to occur under Windows 95 which manages virtual memory somewhat better. zOpen requires that Director remain active. If there is not enough memory to launch another application simultaneously, you should use zLaunch instead. In either case, make sure you specify an appropriate minimum configuration and tell users to quit other running applications.

Posted November 7, 1997

Alert #8 - Using zOpen's zFindExe method does not find a file association.

Contrary to earlier documentation, when using the zFindExe method, you should always specify the period ".", as part of a file type. Failure to do so may cause zFindExe to not find the proper association, particularly under Windows NT. Such as:

	-- Right!
	set acrobatPath = zFindExe(".pdf") 

	-- Wrong
	set acrobatPath = zFindExe("pdf")

Posted September 4, 1997

Alert #7 - Using zOpen you encounter the error message "Can't find application to open document xxxxx".

Some applications only look for documents in the working directory. Even though the file path listed in the error message may appear correct, the application requires that you set the working directory to the folder containing the document. This may be a folder other than the one containing the application or the Projector. The working directory is specified as a parameter to several of zOpen's methods, including zOpenDoc, zPrintDoc, zOpenExe and zOpenCover. Failure to set this properly may prevent zOpen from properly opening your application and/or document.

Posted August 20, 1997

Alert #6 - Using zWinVer with a 16-bit projector under Windows NT, the Windows version is reported as "Windows, 3.10".

Windows NT will not run a 16-bit application, including 16-bit projectors. Windows 3.1 can be installed to run under Windows NT to handle 16-bit applications. This is called "Windows on Windows" (WOW). In this case, zWinVer is actually running under Windows 3.1, and it returns "Windows, 3.1" as the Windows version, even though Windows NT is also running on the same CPU. We are currently exploring possible solutions to indicate whether NT is running, even when a 16-bit projector is running using WOW. The easiest solution is to use a 32-bit projector under Windows NT, which will not require WOW in the first place.

Posted July 10, 1997

Alert #5 - Using zOpen under Windows 95, if the user clicked repeatedly, it could hang the zOpenCover method.

This has been fixed in the latest version of zOpen which is available from Zeus Productions to registered users. Contact Zeus for details.

Posted July 7, 1997

Alert #4 - Using zOpen under Windows 3.1, zFindExe locates an executable, but the call to zOpenDoc fails.

Under Windows 3.1, zOpenDoc only looks in the WIN.INI file, not the Registry file (even though zFindExe looks in both). Therefore, if an installer only writes information to the Registry file, and not the WIN.INI file (as some newer Microsoft software does) zFindExe will locate the application, but zOpenDoc will fail. Until a fix is available, you can use zFindExe to locate the executable, and pass the return value to zOpenExe to launch the application. This is not a problem under Windows 95, or under Windows 3.1 when an installer updates the WIN.INI file.

Posted July 7, 1997

Alert #3 - Using zLaunch, my projector won't quit.

There are a number of possible causes, but one possible cause was omitted from earlier documentation. Be sure to set the Projector option to "Animate in Background" when you build your projector. If you are not sure if you used that option when you built it, then rebuild your projector. Refer to the TechNote, "Creating Director Projectors for Mac and Windows."

Consult the documentation for details on other possible causes. Most notably:

You must use the Lingo quit command to quit your Windows projector after calling zLaunch for Windows. Consult the zLaunch for Windows documentation for details.
You must not use the Lingo quit command to quit your Macintosh projector after calling zLaunch for Macintosh. Use line 1 of launchdata.txt (the configuration file used to pass parameters to zLaunch for Macintosh) to specify the name of the Projector to quit. Consult the zLaunch for Macintosh documentation for details.

Posted June 26, 1997

Alert #2 - Using the BACKGROUND=0 option with zLaunch for Windows under Windows 95, prevented the projector from restarting once the external application was finished.

An updated version of zLaunch32 is included in the new download of zLaunch for Windows available in our Download Center . It remedies possible problems when using zLaunch without the background cover screen under Windows 95. This allows you to use the BACKGROUND=0 option properly, which did not work in some cases when it had trouble detecting that the external application had terminated.

Posted June 26, 1997

Alert #1 - Using zLaunch for Windows under Windows 95, some applications create windows that disappear behind zLaunch's black cover window.

It has been reported that some applications, especially installers, create secondary windows that are sometimes obscured by zLaunch's cover window. The problem only occurs when launching some external applications that don't manage their windows in the standard manner. These windows are not brought to the foreground as is expected under Windows 95. Thus, they can be obscured by other Windows, including zLaunch's cover window. The problem does not seem to occur under Windows 3.1, but sometimes occurs with older 16-bit applications run under Windows 95.

Possible solutions:

Obtain a version of the external application that is optimized for use under Windows 95 and properly manages its own window(s).
Use zLaunch's BACKGROUND=0 option. (See Issue #2 below). This eliminates the cover window, so it is less likely that something will obscure the external application's window(s).
Use the 16-bit version of zLaunch (zLaunch16) under Windows 95. Although it is not optimized for this purpose, it works better with some non-compliant external applications. An updated version of zLaunch16 is included in the new download of zLaunch for Windows available in our Download Center .