You can think of ALPFrame as for a WEB browser combining ASP/CGI engine and an extended DHTML model in one. But don't forget it hosts Microsoft Internet Explorer and depends on it and its version. ALPFrame will run on Windows 98 and later and Windows NT4 and later with Internet Explorer 4.0 or later installed. Although tests show that it runs on the most Windows 95 installations we can not guarantee support for Windows 95. If you are going to build ALP applications that use the ALPFrame features - pay attention to the DHTML parts of your applications if you want maximum compatibility - rely on the IE4 features only if you want to run them on any of the supported platforms - ALPFrame features are independent of the IE version.

To evaluate ALPFrame download it - unpack the archive with the sub-tree in an empty directory and run ALPFrame.exe. Try it on a machine without ALP installed. Alternatively you may download the SFX archive version and just start it (but note it uses temporary folder and its contents will be lost after closing the application - choose it if you want a quick preview only). Package includes part of the standard ALP samples and a few VarioMenu samples showing usage of the extended DHTML model.

More about the ALPFrame

ALPFrame combines typical WEB server scripting techniques with DHTML and additional client side user interface features. It is an executable intended run ALP applications without installation (running from the CD for example). It is intended to allow you to mix server-side and client side scripting on the client machine without need to care about installations or core features availability. Having both ASP/CGI and DHTML on the client machine you are able to use the easiest way for any application you built. For example DB operations are easier to implement in ASP, but visual effects are bound to the client side (DHTML) - with ALPFrame (and ALP in it) you have both features on the end user machine and choice is up to you. With the window presence, window and context menus controlled by the page scripts you are able to add UI elements typical for the other Windows applications without "drawing" menus using DHTML divisions and tables. Last updates to the final version (24.September.2001) add some additional features like menu style control from the script, window behavior control and additional menu operations (such as tracking the menu selection).

What is ALPFrame?

It is an application that hosts Internet Explorer control and does some important steps while initializing. It uses configuration describing what components to load (acts instead of the system registry) and registers the ALP engine as a temporary namespace handler for the ALPFrame process. Ships with the VarioMenu components and adds to the DHTML pages ability to build, control and use the window and shortcut menus. As a result ALPFrame provides framework that combines ASP/CGI, DHTML and typical UI elements of Windows OS in a complete execution environment.

Details

Menus: With the VarioMenu component script in the page is able to create trees of menus and show, hide, modify them. The script can attach parts of these trees to the window (as a window menu) or use some parts for right hand menus for the items/parts of the DHTML page or diplay them on some other DHTML event (for example button click). Menu items are configured by the script to invoke a member of the page script and also support HTML frames. Menus include support for keyboard accelerators too.

Window control: ALPFrame incorporates a set of functions and objects accessible to the scripts in the WEB pages that allow them to control the:

• window style - caption/without caption, thin captions, system menu and other window elements
• window position - controlled through extended set of members using coordinates packed in objects (point and rectangle), Arithmetic with the coordinate objects and so on.
• window presence - pages are allowed to make it "top most", send it on bottom, hide show it, minimize, restore and maximize it.
• Print method independent of the IE version.

Some typical questions you will probably ask:

Why the menus are controlled by the DHTML scripts and not by the ASP scripts?
Providing as extension to the DHTML model - menu features are available to the both page scripts and server scripts (ASP/CGI). Server side script is able to generate the appropriate client script thus application is not required to use ASP pages if there is no need of server side programming in a particular part of it. Also server side scripts are not aware of the HTML frames and thus they can not control the menus in the right manner.

What can I do with the ALPFrame and it features?
You are able to build ASP/DHTML/CGI applications that:
- starts without need of installation
- presents to the user professional interface including standard window and context menus
- place it on any location and start it taking care only to copy your application - the directory with its sub-tree and all the alp.xxx configuration files in it.
- using frames makes possible to create very complex interface and menus will help you to make it more friendly.
- Controlling the window presence gives you ability to use techniques typically available only for the applications written in VC, VB and so on.

Why there are no toolbars (if the menus are present what about the toolbars)?
DHTML itself gives powerful designing capabilities and toolbars can be made without need of external components. But of course we are thinking about that - your opinion will be the reason to determine if there is a need of integrated toolbar support (controlled by the scripts) in the next ALPFrame versions. Also we plan to make possible to extend the ALPFrame with custom elements.

Is it applicable for the usual WEB applications?
ALPFrame is integrated with the ALP engine but this is not a limitation. Contrary - it allows distributing the application between local machine and the WEB server in an easiest way if you feel this will bring benefits to your application. Part of the server side code can be executed on the client machine and using the compatibility between ALP and the server side programming distribution process is just a selection what scripts to leave on the server and what to run locally at the user side. Your selection depends mostly on the requirements caused by the data available on the server and on the client machine. You can use it as a client side for any WEB application. You are able to add some useful UI elements to your application and update your clients by just providing a download link for the ALPFrame package prepared for them. Default starting page can be specified in it and other elements that will save administrative work.

Example?
One of the easiest ways is to make some forms to submit to the local ASP pages or to the WEB server. Suppose you have built an address catalog in ASP for example. You are able to pack the applicable part of the server application with ALPFrame and the user will have it running on his/her local machine. By allowing him/her to make requests to the server from the local application user will be able to browse your site. Making some of the server forms to submit to the local ASP pages will give the user ability to save records to the local application database.

Limitations

Unfortunately not all components can be loaded and used dynamically by the ASP-like and raw scripts. The problem is caused not by a bug but by the practice:

Most development tools produce automation compatible components using the ITypeInfo interface. They load the type info by checking the registry thus if the control is not registered type info load fails and the component is not capable of automation.

Components provided with ALP load their type info directly from their resources but if you are going to use some third party components without prior registration you may expect problems with many of them. ALP applications using the standard components that are available on the system and components provided with ALP will not have difficulties.

In the code snippets part of the site modified version of the CComTypeInfoHolder ATL class is provided in order to be used to correct your own components written in C++ and ATL. We have an idea to develop Dispatch wrapper ActiveX as freeware at later time. It will not be provided as a part of ALP but it will be helpful to solve many problems.

Visual components used in the HTML page can not be registered dynamically. Registration supported by COM on all the platforms, covers only one apartment thus ALP runs as free threaded application but UI part can not be made free threaded by design. In fact most of these components are signed and are easy to install thus the problem is not fatal, but may lead to need of installation. ALPFrame can be used as a part of another applications and thus can be installed among other parts of the application (just copying it) - in that situation the problem with the additional components can be resolved by installing them, but applications intended to run with minimum requirements should depend on the features tested with ALPFrame only (Developers of the software that runs from a CD should pay attention to find if their applications do not depend on the components not able to run without install or if there is no choice to make the CD-ROM installable).

What is the license?
ALPFrame does not require licensing, but ALP engine bundled with it requires under the same conditions defined for the ALP product. You are allowed to redistribute applications with the shareware version of the bundled ALP engine as long as the applications are freeware. Note that nag screens and footnotes will be displayed as long us you have no ALP license in your applications - don't forget to inform the users about that behavior. ALP supplies appropriate links thus you are not required to include ALP license agreement with the applications. ALP engine must not and can not be removed from the ALPFrame - if you are using only static pages you are able to avoid using it but the engine must remain as part of the package.