Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : TN9011.ZIP
Filename : ENVPRES.TXT

 
Output of file : ENVPRES.TXT contained in archive : TN9011.ZIP
This article is reprinted from the November 1990 edition of
TechNotes/dBASE IV. Due to the limitations of this media, certain
graphic elements such as screen shots, illustrations and some tables
have been omitted. Where possible, reference to such items has been
deleted. As a result, continuity may be compromised.

TechNotes is a monthly publication from the Ashton-Tate Software
Support Center. For subscription information, call 800-545-9364.

Environmental Preservation
Tom Woodward

We all remember the golden rule of camping : leave the campsite in
the same condition as you found it. Well, programming isn't any
different.

If you're a programmer, and you're writing a turn-key application for
someone which will be the only thing they do in dBASE IV, there's no
burning need to worry about dBASE environment settings previous to you
entering the program. You set what you want and leave it that way
when you're finished. Who's going to know the difference? However,
what if you're writing a little utility that's going to automate some
tasks in the middle of a user's process, and needs to modify the
environment? What if you're writing a generic subroutine that needs
to modify the environment which is to be called by a variety of
different applications? You are going to need to save the environment
as it was upon entry, and restore that same environment on exit. This
article explains how, with dBASE IV version 1.1, to do just that.

With dBASE IV 1.0 we had the SET() function to help us with the
problem of resetting the environment. If you set a variable equal to
the SET() Function, using the SET command in quotes as the argument,
it stored the value of the current setting for that command in the
variable. For example:

old_Safety = SET("SAFETY")

would save the current setting of SAFETY to the variable old_Safety.
To restore that old setting,

SET SAFETY TO &Old_Safety

would return it to its original state.

One problem we had was that 1.0 only permitted us the ability to save
SET commands which could be SET ON or SET OFF. Any complicated
settings were very difficult to attain inside a program. Now, with
advent of version 1.1, we now have an extended SET() functionality
which can return the value of FILTER, FORMAT, VIEW, even RELATION;
virtually any SET command. However, even version 1.1 has a couple of
limitations, and these and their workarounds, are what this article
addresses.

The first limitation of the new SET() functionality is saving color
settings. Now, there is the "ATTRIBUTE" argument which can be used,
however, it doesn't work in the same way as the others. If, at the
dot prompt, you type in:

? SET("ATTRIBUTE")

it will return something along the lines of:

W+/B,RG+/GB,N/N && W/N,W/B,RG+/GB,B/W,N/GB

If your colors differ from the dBASE defaults, it will vary somewhat.
The breakdown is:

NORMAL,HIGHLIGHT,PERIMETER && MESSAGES,TITLES,BOX,INFORMATION,FIELDS

Storing the setting to a variable remains the same process:

Old_Color = SET("ATTRIBUTE")

If you're using the dBASE III PLUS method of setting colors (SET COLOR
TO

, , ), the method of restoring also
stays the same:

SET COLOR TO &Old_Color

This works because dBASE IV will treat anything after the "&&" portion
of the string returned from SET("ATTRIBUTE") as a comment, so all the
dBASE IV color settings are ignored. But what if you are using the
dBASE IV method of setting colors? How do you save and restore your
old color settings? Well, you could spend hours of programming time
writing a routine to parse the string output from SET("ATTRIBUTE") or
you can insert a UDF into your code that returns the foreground and
background color of the color attribute passed to it. Such a UDF is
ColorChk() found on page 8. The color attribute can be passed as a
string with all or any subset of its name (even just the first
letter). For Example, any of the following usages are valid:

Old_Norml = ColorChk("NORMAL")
Old_HiLt = ColorChk("High")
Old_Box = ColorChk("B")
Old_Mssg = ColorChk("m")

Now that we have hurdled one of the barriers preventing us from total
restoration of the environment, we need to workaround the next. And
the next problem, the setting of DATE, isn't addressed at all with the
SET() function, so we're going to have to improvise. The
functionDateChk() has no parameters, and sets CENTURY ON during the
UDF execution, returning it to its original state at the end of the
function. Its usage is as follows:

Old_Date = DateChk()

Notice that while date display formats which duplicate other display
formats (AMERICAN for MDY, FRENCH or BRITISH for DMY, and JAPAN for
YMD) are not addressed in the function, the multiple format names
serve no other purpose than to make the name comfortable for the
person selecting it (especially the French and British who would
probably complain heatedly if either were forced to use the other's
nationality as there own date format name). Because there is no way
of checking your date format setting (that's why we created the
function!), no one will be the wiser as to us changing from, say,
AMERICAN to MDY.

Now that we've filled the small environment preservation void left by
dBASE IV version 1.1, we can completely save and restore our settings,
and our programs will be ecologically approved by GreenPeace, the
Sierra Club, the EPA, and the likes.

FUNCTION: ColorChk
FUNCTION ColorChk
PARAMETER WhichCol
SET CONSOLE OFF
lc_talk = SET("TALK")
SET TALK OFF
SET CONSOLE ON
WhichCol=UPPER(LEFT(WhichCol,1))

IF WhichCol $ "M,T,B,I,F"
Col_Attr = SUBSTR(SET("ATTRIBUTE"), AT("&",
SET("ATTRIBUTE")) + 2)
ELSE
Col_Attr = LEFT(SET("ATTRIBUTE"), AT("&",
SET("ATTRIBUTE")) - 2)
ENDIF

DO CASE
CASE WhichCol = "F"
Stop_At = 4
CASE WhichCol = "I"
Stop_At = 3
CASE WhichCol $ "B,P"
Stop_At = 2
CASE WhichCol $ "T,H"
Stop_At = 1
OTHERWISE
Stop_At = 0
ENDCASE

Counter = 1
DO WHILE Counter <= Stop_At
Col_Attr = SUBSTR(Col_Attr, AT(",", Col_Attr) + 1)
Counter = Counter + 1
ENDDO
SET TALK &lc_talk
RETURN IIF("," $ Col_Attr, LEFT(Col_Attr, AT(",", Col_Attr) - 1),
Col_Attr)

FUNCTION: DateChk
* Function....: DateChk.Prg
* Author......: Tom Woodward
* Version.....: dBASE IV 1.1
* Notes.......: This Function Returns the Current Date Format

FUNCTION DateChk

SET CONSOLE OFF
lc_talk = SET("TALK")
SET TALK OFF
lc_date = SET("CENTURY")
SET CENTURY ON

* First, Determine the Delimiter Character
DO CASE
CASE "/" $ DTOC(DATE())
Delimtr = "/"

CASE "." $ DTOC(DATE())
Delimtr = "."

OTHERWISE
Delimtr = "-"
ENDCASE

* Next, Verify that the Day and the Month are not the same
* If they are modify the test date (MDate) so they are not
DO CASE
CASE MONTH(DATE()) <> DAY(DATE())
MDate = DATE()

CASE DAY(DATE()) <> 1
MDate = DATE() - 1

OTHERWISE
MDate = DATE() + 1
ENDCASE

DO CASE
CASE SUBSTR(DTOC(MDate), 3, 1) <> Delimtr
* If the 3rd character in the Date is not the
delimiter, Then we
* know it's YMD, Because the year is 4 Characters
long,
* making the delimiter in the 5th position, and there
is no such
* thing as YDM.
DateOrd = "YMD"

CASE STR(MONTH(MDate), 2) = STR(VAL(LEFT(DTOC(MDate),
2)), 2)
* If the Month = the 2 Leftmost Characters Then We
Know It's MDY
DateOrd = "MDY"

OTHERWISE
DateOrd = "DMY"
ENDCASE

DO CASE
* If Delimiter is a Slash, then keep Date Type as YMD,
MDY, DMY
CASE Delimtr = "/"
SaveDate = DateOrd
CASE Delimtr = "."
IF DateOrd = "YMD"
SaveDate = "ANSI"
ELSE
SaveDate = "GERMAN"
ENDIF
OTHERWISE
IF DateOrd = "MDY"
SaveDate = "USA"
ELSE
SaveDate = "ITALIAN"
ENDIF
ENDCASE
SET CENTURY &lc_date
SET TALK &lc_talk
SET CONSOLE ON

RETURN SaveDate




  3 Responses to “Category : Dbase (Clipper, FoxBase, etc) Languages Source Code
Archive   : TN9011.ZIP
Filename : ENVPRES.TXT

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/