![]() |
|
Published 1997-11-01 Printer-friendly version
I heard that you cannot compile Windows Help for Windows 3.1x under Windows 95. Is that true? My Clarion application is used on both 16-bit and 32-bit Windows platforms, what should I do to provide Windows Help with the program?
No, that is not true, but there is some basis for this misconception. Here are some factors you should know about.
You can compile either16-bit or 32-bit help under Windows 95. The type of help file created depends on which compiler you use. The 16-bit compilers (HC.EXE or HCP.EXE) create 16-bit help files. The 32-bit compiler(HCW.EXE) creates 32-bit help files. All of these compilers are made by Microsoft and are not freely distributable (although you can find them available for download in many places). They are licensed by most help authoring tools and buying one of these gives you the right to use the compiler that is licensed with the product. Some help authoring tools include both 16-bit and 32-bit compilers and let you choose the target.
There are 2 help engines a 16-bit engine (WINHELP.EXE) and a 32-bit engine (WINHLP32.EXE). The 32-bit engine can display 16-bit help files, but the 16-bit engine cannot display a 32-bit help file.
Windows 95 always uses the 32-bit engine; Windows 3.1x always uses the 16-bit engine. Windows NT behaves a little bit differently. NT has both engines and launches the appropriate help engine based on the application from which it is called. In other words, a 16-bit application will launch the 16-bit help engine under NT.
Therefore, if you have a 16-bit app and want your Help to work under NT, you must ship a 16-bit help file with it.
The Internet Developer's Kit comes with a single-user version of the Application Broker. I find this too limiting because I need to test for issues concerning multi-user access. Is there any way I can run more than one session of my application for testing purposes?
Yes! All you have to do is open more than one browser window.
The Internet Developer's Kit contains a single-connection Application Broker (CWBrokr1.EXE). It also contains a single-connection ISAPI version of the Application Broker.
The single-connection Application Broker functions exactly as the Application Broker, except that it only allows access by a single IP address at a time. That means one client can run more than one copy of an executable or run multiple executables by opening another browser window. To allow access to another user, all applications started by the first client must be closed.
A client must exit the application for the application to close; simply closing the browser does not close an application. If the user merely closes the browser, the application won't close until a timeout occurs. The templates set an application's timeout to 10 minutes by default. You can modify the amount of time in the Global Internet Application Extension Template.
You can easily test any concurrency issues (i.e., issues in your application concerning more than one user) with the single-connection Application Broker by starting two instances of your browser and running a copy of the application in each.
To start a new instance of your browser:
In Internet Explorer 3.0x:
Choose File » New Window.
In Internet Explorer 4.0x:
Choose File » New » Window.
In Netscape Navigator 3.0x:
Choose File » New Web Browser.
In Netscape Navigator 4.0x:
Choose File » New » Navigator Window.
I have an application that makes extensive use of values stored in an INI file. I use it to save each user's preferences and do field priming on insert to fill in some fields when the users adds a record. If I run the same application on the Web using Internet Connect all users share the same INI file which defeats my purpose. How can I save and retrieve settings for each user?
Relax. Have a cookie. No, I don't mean chocolate chip. I mean Internet Cookies. Use cookies when the application is running on the Web and INI files when running under Windows.
Cookies are a method for web servers to both store and retrieve information on the client side of the connection. This allows a server to store data on the client's machine and retrieve it later.
A server can send a piece of data to the client (browser) which the client stores locally. This is known as a cookie (the name has no known origin). Cookies contain a range of URLs for which it is valid. Later, when the client returns to a URL within that range, the server can query the cookie and use that data. A server cannot retrieve information from other servers (i.e., a server cannot query a cookie that is out of its domain range).
This mechanism is similar to the INI file storage and retrieval paradigm in Windows (GETINI and PUTINI), and provides a method for identifying user preferences and other data. For example, an application that requires a user to provide their name before entering can use a cookie to avoid the Login process after the first visit.
Note: Cookies are machine specific so a client who accesses a site from more than one machine will need to provide the cookie information once for each machine so a cookie is stored on the machine. In addition, cookies are browser specific, so a client who uses more than one browser, will need to set and get cookies for each browser.
Your web-enabled applications can use cookies to store user preferences such as the default city and state for new records. These settings can be retrieved the next time the user runs the application over the web.
To use cookies when the application is running on the Web and INI files when running under Windows, you would merely enclose the statements inside a conditional structure, such as an IF...THEN...ELSE structure.
Example:
IF WebServer.Active !Check if running over the web
LoginName = Broker.Http.GetCookie('LoginName') !get from cookie
ELSE
LoginName = GETINI('Preferences', 'LoginName') !get from INI file
END
Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.
Clarion Magazine ISSN 1718-9942
One year: $189
(includes all back issues since '99)
Renewals from $139
Two years: $289
Renewals from $239