🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.ms.programmer
Article #2371

Re: BC++, now what?

#2371
From: CADSI
Date: Tue, 30 Apr 1991 15:28
51 lines
3303 bytes
From article <1991Apr30.025653.5905@mnemosyne.cs.du.edu>, by ebergman@isis.cs.du.edu (Eric Bergman-Terrell):
> 
> Based on my own experience porting a hefty MS-DOS application to Windows
> 3.0 I'd say that Petzold will give you most of the information that you'll
> need.  The book has an uncanny ability to anticipate almost all the serious
> problems that one (at least this one!) is likely to encounter learning
> Windows software development.
> 
> I recently added volumes I & 2 of the MS press books (that come with the
> SDK) to my library - both seem to offer little extra basic information.
> However, later on when I'm in "polishing" mode I expect that they'll be
> more interesting.

I hereby add my ideas (i ported one very ugly, large, unwieldy, ...) program
from DOS to Windows.  My strategy (this assumes command line interface only,
a menu interface should be even easier).
	1) make the main Window into a Message type Window.  (The MS-SDK
	   has a stdio type window for the looking in the TTY example).
	2) Create a keyboard class (object, whatever) whose job is to
	   become the interface manager (this is probably already done
	   in the DOS version).
	3) All Commands should have a Menu pick somewhere.  This Menu
	   pick simply builds a string as it goes and when a Leaf of
	   a menu is obtained, the built command string is sent to
	   a Keyboard.docommand(str) type call.This will branch as necessary
	   to the correct operation.
	4) Make the Dialogs for any missing information in the Menus which
	   continue to build the command (DialogBoxParam is usefull here).
	5) Compile and run, heh, heh.

Anyway, this just amounts to a Windows wrapper around the real app.  I
have done this for the X11 interface of our (CADSI's code).  The design
simply sees the Menu as a wrapper which ALWAYS ands up sending commands
to the Keyboard object.  It works, and your product is out the door with
minor changes, albiet hefty additions (the Windows stuff).  If somebody
needs, I can mail a copy of my KeyboardCommand class for a look.  It
compiles in Windows and words.

So, at this time, you may be asking WHY Keyboard.  Note that this approach
allows the use of a Command Line interface - the Power Users dream.
IMHO, ALL programs should have the option of a Command Line Interface.
GUI's force you to wait on them, command lines don't.

BTW, the KeyboardClass code is both C and C++ if you wanna see how
to make your C++ classes work in C.  It ain't perfect, but its good.

|----------------------------------------------------------------------------|
|Tom Hite					|  The views expressed by me |
|Manager, Product development			|  are mine, not necessarily |
|CADSI (Computer Aided Design Software Inc.	|  the views of CADSI.       |
|----------------------------------------------------------------------------|
Technical Details
Message-ID: <1991Apr30.152839.30742@ccad.uiowa.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!ns-mx!ccad.uiowa.edu!cadsi
References: <1991Apr30.025653.5905@mnemosyne.cs.du.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!ns-mx!ccad.uiowa.edu!cadsi
From: cadsi@ccad.uiowa.edu (CADSI)
Newsgroups: comp.windows.ms.programmer
Subject: Re: BC++, now what?
Message-ID: <1991Apr30.152839.30742@ccad.uiowa.edu>
Date: 30 Apr 91 15:28:39 GMT
References: <1991Apr30.025653.5905@mnemosyne.cs.du.edu>
Organization: CAD-Research, U. of Iowa, Iowa City, Iowa
Lines: 51