So, it's time for your first event. You don't need to worry about what you'll wear, but you should consider a few "do's" and "don'ts".

"Do's"
I'm a big fan of major league baseball. One of the benefits of actually going to a game, as opposed to watching it on TV, is that you can see the defense adjust after every event. There are many events in baseball that can move a defense. Certainly, if the ball is put into play, you'll see a defensive reaction. But I'm talking about the "lesser" events such as an out, the position of a base runner, a run scored, a new batter, or even a change in the count of balls and strikes. Any of these events warrants a defensive re-evaluation.

It's kind of the same thing in your Windows app. Whenever you get an event, you need to look around and decide if what just happened changes what events you should allow to follow. Remember, one of the tricks to thinking like a Windows app is to present to the user only choices that make sense.

Here's an example from ViewMgr. This is a piece of the Print Field Selector tab:

Notice that when a field on the "Select from" list is highlighted that only the "Add" button is enabled. Now look how this changes if the highlight is moved to the "Selected" list:

Now the "Add" button is disabled, the "Remove" button is enabled, the "Up" button is enabled, but the "Down" button remains disabled. If a field other than the last one in the list had been selected, the "Down" button would have been enabled too.

The IB code to change the state of a button is easy. Here's the code to disable the "Add" button:

cosCltId = IDC.FIELDADD       ! The control id of the "Add" button
cosState = cosEW.DISABLE   !The new state for the button (vs. cosEW.ENABLE)
gosub COS.EnableDlgItem      !The API call to make the change

There may also be times when you'll want to disable the entire app to give yourself time to do some processing without being interrupted by user events. In this case you want to change the state of the window, not just a single control. If you're going to do this, I suggest you turn on the wait cursor (you know, the hourglass) so the user has a visual clue that they're supposed to stand by. Again, this is an easy thing to do. Here's the code:

print (BeginWaitCursor)          ! Displays the hourglass
cosCWnd$ = cosDlghDlg$       ! The handle of the view window
cosState = cosEW.DISABLE    !The new state for the window (vs. cosEW.ENABLE)
gosub COS.EnableWindow      !The API call to make the change

Then, when you're ready to receive events again, you need to re-enable the window and turn off the wait cursor:

cosCWnd$ = cosDlghDlg$
cosState = cosEW.ENABLE
gosub COS.EnableWindow
print (EndWaitCursor)

That's all there is to it! These are easy ways to make your programs smarter.

"Don'ts"
If you write a dialog app, one thing you probably won't want to do is an INPUT. INPUT is a QCRT command. It only works on the Comet window, not your dialog. So, unless your dialog is a modeless, popup dialog, you won't be able to get to the Comet window. If you can't get to it, you can't INPUT from it. Your program will hang!

Another thing you really shouldn't do from inside your Windows app is a RUN unless you've either destroyed your dialog or deleted all your free-form controls first. These things take up resources in COSW and it's just good housekeeping to cleanup after yourself before you leave. Violating this rule of etiquette is more forgiving than doing an INPUT from your dialog. When you finally get back to either QMONITOR or QENDITOR, Comet will cleanup after you, but it's just bad manners not to do it yourself.