Good programs have the right tools, and a plan!

1. The Master's Touch David Blankenship Good programs have the right tools, and a plan!

2. What makes a program a “Windows Program”? The goal of the GUI environment is to have our applications present the "look and feel" of a Windows program application. Proportional fonts and mouse controls are certainly a part of what is commonly recognized as a "Windows Program". End users are not concerned about details, facts, or in many cases, performance! They don't understand that Business Rules is a compiled 32-bit application, and that DOS never made it beyond 16 bits. Judgment is made on LOOKS! Screen design becomes extremely important, but... What else can we do to reinforce our claim of being a Windows Application?

3. What defines the “Windows Look”? Use softer colors and use the Windows color Palette when practical. Use Windows “standard” key combinations (Ctrl+Home, Ctrl+End, etc.) Pull down Menus. Using standard Windows controls where they are applicable (Printer selection using PRN:/select or Win:/select)

4. What else can we do? Use graphics (logos) when printing reports. Proportional spacing may be important, but using a variety of sizes and spacing for each report may be more important than using Courier at 10cpi for all reports! Reduce or eliminate pre-printed forms. High speed laser printers overcome the issue of multiple copies and NCR forms on a dot matrix printer. Save their ears!

5. These forms were printed by a BR Program on plain white paper!

6. Is there anything else? Yes! External tools may be used to "enhance" the appearance of your application. Anything that makes your application look like other Windows applications reinforces the fact that your application is in fact a Windows application! Consider a very basic issue: One of your customers wants to extract all financial transactions for a particular client over the last year to a spreadsheet to assist that client with an audit. Typically you might let your customer name the file (at least 8 characters of the name anyway), but where did you put the file? Many of my programs end by telling the user what the file name is and where it is located. It is up to them to get it, rename it if necessary, and put it somewhere else to protect it! What if?

7. How do I use FileDialog? What if? What if you could use the same “file-open” or “file-save” routine that most windows application use? Introducing FileDialog.exe. Using a very few command line switches, your application can allow the user to select the location and name the file to suit their needs!

8. Any Questions? c:\brag\...\filedialog.exe -B999 -X*.csv -P"c:\Documents and Settings\David\My Documents" -T1 The screen to the right was produced by the command line above using fileDialog.exe The selected file name of vbi-synnex.csv is written to the response file “DBDE999.txt” indicated in the -B switch. (See documentation for details) Results: C:\Documents and Settings\David\My Documents\vbi-synnex.csv

9. How do I save a file? c:\brag\...\filedialog.exe -B999 -X*.csv -P"c:\Documents and Settings\David\My Documents" -T2 The screen to the right is now a “Save As” screen! I changed the argument of the -T switch. The result of typing in a new file name (“susans best effort”) will produce the results below in the response file named “DBDE999.txt” indicated in the -B switch. (See documentation for details) Results: C:\Documents and Settings\David\My Documents\susans best effort.csv

10. What happens behind the scenes? Your program reads the results from the file named with the -B switch. If you ask the question before you extract the required data, you could simply open that file name and write the results, or you could write the results to a temporary file, and after building the extraction, you could copy the file to the permanent path and name obtained. The result is that you have satisfied the requirement to save the file and you have added the ability to allow the user to specify the drive, path, and name of the file! See the next slide for a bit of source code to wrap this up!

11. Sample BR source code Using the command line from my example and the results as they were presented: 10000 ! obtain the name to use for saving the extracted results 10010 execute "sys -w c:\Brag\filedialog.exe -B"&wsid$&" -X*.csv -P""c:\Documents and Settings\David\My Documents"" -T2" 10020 ! note the quotes around the location of the -P switch 10030 ! these are required due to the spaces inside the path argument 10040 sleep(.5) 10050 ! since I did not specify a path and extension the results file 10060 ! will be in the same folder as the application. 10070 if exists("c:\brag\dbde[wsid].txt") then 10080 else 10300 10080 open #180:"name=c:\brag\dbde[wsid].txt",display,input 10090 dim longresult$*200 10100 linput #180:longresult$ 10110 close #180: 10120 ! for this example we have already extracted the results to a file 10130 ! named c:\temp\temp[wsid].csv 10140 ! LONGSTRING$="C:\Documents and Settings\David\My Documents\susans best effort.csv" 10140 execute "copy c:\temp\temp[wsid].txt """&longresult$&""" -N" 10150 goto 10340 10160 ! . . 10300 ! the FileDialog documentation tells us that the results file 10310 ! will not exist if the user elects to "cancel" 10320 ! here you display a message with the option to abort the program (Maybe RadioChk.exe) 10330 ! or re-try the operation to enter a valid destination file name 10340 return

12. Just the Facts! This shows how little code it takes to use FileDialog. All I have done is removed the comments from the previous screen. 10010 execute "sys -w c:\Brag\filedialog.exe -B"&wsid$&" -X*.csv -P""c:\Documents and Settings\David\My Documents"" -T2" 10040 sleep(.5) 10070 if exists("c:\brag\dbde[wsid].txt") then 10080 else 10300 10080 open #180:"name=c:\brag\dbde[wsid].txt",display,input 10090 dim longresult$*200 10100 linput #180:longresult$ 10110 close #180: 10140 execute "copy c:\temp\temp[wsid].txt """&longresult$&""" -N" 10150 goto 10340 10340 return

13. What else can I do? Use your imagination! Dixon and I have written 11 utilities in Delphi to supplement the appearance of various objects to give BR programs the "windows look". These tools are provided at no cost and have no warranty, expressed or implied. It is your responsibility to ensure that they provide a solution acceptable to you and your client. All of the utilities have the supporting libraries compiled into the executable file. There is no "installation". Copy them into your selected location, and integrate into your programs via a system call to provide the "look and feel" of Windows. The total development time numbers in the hundreds of hours. Some of that time is learning, but much of that time is in making the programs flexible enough to accept instructions (switches) and data to build a custom control that appears to be integrated. Our latest enhancement provides you with the ability to position most of the forms created by these programs relative to the current location and size of the BR window! This is not dependent upon the "stored location", but is dynamic...determining the location and size as the program is executed. Happy developing!