Tech Notes

Building and Using Sheet Windows

It only takes a few lines to build a sheet window and a few lines to dispose of it. I'll cover that in just a second. The problem is that we do not freeze our computers while we are waiting for input. For example, if a sheet window over one document displays the "Save before closing?" dialog, there is no reason that other documents should not be useable. The same is true of anything that might be asked of a single document. In fact, there may be a dozen "Save before closing?" sheets visible at one time and you should technically be ready to service each of them independantly. I bet that makes your brain hurt!

Why don't we start with the simple steps required for building a sheet window. I will ignore sheet alerts. They're for whimps. Real mean don't drink wine coolers and they don't freeze up a program with alerts.

// create the window

appearance window -sheetWNum , , @r , _kSheetAlertWindowClass

// put button and fields in here

// now display the window
get window wNum , parentW
get window sheetWNum , sheetW
err  = fn ShowSheetWindow( sheetW, parentW ) // show dis sheet

At some point in time, Bubba Q. Citizen is going to get tired of this sheet and click a button. Here is how we push the flush lever:

dim as windowRef @ sheetW
dim as OSStatus    err
dim as long        sheetNum

sheetNum = window ( _outputWnd )
get window sheetNum , sheetW
err  = fn HideSheetWindow( sheetW )
window close sheetNum

Here's the $64 question: How did we know that Bubba clicked in a sheet window? And how did we know what window that sheet belonged to?

The answer is going to be a simple one: We set each sheet window to have an ID number equal to the window that it covered plus 50,000. We can deal with the dialog events by looking at the output window (which will be greater than 50,000). Or...

I have a slightly different style of programming. I enumerate my windows in increments of 1000. My first window is 1000, then 2000, etc. All controls and fields inside of those windows are numbered inside of the window's range (i.e. 1001 , 1002 , 1003...). I know if button number 4007 is clicked that it belongs to window number 4000. I know if button number 51003 is clicked, it belongs to button #3 in a sheet window that is over document number 1000. Know what I mean, Vern?

The enumeration is easy:

begin enum 1000, 1000
 _myfirstWindow
 _mySecondWindow
end enum

begin enum
 _okFirst = _myfirstWindow + 1
 _cancelFirst
 _entryField
 _promptField
end enum

_sheetWindowAdd = 50000

begin enum
 _sheetSave = _sheetWindowAdd + 1
 _sheetDontSave
 _SheetCancel
 _sheetOk
 _sheetDeletePage
end enum

The pieces are falling into place now. If we receive a dialog event, and it is a button click, we know (because of the button's ID) that it is in a sheet window. If you do not use this enumeration system, then you still know it is in the sheet window because of the number of the output window. It is higher than _sheetWindowAdd. Given this information, you can branch to your sheet window handler and prossible/probably close the sheet window.

I've built a complete project for your inspection. No matter what methodology you use, fancy enumeration, high numbered output windows, spagettie code... you can still work sheet windows into your application.

Click here to download the file.