Introduction to FiveWin.pdf

(86 KB) Pobierz

An Introduction to FiveWin

By James Bott

Getting Started

Windows is a whole new world for Clipper programmers, but FiveWin eases the pain. Once you

get your feet wet you will be amazed how easy it is to create a Windows program using Clipper

and FiveWin. Here's an example of the proverbial "Hello World" program:

#include "fivewin.ch"

function main()

msgInfo("Hello World")

return nil

Hey, you can handle that!

FiveWin

FiveWin is a Clipper add-on product that allows creation of true Windows programs using the

familiar xBase syntax. FiveWin consists of some Windows API wrapper programs written in C,

lots of classes to define Windows behaviors, and a number of header files to allow the use of

xBase like syntax. Of course, you can still use most of the old Clipper syntax.

FiveWin insulates us from the Windows API with the C wrapper programs. FiveWin also contains

a complete OOP language which was used to write the classes. If you prefer, you can write your

code in the OOP syntax (similar to Classy) or you can use a very xBase-like syntax which is then

converted to the OOP syntax by the preprocessor.

define window oWnd

activate window oWnd

Is translated by the preprocessor to:

oWnd:=twindow():new(... )

oWnd:activate()

The xBase-like syntax makes it easy for Clipper programmers to get up to speed. The OOP

capability provides power and flexibility for the advanced programmer. You get the best of both

worlds.

In addition to FiveWin, you will also need a Windows capable linker (such as Blinker) and a

resource editor (such as Borland's Resource Workshop or Microsoft's AppStudio) in order to

create Windows programs. Many of you may already have such a linker, and resource editors

come with many other language compilers such as C so you may have one of those too.

And now for something completely different.

The Windows Way

The biggest problem that Clipper programmers have writing Windows applications is

understanding the

Windows way.

This means non-modal and event driven applications. In typical

Clipper applications, the programmer controlled the work-flow by presenting the user with a

menu, edit screen, etc. and requiring the user to finish it before anything else could be done (a

modal methodology). Windows applications are usually written mostly in a non-modal fashion

allowing the user to be in control by allowing them to jump from one thing to another without

finishing the first.

New FiveWin programmers typically spend a lot of time trying to figure out how to recreate DOS

methodology in Windows. Partially this is because of their old DOS mindset and partly its

because of pressure from users that are currently working with legacy DOS applications. They

want the Windows version to work just the same. In the long run this is not good for either the

user or the programmer. Users may want the Windows version like the DOS version at first, but

soon they are going to be unhappy with it. Sometimes the programmer has to just do what is best

in spite of user protests.

It is not possible to cover much Windows philosophy here. The user should get one of the many

books on the topic and read it thoroughly. A very good one is Charles Petzold's "Programming

Windows 3.1."

Resources

Resources are a new concept for DOS only programmers. Icons, bitmaps, dialog boxes, menus,

strings, etc., are all called "resources" and can all be stored in a single resource file in either a RC

or DLL format. They can then either be accessed from the resource file by the Windows

application (DLL's) or alternately, they can be compiled right into the EXE using a special

resource compiler (RC's).

Resources can be designed in a special resource editor or some can be designed in other editors

(such as Paintbrush) and then imported into the resource file by a resource editor. The resource

editor then saves them in the desired resource file format.

A resource editor does not come with FiveWin, you will have to purchase your own. Although,

theoretically, you could write Windows applications in FiveWin without one, don't try it! Borland

makes one called Resource Workshop which comes with all their C compilers. It is also available

directly from Borland as an individual product, but it costs more than their Turbo C++ compiler

and takes 4 weeks for delivery (they don't do rush). Microsoft also makes a resource editor called

AppStudio which is included with some of their compilers. Get one.

Note that you will usually see the resource compiler referred to as RC.EXE but the Borland

compiler is named BRC.EXE. If you have the Borland compiler, the FiveWin BUILD.BAT file will

have to be modified since it calls RC.EXE. When you compile a program using the BUILD.BAT

program (and assuming the PRG and RC files have the same name) the resource compiler will

be called automatically and thus your resources will be placed in the EXE.

If you want to place your resources into a DLL you'll need to start with an empty DLL. FiveWin

provides one called \DLL\SCREENS.DLL. Just make a copy of this file with a new name and load

it into the resource editor and import all the resources into it. Then call it from your program using

SET RESOURCES TO "myapp.dll".

If you use any of Borland's special resource types you will have to load Borland's BWCC.DLL

also. If you don't, you will get some generic errors like "Can't load dialog box" that will leave you

clueless.

To load the Borland library, in your code, near the top of your main function issue:

Local hBorland := LoadLibrary("BWCC.DLL")

And just before the return statement in your main function call:

FreeLibrary(hBorland)

Windows

We will use

Windows

in proper case to describe the Windows operating system and

windows

lower case to describe a generic window. Windows themselves come in several types. There is a

SDI window, a MDI window, a MDI child window, and a dialog window (also called dialog box or

just dialog).

The SDI (single document interface) window is just, well, a window. When it is iconized it is

placed on the desktop. The Windows Write program is an SDI application.

The MDI (multiple document interface) consists of a parent window which contains MDI child

windows. MDI child windows always remain within the boundries of the MDI parent window, even

when iconized. MDI child windows are non-modal.

The Windows 3.1 Program Manger consists of a MDI parent window with each program group contained in a MDI child

window. Most word processor's are also MDI applications.

A dialog window contains some type of dialog with the user. Dialogs are usually modal although

some are non-modal such as a Find dialog in an editor.

Shell Window

Every application has a main or shell window. This is usually a MDI window but could be a SDI

window and is sometimes a dialog window if it is a small single-purpose application.

Here's how to define a MDI shell window:

define window oWnd title "MDI Shell" MDI

activate window oWnd

Here's a SDI window:

define window oWnd title "SDI Shell"

activate window oWnd

Or, a dialog:

define dialog oDlg title "Dialog Shell"

activate dialog oDlg

Colors

FiveWin windows default to the colors black on dark gray. You can change the window colors by

adding a

COLOR

clause to the window definition:

define window oWnd colors "N/W"

Or, you can use manifest constants (see \INCLUDE\COLORS.CH). You may find them easier to

read.

define window oWnd colors CLR_BLACK, CLR_LIGHTGRAY

[Note: Remember that manifest constants must be all uppercase.]

However, you'll probably want to use the standard default Windows colors as defined by the

Control Panel. These colors are stored in the WIN.INI file in the COLORS section. Here is a

function to retrieve these colors:

function iniColor(cID)

local cSetting,nLoc1,nLoc2,nRed,nBlue,nGreen

cSetting:=alltrim(getProfString("colors",cID))

nLoc1:=at(" ",cSetting)

nLoc2:=rat(" ",cSetting)

nRed:=val(left(cSetting,nLoc1))

nGreen:=val(substr(cSetting,nLoc1+1,nLoc2-nLoc1))

nBlue:=val(right(cSetting,len(cSetting)-nLoc2))

return ( nRed + (nGreen * 256) +(nBlue * 65536) )

There are some colors sets you will find useful:

...colors iniColor("windowText"), iniColor("appWorkSpace") // shell window colors

...colors iniColor("windowText"), iniColor("window") // child window colors

...colors iniColor("graytext"), iniColor("window") // disabled text

If you use these ini colors, users can change to whatever colors they like using the Control Panel.

To get a better understanding of how this works, run the Windows 3.11 File Manager and change

the colors using the Control Panel. The colors will be updated in the File Manager when you save

them in the Control Panel. Note that, unlike the File Manager, FiveWin applications' colors will not

be updated until the program is run again. But, this should not be a problem.

Icons

You will need to assign an icon to the shell window. You can assign an icon as a file:

define icon oIcon file "..\icons\myapp.ico"

define window oWnd title "Shell" icon oIcon

Or, use an icon as a resource:

set resources to "myapp.dll"

define icon oIcon resource "myapp"

define window oWnd title "Shell" icon oIcon

However, if you place this icon in a DLL it will not be visible to the Program Manager nor will it

appear when the application is iconized on the desktop. It is best to place the shell window icon

into a RC file using a resource editor, and then compile this icon into your application. Note that

you can compile some resources and still call others from DLL's in the same application. When

you refer to resources that have been compiled into the application there is no need to do a SET

RESOURCES TO command, so all you need is:

define icon oIcon resource "myapp"

define window oWnd title "Shell" icon oIcon

If you are using multiple DLL's, then you need to specify them all early in your program.

set resources to "myapp.dll", "misc.dll" // at beginning of program

Then before you call the desired resource, you must ensure that it's resource file is active.

set resources to "myapp.dll"

redefine ...

This syntax is somewhat like opening index files and then selecting the one to be active.

Brushes

Brushes are used to fill the background of a window. They can provide texture and/or color to an

otherwise dull boring background. But be careful, you can get too carried away and make the

background so "busy" that you get tired of looking at it. Also, be aware that brushes eat Windows

memory resources. The BORLAND style is popular for the shell window:

define brush oBrush style BORLAND

define window oWnd brush oBrush

Here is an example of gray diagonal lines on a white background:

define brush oBrush style diagonal color CLR_LIGHTGRAY

You could define just a color brush, but it seems to be no different than using the

COLOR

clause

for the window definition.

define brush oBrush color CLR_YELLOW

define window oWnd brush oBrush

Gives the same result as:

define window oWnd color CLR_BLACK,CLR_YELLOW

You can also use bitmaps, see BRUSH?.BMP and BRICK?.BMP. Play with all these options to

see what you like. Personally, I find all but the BORLAND style a bit too busy.

Menus

The topic of menus can get complicated. We'll just cover the basics here. So far we have used

the DEFINE command to create windows, icons, and brushes. Menus are created differently. One

would think we would:

define menu oMenu

But since menus require complex multiline definitions, the syntax for menus is:

menu oMenu

...

endmenu

Since we cannot define a menu in one line like brushes and icons, we have to encapsulate the

menu definition in a function which returns a menu object.

static function buildMenu()

local oMenu

menu oMenu

...

endmenu

return oMenu

Then we attach the menu to the window in the window definition statement just like icons and

brushes:

define window oWnd menu buildMenu()

Menus can also be created using a resource editor, then

DEFINEd

in FiveWin:

define menu oMenu resource "mainmenu"

Sure, now we use the

DEFINE

clause with menu.

You will rarely see a Windows application that uses multiple level cascading menus as is

common in DOS applications. This is due to the current popular belief that most users have a

hard time grasping multilevel concepts. Windows provides the dialog box containing such controls

as radio-buttons, listboxes, comboboxes, and checkboxes to handle collecting complex

information from the user. This allows us to collect the information we need in just two levels--one

pulldown menu and one dialog box.

Message Bars

If you want a status line on bottom of your window, you define a message bar. There are two

ways you can do this. You can use the Clipper syntax with a minor variation to attach it to a

window:

set message of oWnd to "Default message goes here."

Or you can use the FiveWin syntax:

define message oMsgBar of oWnd prompt "Default message goes here."

This default message will appear whenever other messages are not showing. Messages defined

for menu choices will be displayed on the message bar when the menu choice is highlighted.

Buttonbar messages also appear here. Just define the message as an empty string, "", if you

don't want a default message.

There are also some great clauses;

KEYBOARD, DATE,

and

TIME.

set message of oWnd to "FiveWin demo" keyboard date time

This message bar shows the keyboard status of numlock, capslock and insert keys, and the date

and time, all in recessed boxes on the right side. Slick and simple!

Toolbars (Buttonbars)

Toolbars, or buttonbars as they are called in FiveWin, are defined in the conventional manner:

Introduction to FiveWin.pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: