Windows S/W Development

Tim Cutts tjrc1 at mole.bio.cam.ac.uk
Fri Feb 17 04:07:47 EST 1995

johnk at spasm.niddk.nih.gov (John Kuszewski) writes:

>In article <3i0mduINNmi8 at s850.mwc.edu>, sgough at s850.mwc.edu (stephen gough) writes:
>|> I would like to develop an interface for laboratory exercise data,
>|> images from lecture, etc. on our in-house system.  I want to go with
>|> Windows, and obviously use some kind of object-oriented development pkg.
>|> Unfortunately, the last time I programmed I used 'C' (w/ curses routines
>|> to create rudimentary graphics) so I am ignorant on the newer
>|> methodologies.  Can someone point me to an appropriate piece of software
>|> to use for this purpose (pref. one that is readily mastered) and perhaps
>|> book(s) to use to come up to speed?  Any other pointers would also be
>|> greatly appreciated.  If one is fairly good at conventional programming
>|> is it difficult to make the leap to the newer systems?  (Time, as
>|> always, is of the essence.)

>If time is of the essence, forget trying to switch to the 
>object-oriented paradigm.  It takes quite a bit of rethinking
>and a lot of time to become familiar with the class libraries
>that are usually shipped with Smalltalk or C++ compilers.

>If time is of the essence, use Visual Basic instead.

For quick-and-dirty jobs, Visual Basic is indeed probably your best
bet, though if you want to develop serious programs under Windows, you
ought to use C++ or Pascal, preferably the former (although Borland
Pascal for Windows is quite capable of developing major Windows

You don't have to use C++ to write Windows programs, you can use plain
C, but that's not quite as easy, though you end up with faster, more
compact programs.  There is a very good tutorial on doing it in
Microsoft's "Windows 3.1 Guide to Programming".  It covers all the
basics; Menus, dialogs, modeless dialogs, printing and dynamic link

Together with the documentation for whichever compiler you choose,
I've found it contains pretty well all the information I needed.

When going to an interface like Windows, your entire method of
programming has to change though, which can take some getting used to.
DOS programs are usually very sequential, with a chain of events from
beginning to end.  Windows programs are not.  They are completely
event-oriented; the sequence of events is under the user's control,
not yours (obviously).  The way this works is actually fairly simple:

For each window or dialog you create, you give Windows the address of
a function to associate with the window (this is really object
orientation, but you can write it in plain C without having to learn
anything new).

This function basically is a large switch { } statement.  Every time
something happens to the window, Windows calls the function with
parameters telling you what's happened, or is about to happen.  Then
you can call a function of your own to deal with it.  These calls are
called 'messages' and are the basic way all GUIs work.  For example,
here is a function for a simple dialog box (Borland C++):

int FAR PASCAL _export AboutProc(HWND Dlg,
				 UINT Msg,
				 WPARAM wParam,
				 LPARAM lParam)
  switch (Msg) {
    case WM_COMMAND: {
      /* Great, a button, menu or control was used.  Which one was it? */
      switch (wParam) {
        case ID_OK: {
          /* User pressed OK button! */
          /* Perform any OK processing here */
          EndDialog(Dlg, ID_OK);
        case ID_CANCEL: {
          EndDialog(Dlg, ID_CANCEL);
    case WM_INITDIALOG: {
      /* Dialog is about to be created, so fill any controls here */
  /* If we haven't handled it, do Windows default processing */
  return(DefDialogProc(Dlg, Msg, wParam, lParam));

It may look hideously complex, but is actually pretty simple.  All the
C++ classes most compilers have do is to package this up into a C++

You just create one of these functions for every window.  All the rest
of your code can be pefectly ordinary C as in a DOS program.

See?  Not *that* bad, really...


More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net