Updated case of images

Author: DougHennig

.gitignore

@@ -0,0 +1 @@
+*.zip

section4/s4g025.md

@@ -69,7 +69,7 @@ TRANSFORM() can be a very handy way to express a special coding system—suc
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="95" height="77" src="Bug.gif">
+<p><img width="95" height="77" src="bug.gif">
   </td>
   <td width="83%">
   <p>Any attempt to TRANSFORM the contents of a Memo field by specifying a format code results in a return of the string &quot;Memo,&quot; a useless result as far as we are concerned. Apply ALLTRIM() to the memo field to get the result you want. Omitting the format code in VFP 6 or later returns the same result as ALLTRIM()&mdash;but what's the point?</p>

section4/s4g034.md

@@ -14,7 +14,7 @@ Very useful for benchmarking the time to complete a task—record the start
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="94" height="78" src="Bug.gif">
+<p><img width="94" height="78" src="bug.gif">
   </td>
   <td width="83%">
   <p>The SECONDS() function grabs the time when FoxPro starts and stores it in some hidden nook or cranny. Changing the system time while FoxPro is running is not reflected in the SECONDS() function, although TIME() and DATETIME() do seem to pick it up.</p>
@@ -25,7 +25,7 @@ Very useful for benchmarking the time to complete a task&mdash;record the start
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="114" height="67" src="Cool.gif">
+<p><img width="114" height="67" src="cool.gif">
   </td>
   <td width="83%">
   <p>Strangely enough, the SECONDS() function, while ignoring other changes, does note that midnight has passed during the current session and resets SECONDS() to zero. This can be very useful if you are capturing seconds since midnight in an application that might need to run for several days. This was a notorious 2.x bug, squashed finally in 3.0. </p>

section4/s4g035.md

@@ -269,7 +269,7 @@ SET MARK TO is a bit curious. There is always a date delimiter in place. SET MAR
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="94" height="78" src="Bug.gif">
+<p><img width="94" height="78" src="bug.gif">
   </td>
   <td width="83%">
   <p>Help seems to indicate that the delimiter is changed, from dashes to slashes to dots, using SET DATE. This is only the case if a MARK has not already been SET, either explicitly or by FoxPro reading a set of defaults from the Registration Database on startup. To be certain you change both the order and the mark of the date display, you must explicitly issue a separate SET MARK TO command with no argument (see below).</p>
@@ -280,7 +280,7 @@ SET MARK TO is a bit curious. There is always a date delimiter in place. SET MAR
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="94" height="77" src="Bug.gif">
+<p><img width="94" height="77" src="bug.gif">
   </td>
   <td width="83%">
   <p>Help claims that omitting cExpression resets the mark to a slash. It doesn't&mdash;it resets the mark character to the default for the current setting of DATE. If SET(&quot;DATE&quot;) = &quot;GERMAN&quot; and you issue the command SET MARK TO, the mark is now a dot.</p>

section4/s4g041.md

@@ -14,7 +14,7 @@ FILE() returns a logical value if the specified file name exists in the specifie
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="94" height="78" src="Bug.gif">
+<p><img width="94" height="78" src="bug.gif">
   </td>
   <td width="83%">
   <p>If no directory is specified, in addition to the current directory, FoxPro also searches the FoxPro PATH (not the DOS path) set with the SET PATH statement, and returns .T. if the file is found anywhere along that path. It can be argued that &quot;It's a feature, not a bug,&quot; as we might in the section by that name, but this one trips us up often. To specify that FILE()searches only the current directory, you must explicitly specify at least the directory path name, starting at the root of the drive. So you'll probably want to type this command as<br> FILE(CURDIR() + cFileName) in most cases.</p>

section4/s4g059.md

@@ -88,7 +88,7 @@ The AS clause of both commands lets you specify the code page of the original da
 <table>
 <tr>
   <td width="17%" valign="top">
-<img width="94" height="93" src="Design.gif">
+<img width="94" height="93" src="design.gif">
   </td>
   <td width="83%">
   <p>Unlike APPEND FROM, IMPORT doesn't set _TALLY to the number of records imported (in our testing, it set _TALLY to 1). Use RECCOUNT() instead.</p>
@@ -150,7 +150,7 @@ See the discussion above for an explanation of SDF and DELIMITED files. COPY TO
 <table>
 <tr>
   <td width="17%" valign="top">
-<img width="94" height="94" src="Design.gif">
+<img width="94" height="94" src="design.gif">
   </td>
   <td width="83%">
   <p>The behavior of COPY TO ... DELIMITED differs between versions of VFP:</p>
@@ -182,7 +182,7 @@ See the discussion above for an explanation of SDF and DELIMITED files. COPY TO
 <table>
 <tr>
   <td width="17%" valign="top">
-<img width="94" height="94" src="Design.gif">
+<img width="94" height="94" src="design.gif">
   </td>
   <td width="83%">
   <p>COPY TO ... TYPE XLS is as much as 10-15 times faster than COPY TO ... TYPE XL5. In addition, XL5 files are significantly larger than their XLS counterparts. However, date fields aren't treated properly in XLS files. You'll see them displayed in Excel as &quot;DD-MMM-YY&quot;, and changing the format to &quot;MM/DD/YYYY&quot; doesn't help. You actually have to go into each cell, edit (without making any changes), and then click in another cell to see the date formatted properly. Dates work just fine in XL5 files.</p>

section4/s4g068.md

@@ -353,7 +353,7 @@ Each collation sequence has specific ordering rules, needed for a specific purpo
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="95" height="78" src="Bug.gif">
+<p><img width="95" height="78" src="bug.gif">
   </td>
   <td width="83%">
   <p>All collation sequences except Machine use 2 bytes per key so the maximum size of a key expression is only 120 bytes, not 240 as Help states.</p>

section4/s4g070.md

@@ -165,7 +165,7 @@ We're particularly fond of the FROM ARRAY form of CREATE CURSOR and, in programs
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="94" height="94" src="Design.gif">
+<p><img width="94" height="94" src="design.gif">
   </td>
   <td width="83%">
   <p>If any of the fields supports NULL, you are limited to 254 columns because of the hidden &quot;_NullFlags&quot; column (see &quot;Nulls&quot; in &quot;DBF, FPT, CDX, DBC&mdash;Hike!&quot;)</p>

section4/s4g076.md

@@ -134,7 +134,7 @@ nFileSize = FSIZE( cFileName )
 <table>
 <tr>
   <td width="17%" valign="top">
-<p><img width="95" height="77" src="Bug.gif">
+<p><img width="95" height="77" src="bug.gif">
   </td>
   <td width="83%">
   <p>FCOUNT()  and FLDCOUNT() do not report on hidden, system fields (see &quot;DBF, FPT, CDX, DBC&mdash;Hike!&quot;). If you use one of them with FSIZE() to try to calculate the size of a table, you'll come out with the wrong number if any of the fields are nullable. You need to use RECSIZE() or AFIELDS() to test for this, and while you're at it, you can use the return value of AFIELDS() for a better FCOUNT() and the sum of the AFIELDS() size values for a better FSIZE().</p>

section4/s4g080.md

@@ -90,7 +90,7 @@ A word to the wise: INSERT isn't generally the best bet for adding new, empty re
 <table>
 <tr>
   <td width="17%" valign="top">
-<img width="94" height="93" src="Design.gif">
+<img width="94" height="93" src="design.gif">
   </td>
   <td width="83%">
   <p>Watch out when you want to insert data from one table into another. The INSERT command changes work areas behind the scenes <I>before</i> it evaluates the new field values, so you need to add the alias to fields from other tables. Similarly, if you have a variable with the same name as a field in the table to which you're adding a record, be sure to use the m. notation.</p>