![]() |
||
| Home | SwiftForth Archive | SwiftX Archive | |

I can't comment on the application template, but I would like to comment on
your avoidance of INCLUDEs. I highly recommend using INCLUDEs to load
functional modules within an application.
Until recently, I thought the same way as you about avoiding INCLUDEs. As
part of a review of my code, a Forth consultant, Gary Sprung, urged me to
look at some of Rick's code (there were INCLUDEs and CLASS definitions all
over the place). I wasn't immediately convinced, but afterwards I did try
to modularize things here and there (e.g., a module for password-protected
menu items instead of cut and paste several places in the app.).
I was surprised to find that I liked it. It did force me to think in terms
of functional code groupings so I often had to rework things to make them
callable from an application (e.g., specifying the password before including
the password module).
It wasn't a pleasant transition: much of my existing code had to be
reworked. However, this was very good! It forced me to factor my modules
and to also think about factoring out common tools with CLASS definitions.
So much so that I found myself "INCLUDING" modules within modules, something
that I hated from C (go figure).
I discovered that once something worked and was reliable, I didn't need to
clutter up the app. with the code details. This is somewhat like the
philosophy of crafting well-factored words that are tested and reliable. It
seems that I keep re-learning the same lessons.
I do agree that, at first, it was useful to have the code "all in front of
me." But, I highly recommend trying to modularize things as soon as you
understand the code and it is working reliably.
I used to "build" new apps by using templates (or previous apps) with
everything already coded that I might want to use (e.g., serial ports,
email, and DDE). The task was one of cutting out the code that wasn't
needed. Now I build apps up by including modules picked from several
working apps. Much better.
P.S. Sorry for the diatribe about "INCLUDEs as a transcendent experience."
-----Original Message-----
From: Richard Owlett [mailto:rowlett_at_atlascomm.net]
Sent: Saturday, September 29, 2001 6:07 AM
To: sftalk_at_forth.com
Subject: [sftalk] What to use for a template for developing a Windows
program
The SwiftForth distribution CD provides a least four
templates/foundations on which to build an application -- Win1.f,
Win2.f, Winapp.f, and Winmaker.f ( specifically the word GENERICWINDOW )
My primary question is how to chose among them.
A secondary question:
Is there any significant difference between Win1.f and Win2.f except
the inclusion of menus in the second. I assume the longer [SWITCH
APP-MESSAGES ... could have been used in Win1.f.
I'm developing the display portion of a slide show program [ A very
stripped down equivalent of MS PresentationManager etc. They are too big
and even then do not do what is wanted.] The final version will have to
be a standalone exe.
Rick VanNorman gave me a starting point [ attached below for reference ]
in reply to a related question. I have used it as starting point to
explore the Windows API. I now have a program with prototypes or stubs
of all the desired features. It grew like Topsy and although it runs (
or at least limps ;) it's time to clean it up.
A concern rises out of the requirement that when referring to
words/variables within
GENERICWINDOW SUBCLASS SLIDE-WINDOW
.
.
.
END CLASS
by FOO xxxx
and similarly within that referring to things defined outside require a
preceding ::
This seems "un-neat". I am wary of lack of "neatness". It usually means
I've overlooked something and have set myself up for a fall. I could
stuff just about everything into the class definition. That would have
some justification as once the data file is loaded to memory all
operator interaction can be processed by WM_KEYDOWN MESSAGE: xyz ; .
My inclination is to rewrite based on Win1.f. This is based on:
1. As a "newbie" I like all the program to be visible at once. I'm even
avoiding INCLUDE's for the same reason. This is essentially a
style/preference issue.
2. Win1.f has all the stubs etc. for making it standalone.
3. It would solve the "un-neat" problem.
Am I missing any "gotcha's"? [I can see advantages in a production
environment of the GENERICWINDOW approach. I'm not there yet.]
{ ====================================================================
slides.f
first, almost useless attempt at a slideshow
Copyright (C) 2001 FORTH, Inc. <br> Rick VanNorman rvn_at_forth.com
==================================================================== }
GENERICWINDOW SUBCLASS SLIDE-WINDOW
: MyClass_ClassName ( -- z ) Z" SlideView" ;
: MyWindow_WindowName ( -- z ) Z" SlideView" ;
1024 BUFFER: TEXT
VARIABLE X
VARIABLE Y
VARIABLE N
VARIABLE DC
: EMPLACE ( addr len x y -- )
Y ! X ! 1024 MIN 0 MAX DUP N ! TEXT SWAP CMOVE ;
: SHOW ( -- )
mHWND :: GetDC DC !
DC @ X @ Y @ TEXT N @ :: TextOut DROP
mHWND DC @ :: ReleaseDC DROP ;
: TYPE ( addr len x y -- ) EMPLACE SHOW ;
END-CLASS
SLIDE-WINDOW BUILDS FOO
: Z FOO CONSTRUCT ;
: SHOWING
S" THIS IS FIRST" 10 10 FOO TYPE 1000 MS
S" THIS IS SECOND" 30 30 FOO TYPE 1000 MS
S" THIS IS THIRD" 50 50 FOO TYPE 1000 MS ;
----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe sftalk" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/sftalk -- check them out!
Search the archives! Visit http://www.forth.com/search for details.
----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe sftalk" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/sftalk -- check them out!
Search the archives! Visit http://www.forth.com/search for details.
Received on Tue Oct 02 2001 - 13:47:15 PDT
This archive was generated by hypermail 2.2.0 : Sat Nov 22 2008 - 03:04:19 PST