Clipper Summer 87 Software Download 6,5/10 5884reviews

Clipper Programming Language. In the Summer '87 version had the words 'dBase III ®. Nantucket Clipper Summer '87 - released December 21.

Ca Clipper Software

I do not know the specific software you are having problems with. I offer simple fix only. Backup the entire affected application. Backup the entire system the affected application sits on.

Make extra backups of both application(s), data,and system. If you have hardware to PARRELLEL your production server do so.

If not, ask your boss why? Only other option at this point: (?) Build 'mirror image' of problem system. Re-install initall software, overlay curent data. Can't do that? Drop PRODUCTION server, and do same. *this is a succeed or fail* task. Choose your choices accordingly.

Regards::) mlv//Mark LeVeck computer system support WORK:314.495.8296. It looks like you have not enough handles for files. If in DOS try more files in config.sys, FILE= Sergey. Here some hints from Norton Guide: DOS Error Messages 4 Too many open files (no handles left) DBFNTX/1003 Open error (index) Action: Check to make sure that the specified file exists. If the file is not in the directory where the application runs, use SET DEFAUL or SET PATH to make the file accessible or specify the full path name where the file can be found.

In a network environment, make sure the application has the necessary rights to access the file. If the file i available only for read access, use the READONLY clause on the USE or SET INDEX command. CA-Clipper's default error handler (Errorsys.prg) will set NETERR() to true (.T.) and will ask DBFNTX to default if the error was due to a sharing violation on the network. See Also: USE command, SET INDEX command, Network Programming chapter in the Programmi.

How I have joined HMG Family – A Story It was in the year 1990, I had seen a computer, first time in my life. I was a commerce student, studying in a 100+ years old school in my home town Sivakasi (famous for fireworks ), Tamilnadu, Southern part of India. I was studying +2 (12th and final year in school). Once, the exams were over, it was time to join a College. Not to waste the exam holidays, one of my friends had asked me to accompany him for a part time computer course in a near by Polytechnic College. I told him, “Ok”.

We joined that course which was for six months, conducted on Saturdays and Sundays. I studied some basics about computers and languages like BASIC, Pascal, COBOL and an introduction to Lotus 1-2-3, Wordstar and dBase III Plus. After that I had joined a college and my main subject was Commerce.

After finishing my Under Graduation degree in the year 1993, I had joined Chartered Accountancy Course. And, once I had finished this course in the year 1996, I joined my brother to manage our family business. Even though there was a computer in our office, I was not allowed to touch that. The reason was, at that time, computers (AT 386) were costlier and one cannot take the risk of losing precious data and computers were operated only by computer professionals. In the year 1997, I had purchased a computer on my own, and started implementing something which I had studied some seven years back. I had studied under the DOS environment and I had got Windows ’95 in my new system as my operating environment. Even though it was easy to operate, I could not do any programming.

I had so much of works before hand and I was involved in them for about 1 year. It was a Costing project in Excel with about 150 sheets, everything interlinked. It was a nice experience. I had done some macro programming in Excel for introducing thousand’s comma according to Indian tradition.

In the year 1998, the computer professional who had programmed for the accounting, invoice processing and payroll processing for our business firm had gone for a better job. We could not create new reports according to the requirements and we had to play only with the old options. Only at that time, I had realized about the importance of Database programming. Having the knowledge of DBase III+ programming, I had started to write small utilities to take self configured reports from the existing tables.

I had the reference of the source codes for the existing software. It was done in Clipper Summer ’87 version. There is a saying, ‘Necessity is the mother of invention’. Necessity had driven me to do more and more programming. Actually, I had started staring huge prg files with various do while.not. Eof() loops and virtually indefinite nested if endif conditions. Once understood, I had the confidence of creating bigger software too.

So, in addition to the accounting software, I had created order processing and inventory maintenance and integrated the same with the existing project. It was in the mid, 1998, I could get an internet connection with a dial up modem. In the mean time, I had a dream of using GUI in my programming. I had tried Visual Basic. I could not link with my existing dbf tables and dropped. In the beginning, I misunderstood about OOPS and GUI.

Actually I had an allergy over this OOPS, I don’t know why even now. So, I had abandoned my dream of GUI because of OOPS. In the year 1999, while searching the net, I had come across a site called, a site which had shared source code/libraries for Clipper and many utilities. From that site, I had got an excellent library called. It had some assembly language routines too to capture mouse gestures and enabled Clipper code to be ‘RAT’ified.

Apart from this mouse functionality, the library had so many small utilities like sorting multiple arrays, finding out Day of the week like that. Actually I had realized about the advantages of Open Source on seeing that library source codes. I had studied in depth, and I had known about optimization of codes, effective memory management, different routes to a same destination in programming etc. With the SuperLib, I had changed all my projects to be mouse enabled, there by satisfying half of my dreams.

However, I could not stop dreaming about creating a full fledged Windows program eliminating the dark DOS command box. As new versions of Windows came in the market, I was afraid that, one day there won’t be this DOS Command Box and all my programs would not be useful at all. I was, why was? Even now am, very fond of Open Source. In my system I don’t use any copyright protected software except the Windows Operating System. I would list all the open source software I use in a separate thread for all my requirements.

I had found out Harbour from the Oasis site I had already mentioned. I had tested a lot but could not use it because of SuperLib, as it could not be linked with Harbour. I was in a confused state. I liked Harbour a lot because of its open nature.

I could not abandon SuperLib too, since all of my projects were linked with this library. So, I was desperately searching for a GUI library (at least mouse enabled for Harbour). On one fine day in my life, my search was fruitful. I could even remember the date. It was 4th of October, 2002, I had downloaded Harbour MiniGUI and could create a window with my limited xBase programming knowledge. I could not describe my feelings in words!

Immediately on compiling my hello world prg, I had commented in the yahoo group from where I had downloaded the 0.40 version of the library with the following words, Dear Roberto, It is wonderful to use your Harbour Minigui Library, an open source library for Harbour. Thank you very much for your sincere efforts. I would like to make a small suggestion regarding text boxes. Shall you please make provision for right aligning the text boxes for numeric fields? Thank you once again.

Srgiri From that day, Harbour MiniGUI page was literally my home page. I read all the messages from various users of the library. It helped me a lot to understand programming, inside out of the library, even about calling C API. I had happily started to convert all of my projects to HMG. As the product matured, all my projects were fully converted to HMG and I had seen my dream come true. Most of my programs are used in-house. However, I had created software for many of my friends.

I had earned some money from my programs too. As you know, my income is not based on programming, since basically I am a Chartered Accountant and managing business. I wish to list some of my major HMG projects, • PyroERP (an ERP software for manufacturing companies with accounting, inventory, order processing,payroll) • PyroBase (a License maintenance software given to Explosives department, Government of India) • FACE (Financial Accounting under Computer Environment) • Interest(ing) Calculator (Calculate interesting part of interest for loans and deposits) – An open source product, hosted in Sourceforge.net. • FBT Reference (Fringe Benefit Tax referencer) • Phataka (A Cultural Event maintenance software used by local Rotary Club) • DBU • GSM Calculator There are many tiny projects too. I am not listing them to show my talents. It shows the simplicity of HMG and my craze on HMG. It is my nature, to escape from any politics.

I wish to be good for all. During July 2005, when Roberto had decided to move on MingW and introduced HMG, MiniGUI Extended product had also born. I didn’t tell a word about anything in the group. I believe in Karma and thought, “if this happens, this is also for the good”. I had actively participated in the yahoo group up to April, 2006 and kept silence after that. However, I used HMG in a full fledged manner and I liked MingW version as Roberto distributed them. This is mainly because of the single installation of the whole thing (ie., MiniGUI library + Harbour Compiler + C Compiler) and full utilization of Open Source Software.

All the software projects listed above where developed by me during the period from 2004 till now. I too had contributed some parts like drawing pie graph, alternative syntax (with the valuable guidance of Roberto) (now Roberto had revamped in a better way!), Grid2Print which Roberto has accepted kindly. Can you believe that this forum had been created in just 2 days time? On 29th of July 2008, I had asked Roberto, breaking my long silence, by an email about the need for a forum exclusively for HMG. Roberto also liked and generously accepted to guide and participate in the forum.

On that day itself, I registered this domain hmgforum.com and installed PHPBB forum software and on 1st of August 2008, the forum was officially opened. I am so HAPPY and PROUD to be part of the HMG family. Thus, this story has a happy ending.

Sri Rathinagiri Sivakasi, India ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Courtesy of author, this article borrowed from. NANFOR.LIB Working Group G. Scott [] Overview UCLA Version 2.1 October, 1992 THE NANFORUM TOOLKIT (NANFOR.LIB) PUBLIC DOMAIN USER SUPPORTED CLIPPER FUNCTION LIBRARY. 1 INTRODUCTION This is a standard for establishing and maintaining NANFOR.LIB, a public-domain, user-supported library of functions designed to interface with Computer Associates CA-Clipper, version 5.01a, and later.

You are encouraged to read it over and forward comments to Glenn Scott, CIS ID []. 1.1 History In October and November of 1990, a discussion on the evolution of third-party products, vendors, and marketing took place on the CompuServe Information Service’s Nantucket Forum (NANFORUM). During this discussion, a forum subscriber named Alexander Santic suggested the idea of a user-supported Clipper function library, available to all on the CompuServe Information Service (CIS). A number of subscribers, including several Clipper third party developers, and some Nantucket employees, expressed their support. This standard was a first step toward organizing such an endeavor.

Release 1.0 of the toolkit was made available in April, 1991 and had nearly 150 functions. By the time version 2.0 was released in August, 1991, the 1.0 library had been downloaded nearly 700 times by CompuServe users.

By October of 1992, release 2.0 had been downloaded over 2100 times. The source code had been downloaded nearly 1500 times. In addition, release 2.0 was placed on the massive Internet archive site called SIMTEL20 where it was downloaded by CA- Clipper users worldwide. Over the course of the year that release 2.0 was available, seven patches were issued, each one gathering nearly 1000 downloads. Computer Associates International, Inc. Acquired Nantucket in the summer of 1992 and subsequently renamed NANFORUM to simply CLIPPER. In addition, the Clipper product itself was renamed to CA-CLIPPER.

Despite the name changes, forum members decided to keep the toolkit’s name as “The Nanforum Toolkit,” partly for nostalgia. References to NANFORUM in this RFC have been replaced with CLIPPER. 1.2 Trademarks CA-Clipper is a registered trademark of Computer Associates International, Inc. Computer Associates will be referred to as CA throughout this document. 1.3 Relationship to CA and third party NANFOR.LIB is a project independent of any third party developer or CA. There is no official “sanction” or “seal of approval” from CA of any kind.

In addition, NANFOR.LIB routines will be accepted and included without regard for whether or not routines performing a similar function are included in a commercial third party or CA product. It is desired that NANFOR.LIB not compete with third party products but rather fill in the holes in CA-Clipper’s standard library.

However, there will be some overlap into commercial third-party library functions, so it would be best if this is never taken into consideration when deciding on including a particular function. Developers submitting NANFOR.LIB routines can and will be corporate developers, third party developers, independent consultant / programmers, hobbyists, and other CA-Clipper people. Perhaps even CA employees will contribute. No one is excluded or included due to any particular affiliation. CA employees submitting functions are doing so as individuals, and are not making a policy of involving CA in the project, nor are they committing CA to supporting the public domain library.

1.4 CA-Clipper version supported NANFOR.LIB functions, no matter what language they are written in, will be designed to work with CA-Clipper version 5.01a and later. Many of the functions, particularly those that use the EXTEND system, will be compatible with the Summer 1987 version of CA-Clipper. However, ensuring Summer 87 compatibility will be the responsibility of the user. If a user wants a function to work with Summer 87, she will have to modify the code herself if necessary.

In many cases, this is a trivial task. 1.5 Queries from new users Queries from new users interested in finding NANFOR.LIB should be handled in a uniform and courteous way. A short text file will be created that will briefly explain NANFOR.LIB, who the current people maintaining it are, and how to get a hold of it. This text message can be sent in response to any query. TAPCIS users will find this method very easy to implement.

2 DISTRIBUTION 2.1 Public Domain NANFOR.LIB, its source code, and documentation will be public-domain software. It is not for “sale”, and shall not be sold. No fee or contribution of any kind will be required for anyone wanting a copy, other than what they would normally pay to download it from CompuServe. Users will be encouraged to submit functions via CompuServe. 2.2 Official repository It is possible that copies of NANFOR.LIB will be downloaded and distributed elsewhere. This is encouraged, but the only copy of NANFOR.LIB and all associated documentation that will be maintained by volunteers is in an appropriate library on the CIS CLIPPER Forum. 2.2.1 Contents The deliverables that make up the official posting on CompuServe shall be: 2.2.1.1 NFLIB.ZIP This will contain the files NANFOR.LIB (library), and NANFOR.NG (Norton Guide).

2.2.1.2 NFSRC.ZIP This will contain all the library source code, makefile, and other source-code related materials. 2.2.1.3 NFINQ.TXT This is a short text file used as a response to new user queries (see paragraph 1.5) 2.2.1.4 NFRFC.ZIP This contains an ASCII format, as well as a WordPerfect 5.1 format copy of NANFOR.RFC named NFRFC.TXT (ASCII) and NFRFC.WP5 (WordPerfect 5.1). 2.2.1.5 NFHDRS.ZIP This contains templates of the file and documentation header blocks, including a sample, for prospective authors (FTHDR.PRG, FTHDR.ASM, FTHDR.SAM) 2.2.1.6 PATx.ZIP These are patch files (see paragraph 4.5.1). 3 POLICY ON INCLUDING FUNCTIONS 3.1 “Best Function” It is possible that more than one developer will submit a function or package of functions that perform substantially the same services. In that event, the referees will choose one to be included based on power, functionality, flexibility, and ease of use. Due to the cooperative, non-commercial nature of the library, no one’s feelings should be hurt by excluding duplicate functions. In addition, it is possible that two substantially similar functions or packages will benefit from merging them together to provide new functionality.

This will be the prerogative of the referees (see paragraph 6.3), in close consultation with the authors. 3.2 Public Domain Each author submitting source code must include as part of that code a statement that this is an original work and that he or she is placing the code into the public domain.

The librarian (see paragraph 6.1) and referees should make a reasonable effort to be sure no copyrighted source code, such as that supplied with some third party libraries, makes it into NANFOR.LIB. However, under no circumstances will the librarian, referees, or any other party other than the submitter be responsible for copyrighted code making it into the library accidentally.

3.3 Source code Full source code must be provided by the author for every routine to be included in NANFOR.LIB. No routine, no matter what language, will be put into the library on the basis of submitted object code. 3.4 Proper submission Due to the volume of submissions expected, librarians and referees may not have the time to fix inconsistencies in documentation format, function naming, and other requirements. Therefore, the librarian shall expect source code to arrive in proper format before proceeding further with it. 3.5 Quality and perceived usefulness In a cooperative effort like this, it is very difficult to enforce some standard of quality and/or usefulness. For example, a package of functions to handle the military’s “Zulu time” may be very useful to some, and unnecessary to others.

The Nanforum Toolkit will by its very nature be a hodgepodge of routines, some of very high quality, some not so high. It is up to the users to improve it. It will be complete in some areas and vastly inadequate in others. It is up to the users to fill in the holes. We shall err on the side of including “questionable” functions, provided they seem to work. Debates on the quality of the library’s source code shall be encouraged and will take place in the proper message section of the CompuServe CLIPPER forum.

4 LIBRARY MAINTENANCE PROCEDURE 4.1 Selection procedure Source code will be submitted to the librarian, the documenter (see paragraph 6.2), or one of the referees. Code will be added if it has been reviewed, and approved by at least one, but preferably two, referees. Code not meeting the documentation or source code formatting standards will generally be returned to the author with instructions. Referees will test the submitted code. When the referees have finished evaluating a submission, they will report their approval or disapproval to the librarian, with comments.

Every effort should be made to make sure that the C and ASM functions are reviewed by referees with suitable C and ASM experience. 4.2 Update interval As new functions are submitted, they will added to the library, and the documentation updated. Because this is a volunteer project, and because of the complexity involved in coordinating testing, documentation, and delivery, there will be no fixed interval for updates. 4.3 Version control NANFOR.LIB will use a numeric version number as follows: The major version will be numeric, starting from 1. This will change with each quarterly update. The minor version will change with each bug fix.

This will start with zero and continue until the next major update, at which point it will revert to zero again. Typical version numbers might be 1.1, 2.12, 15.2, etc. The.LIB file, and all associated files, will carry a date stamp corresponding to the day it is released on the CLIPPER forum. The file time stamps shall correspond to the version number (i.e., 1:03am is version 1.3). 4.4 Announcing updates As the library and its associated documentation are updated, simple announcements will be posted on the CLIPPER forum.

This is the only place where an update shall be announced. An update will be announced after it has been successfully uploaded to the appropriate library on CompuServe. 4.5 Bug reports and fixes The librarian will correlate and verify all bug reports, with the help of the referees. If the referees believe a bug to be serious, they will fix it and the librarian will release a maintenance upgrade immediately. If they consider it a minor bug, they will fix it but wait for the next scheduled upgrade to release it. In this case, a bug fix may be released as a “Patch.” 4.5.1 Patches A “ patch” is simply an ASCII text file containing instructions for editing the source code to a misbehaving function or group of functions.

Patches may appear in the CIS library before a maintenance release or quarterly upgrade. A patch file will have a name of the form PATn.ZIP where is a number starting from 1.

Patches will be numbered sequentially. Patches will be deleted every time a new version of NANFOR.LIB goes on-line. A patch zipfile may optionally contain.OBJ files to be replaced in user libraries via a LIB utility. 4.6 Technical Support Technical support will work just as any technical subject on the CompuServe CLIPPER forum works. Users will post questions and suggestions to a particular message area or thread, and anyone who knows the answer should respond. No one is obliged to answer, but it is considered good form to respond with something, even if one doesn’t know the answer. Support will include help on recompiling the routines or modifying the source.

4.7 Linker Compatibility In order to assist users of CA-Clipper third party linkers (such as WarpLink or Blinker), NANFOR.LIB may need to broken up into root and overlay sections. How this will be done will be determined when splitting becomes necessary. The librarian is not responsible for testing every possible linker for NANFOR.LIB compatibility. It is hoped that linker users will submit appropriate link scripts or other documentation for posting in the appropriate section on the CLIPPER forum. 4.8 Splitting NANFOR.LIB by functional category It is possible that at some future date, it will make sense to split NANFOR.LIB into separate functional areas (e.g., video routines vs. Date routines, etc). This RFC will be modified accordingly should that need arise.

5 FUNCTION CODING STANDARDS The goal of this standard is not to force anyone to rewrite his code for this library, but to create some consistency among the functions so that they may more easily maintained and understood by all CA-Clipper developers, both novice and advanced. However, it is extremely important that anyone submitting code attach the proper headers and documentation and fill them out correctly. This will make it much easier for code to be added to the library.

5.1 Required sections for each function 5.1.1 Header (author name/etc, version ctrl info) Figure 1 shows a header that must be included at the top of every piece of source code submitted to the library. This header will work with both CA-Clipper and C code. For ASM code, substitute each asterisk (“*”) with a semicolon (“;”) and delete the slashes (“/”). /* * File.: * Author.: * CIS ID.: x, x * Date.: $Date$ * Revision.: $Revision$ * Log file.: $Logfile$ * * * Modification history: * --------------------- * * $Log$ * */ Figure 1 - Standard function header. Note that the date, revision, logfile, and modification history fields will be maintained by the librarian and should not be edited or adjusted by code authors. The “ File” field shall contain the source file name.

This is often independent of the individual function name. For example, a function named ft_screen() would be included in SCREEN.PRG. As a rule, source files (.PRG,.C,.ASM) should not have the “FT” prefix. The “Author” field should have the author’s full name, and CIS number.

A CIS number is important, as this will make bug fixing and other correspondence easier. 5.1.2 Public domain disclaimer Authors shall simply state “ This is an original work by [Author’s name] and is hereby placed in the public domain.” 5.1.3 Documentation block /* $DOC$ * $FUNCNAME$ * * $ONELINER$ * * $SYNTAX$ * * $ARGUMENTS$ * * $RETURNS$ * * $DESCRIPTION$ * * $EXAMPLES$ * * $SEEALSO$ * * $INCLUDE$ * * $END$ */ Figure 2 – Standard Documentation Header The documentation block must be carefully formatted as it is used by the documenter to produce the Norton Guide documentation for the library. The keywords enclosed in dollar-signs delimit sections of the documentation header analogous to those in the CA-Clipper 5.0 documentation.

Documentation should be written in the same style and flavor as the CA material, if possible. Refer to the CA-Clipper documentation for more detail and numerous examples.

The documentation will appear on comment lines between the keywords. Examples are optional. Do not put documentation on the same line as the comment keyword. Note that the $DOC$ and $END$ keywords serve as delimiters. Do not place any text between $DOC$ and $FUNCNAME$, or any documentation after the $END$ keyword, unless that documentation belongs in the source code file and not in the resultant Norton Guide file. The $FUNCNAME$ keyword should be followed by the function name, with parentheses, and no arguments or syntax, such as: $FUNCNAME$ ft_screen() Note the indent for readability. Parentheses shall be added after the function name as shown above.

The $ONELINER$ keyword should be followed by a simple statement expressing what the function does, phrased in the form of a command, e.g.: $ONELINER$ Sum the values in an array The length of the entire $ONELINER$ shall not exceed 60 characters (this is a Norton Guide limitation). The $SYNTAX$ keyword should be followed by a CA- standard syntax specifier, such as: $SYNTAX$ ft_screen( [,] ) ->NIL All parameters have proper prefixes (see paragraph 5.4), and are enclosed in. Optional parameters are enclosed in [square brackets] as well. An arrow should follow, pointing to the return value. If there is no return value, it should be NIL. Any others should be preceded with the proper prefix (see the CA- Clipper documentation).

The $SEEALSO$ field provides a way to generate cross-references in the Norton Guide help documentation. Use it to point the user to other related functions in the forum toolkit. For example, if ft_func1() is also related to ft_func2() and ft_func3(), the field would look like this: $SEEALSO$ ft_func2() ft_func3() Note that fields are separated by spaces and the parentheses are included. The $INCLUDE$ area allows you to specify what files are included by this function (this will be used to organize the on-line help file, and possibly the master makefile). An example would be $INCLUDE$ int86.ch int86.inc Other documentation fields should be self- explanatory. Review the appendix for a sample. All fields are required and must be filled in.

Examples should not be considered optional. 5.1.4 Sample header and documentation block Refer to the Appendix for a sample header and documentation block. 5.1.5 Test driver A test driver is an optional section of C or CA- Clipper code that will only be compiled under certain circumstances. Developers are encouraged to include a short “test section” in front of their code. The test driver shall be surrounded by the following pre-processor directives, and placed at the top of the source file: #ifdef FT_TEST [test code] #endif The test driver is currently optional, but authors submitting Clipper code should seriously consider adding it. It is a good way to include short demos within a piece of source code, yet pay no penalty because it is only compiled if needed.

It will be invoked when a #define is created that says “#define FT_TEST.” This is a way for submitters to include short test routines with their functions and yet keep it all in one source file. This will be useful to end users. This test driver may become required in a future version of the RFC. 5.1.6 Code The source code shall be formatted as described in paragraph 5.4. 5.2 Function names All NANFOR.LIB functions start with one of two prefixes.

If the function is to be called by user programs, then it will begin with the prefix FT_ ('F', 'T', underscore) Note that “FT” is a mnemonic for “Forum Toolkit.” If the function is “internal” to a module, then it will be prefixed by an underscore: _FT ( Underscore, 'F', 'T' ) with no trailing underscore. Examples: FT_CURDIR() 'external' _ftAlloc() 'internal' 5.3 Librarian’s authority to change function names Some functions will be submitted that either (1) bear a similar name to another function in the library, or (2) bear an inappropriate name. For example, a function called FT_PRINT that writes a character to the screen could be said to be named inappropriately, as a name like FT_PRINT implies some relationship to a printer. The librarian shall have the responsibility to rename submitted functions for clarity and uniqueness. 5.3.1 Changing a function name after it has been released Once the library is released with a particular function included, then a function name should generally be frozen and not renamed.

To do so would probably cause difficulties with users who had used the previous name and are not tracking the changes to the library. 5.4 Source code formatting 5.4.1 Clipper Clipper code shall be formatted in accordance with CA’s currently defined publishing standard. Although there will surely be some debate over whether this is a good idea, in general, the goal is to provide something consistent that all CA- Clipper developers will recognize. Minor deviations will be permitted. The CA standard usually means uppercase keywords, and manifest constants, and lower case everything else.

In addition, identifiers shall be preceded with the proper metasymbol: n Numeric c Character or string a Array l Logical, or boolean d Date m Memo o Object b Code block h Handle x Ambiguous type Refer to the CA-Clipper documentation for samples of CA’s code publishing format. 5.4.2 C C source code shall be formatted in a generally accepted way, such as Kernighan and Ritchie’s style used in the book _The C Programming Language_.” The use of CA’s EXTEND.H is encouraged.

5.4.3 ASM No particular formatting conventions are required for assembly language source code, since assembly code formatting is fairly standard. Lowercase code is preferred. Be sure to include the proper documentation header information, as described above. Do not place ASM code in DGROUP.

See paragraph 5.11. 5.5 Organization into.PRGs Since many different people will be submitting routines, it is probably best if all routines that belong together are housed in the same.PRG. If there is some reason to split the.PRG, the referees and the librarian will handle that as part of library organization.

5.6 Header files Including a “.ch” or “.h” or “.inc” file with each function would get unwieldy. For the purpose of NANFOR.LIB, all #defines, #ifdefs, #commands, #translates, etc that belong to a particular source file shall be included at the top of that source file. Since few submissions will split over multiple source files, there will usually be no need to #include a header in more than one place. If a “ch” file will make the end user’s job of supplying parameters and other information to NANFOR.LIB functions easier, then it shall be submitted as a separate entity. The referees will decide on whether to include these directives in a master NANFOR.CH file. 5.7 Clipper 5.0 Lexical Scoping NANFOR.LIB routines that are written in CA-Clipper will make use of CA-Clipper 5.0’s lexical scoping features to insulate themselves from the rest of the user’s application. For example, all “privates” shall generally be declared “local.” If a package of Clipper functions is added to the library, then the lower-level, support functions will be declared STATIC as necessary.

5.8 Use of Publics Authors shall not use PUBLIC variables in NANFOR.LIB functions, due to the potential interference with an end-user’s application or vice versa. If a global is required for a particular function or package of functions, that global shall be accessed through a function call interface defined by the author (.e.g, “ft_setglobal()”, “ft_getglobal()”, and so on). Globals such as these shall be declared static in the.PRG that needs them. 5.9 Use of Macros (“&” operator) The use of macros in NANFOR.LIB functions will be, for the most part, unnecessary. Since this is a CA-Clipper 5.0 library, the new 5.0 codeblock construct should be used instead.

Anyone having trouble figuring out how to convert a macro to a codeblock should post suitable questions on the CLIPPER forum on CompuServe. 5.10 Use of Static Functions Any CA-Clipper 5.0 function that is only needed within the scope of one source file shall be declared STATIC. This applies mostly to NANFOR.LIB “internals” (names with an “_ft” prefix) that user programs need not access. 5.11 Use of DGROUP in ASM Functions Use of DGROUP in assembly language functions shall be avoided, in accordance with CA’s recommendations. Assembly functions written for NANFOR.LIB shall use a segment named _NanFor, as in the following example: Public FT_ChDir Extrn _ftDir:Far Segment _NanFor Word Public 'CODE' Assume CS:_NanFor Proc FT_ChDir Far... Ret Endp FT_ChDir Ends _NanFor End 5.12 Use of 'Internals' Use of CA-Clipper “internals” by code authors is allowed.

However, should any code make use of an internal, i.e., a function or variable that is not part of the published CA-Clipper API, then that internal shall be clearly marked in the documentation (under “DESCRIPTION”) and in the actual code, everywhere the internal is used. 5.13 Procedures for compiling functions 5.13.1 Clipper Clipper functions will be compiled under the current release of CA-Clipper 5.0, with the following compiler options: /n /w /l /r Note that neither line numbers nor debugging information will find its way into NANFOR.LIB, to keep the code size down. End users may recompile NANFOR.LIB with these options enabled if they want to view NANFOR.LIB source in the debugger. 5.13.2 ASM Assembly functions must compile successfully under any MSDOS assembler capable of producing the proper.OBJ file. However, care should be taken not to use any macros or special syntax particular to one vendor’s assembler, because that would make it difficult for end users to recompile the source. The preferred assembler is MASM, followed by TASM. 5.13.3 C C functions must compile successfully under any C compiler capable of interfacing to CA-Clipper.

Obviously, Microsoft C, version 5.1, is the preferred development environment. Care should be taken, when writing C code, not to use any special compiler features particular to one vendor’s C compiler, because that would make it difficult for end users to recompile the source. 5.14 Functions requiring other libraries It is very easy to write functions in C that call the compiler’s standard C library functions. However, NANFOR.LIB can make no assumptions about the end user’s ability to link in the standard library or any other library. Therefore, no function will be added to NANFOR.LIB that requires any other third party or compiler manufacturer’s library. 6 ADMINISTRATIVE DETAILS 6.1 Librarian The librarian will be the person who rebuilds the library from the sources and uploads the resulting deliverables to the proper CLIPPER forum library on CompuServe. The librarian generally does *not* test code or edit source code to repair formatting errors.

6.2 Documenter The documenter is responsible for maintaining the Norton and guides and keeping it in sync with each new release. 6.3 Referees Referees are volunteers who read source code, clean it up, compile it, look for problems like potentially problematic C code, decide on which function is best, consolidate common functions, etc. They make sure the header and documentation blocks are present.

There is no election or term for refereedom. One simply performs the task as long as one can and bows out when necessary. 6.4 Transitions Not everyone will be able to stay around forever to keep working on this project. Therefore, it is the responsibility of each referee, documenter, or librarian to announce as far in advance as possible his or her intention to leave, in order to give everyone a chance to come up with a suitable replacement. Don’t let it die! 7 CONTRIBUTORS Current contributors, directly and indirectly, to this document include: Don Caton [] Bill Christison [] Robert DiFalco [] Paul Ferrara [76702,556] David Husnian [] Ted Means [] Alexander Santic [] Glenn Scott [] Keith Wire [] Craig Yellick [76247,541] James Zack [] NOTES: • In Harbour library file name of NanForum Toolkit is hbnf.a • Maybe some functions: • obsoleted, • used some low-level hardware access or some OS specific features, • so not included in hbnf library. A tale about the origin of Clipper There is a tale about the origin of CA-Clipper.

Whether it is true or not, few people know, but “insiders” have said that it is not far from the truth. One day in a seafood restaurant in Malibu, California, an Ashton-Tate employee and a consultant friend were having lunch. They were expressing their annoyance at the fact that Ashton-Tate had not created a compiler for the dBase language. The two thought that maybe they should have a go at starting up a new company to create the compiler. As the excitement grew and the ideas flew, the issue of a product name came up.

One of the two noticed a picture of a sailing ship on the napkin (after all this was a seafood restaurant). It was a clipper ship — a sleek, speedy, and elegant thing. That seemed to describe what they were trying to create.

What about the company name? The menu answered that question — the restaurant name was Nantucket Lighthouse. And so Nantucket’s Clipper was born. The consultant was Barry ReBell and the Ashton-Tate employee was Brian Russell. Since that time there were four “seasonally” named versions of the compiler: Winter 85, Spring 86, Autumn 86, Summer 87. Very “California” These early versions clearly billed themselves as dBase compilers, with the Summer 87 version displaying “dBase III® compiler” on the floppy disks and documentation.

Many programmers using Clipper at the time were really “just” dBase programmers with a tool to create faster programs. So it was quite a shock to them when Clipper 5 was released. “What have they done to our language?”, they asked. Local variables? But there were also those of us who had strained against the limitations of the dBase language — the lack of modularity, the clumsiness, the vulnerability of public and private variables. So we recognized that Clipper 5 was a turning point in the history of the Xbase language.

No longer billed as a dBase compiler, Clipper became an “Application Development System”. A real language.

Well, maybe not as real as C, but getting there. In fact, many Clipper 5 concepts were borrowed from C and other languages.

The increment operator ( ++) and expression lists, for example, seem to have come from C, while code blocks may have been inspired by SmallTalk ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This article borrowed by courtesy of author, from. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please look at for continuation of this post.

A Wikibookian believes this page should be split into smaller pages with a narrower subtopic. You can help by splitting this big page into smaller ones.

Please make sure to follow the. Dividing books into smaller sections can provide more focus and allow each one to do one thing well, which benefits everyone. You can ask for help in dividing this book in the. Quite a lot of people were interested in this page (it was the most visited page in my former website) and so I feel that I must complete it.

This page disappeared when GeoCities was closed (in fact it still contains some broken links to GeoCities pages), and it has been reloaded thank to some requests I got, for example on Facebook. There you can find the 'Harbour MiniGUI' group, and others. When (and if) finished, it will prove a complete guide to Open Source Clipper programming. However, this page is still very incomplete.

Recently (it is now ) I noticed a new Wikibook on a subject similar to this: I just threw in some stuff, for the moment. This page is derived from what I call the 'hubbub version'. As a newbie to Wikibooks, I did not yet properly format the few sources in this page (Wikibooks has syntax highlighting for Clipper, but it is a bit buggy). If you check it, you will see misplaced links and so. This page definitely needs proofreading!

A former version of this 'ebook':-) is at (I'd like to thank W. Birula for making me know it). I'd like to see this tutorial grow! If someone on the newsgroup comp.lang.clipper or on the mailing lists HarbourUsers () would give me help or clues.

To apologize for its incompletedness, I can only say that this page contains everything I know about Clipper and xBase programming (in a given moment. I always try to learn new things.). I tried to adhere to the classical tutorials' bottom-up approach of showing all the basic function via very simple examples. The plan to include some bigger examples, with the top-down approach (how do I deal with this problem?) is suggested, but not yet pursued.

I have decided to name this tutorial 'a Guide to Open Source Clipper(s)' and not 'a Guide to Open Source xBase' because I like the name Clipper, and as you can see by watching at the open source compilers I discuss (Clip and (x)Harbour) the influence of the name Clipper is great. Only X2c doesn't recall the name Clipper. And now X# Modern xBase open source dialects are: • Harbour and xHarbour, which are the more active projects • Clip, which is not being updated since 2013 • X#, which will be a xBase for.NET X2c is too old - what use could be for a modern xBase the need to get its compiler from the Borland Museum? This Guide was born when I followed a small project (the port of an old Summer 87 application to Windows) and I saw the many Clipper compatible open source compilers available, but noticed also that there were no good tutorials and that the books about Clipper/xBase/Visual Objects and so on couldn't be found in any bookstore (not even in libraries!). I think that the first part of the tutorial will cover the basic of the language, up to the procedural programming facilities.

Part 2 will deal with the native DBF file support. Part 3 will explain OOP. Part 4 will cover other programming topics, and the last part will be about programming a user interface. This makes up for a nice introduction to computer science. Thanks to bpd2000 for the nice link he provided.

Michele Povigna • • • Part 1: The Common Ground • Chapter 1: Basic Language Tutorial • Chapter 2: Database Making • Part 2: Additions to the Language • Chapter 3: Object Oriented Programming • Chapter 4: Some More Advanced Programming Topics • Part 3. Function MAIN * This is an example clear? 'Hello, the weather is fine today' return (in GeoCities this and all other sources were highlighted by the on-line service CodeColorizer at ). We will comment each line of the helloworld program. Function MAIN The first line defines a function named MAIN. Defining such a function is not compulsory with Harbour, as if it is missed errors would occur during compilation, but I will keep it to make sure the examples work with all compilers. We will learn later how to define and use functions and procedures.

* This is an example The second line is a comment. Commenting your programs will help you when you are to modify them later. If they aren't commenting, modifying them will be a very hard task. It will be much more difficult if you are to modify programs written by others if they didn't comment them: figuring out what a program does using only its code is very difficult and even the most clean programming language may prove to be write-only if not properly commented. You can write comments in many different styles: using an asterisk (*), two sweeps (//), a double ampersand (&&) or a couple sweep-asterisk (/*) and asterisk-sweep (*/), as you see below: * This is a comment.

//.and so is this. /* This is an example of the fourth commenting style, which may span over several lines.*/ The second and the fourth commenting styles are derived from the C programming language, the first and the third are peculiar of the Clipper/xBase standard. Clear No, the purpose of this command is not to make the source code clear (that would be too easy! It is up to us to write clear source code, and to do so we must comment it well), but instead to clean the screen.:-) You could also use clear screen or cls, although these two commands are not exactly the same of this clear (the difference will be clear later, when we can GET the point - then, you could also appreciate the pun in this paragraph - but will more likely not). What are commands? Harbour commands are defined in the file std.ch via the #command macro directive ().

The first commands we encountered are defined by these lines: #command CLS =>Scroll(); SetPos(0,0) #command? [] =>QOut( )? 'Hello, the weather is fine today' The? Is a command which means print. In the BASIC programming language, it is also an abbreviation for its print command (the syntax of xBase is quite similar to that of the BASIC programming language). In this case?

Print the string Hello, the weather is fine today. Please note that the string return Return is used to terminate the function. We will explain later what the return exactly does.

Today Harbour needs not an explicitly defined main function/procedure. The following version of helloworld will compile and is exactly the same of the previous one. The Harbour Interpreter and Virtual Machine The program above, stored in a text file named hello.prg, can be run with the command hbrun hello.prg hbrun is an interpreter for Harbour. This means that if we run it, we get to a screen with a 'Dot prompt' on its last line, where we can enter and run instructions.

For example entering? 'Hello world' will get Hello world printed on the screen, but only after the interpreter hbrun itself is closed. To quit the interpreter and get the greeting printed type QUIT All in all, hbrun permits to feel how handling databases was done in the old dBase 'Dot prompt' mode - that is, like this: Running the compiler harbour (harbour.exe on Windows) on a printA.prg containing the line? 'A' will output a printA.c file. The bottom of this file reads.

&& example of compilation command && A: >c: hb31 bin hbmk2 -quiet -oc: test.exe test.prg -run && please note that this example has not a MAIN function: I found that Harbour 3.0 can compile it anyway && an example of string concatenation? 'Hello' + ' ' + 'World!' && let us do now a few numerical computations, integer numbers are a good starting point? 3/2 SET DECIMALS TO 15 sqrt2= sqrt(2) && computing the square root of 2.?

And printing it &&? Caporetto && if the line above was not commented, the compiler would issue the two following lines && Error BASE/1003 Variable does not exist: CAPORETTO && Called from TEST(8) && as xBase is not good at history, let us revise it: && we can then assign the correct date to this war caporetto:= ctod( ') a:= date() && system date? A + 1 && will print tomorrow's date? A - caporetto && this will tell us how many days have passed since Caporetto's battle (difference between two dates) SET DECIMALS TO 2? (a - caporetto) / 365??

' years have passed since Caporetto's battle'? 1+1=3 && it will print '.F.' , that is, 'FALSE' (of course.) && The following two instructions should be discussed to expand on the subject of operator precedence?

1/2+2^3*(sqr(25)-3^2) From the following example (which runs) we see that Harbour is a weakly typed programming language: a variable, such as a in our example can be a number, and then become a string of text. && First we print the values of two expressions with the exponentiation operator? 3**3**3 && is 19683?

3**(3**3) && is 987 && Then we let our compiler tell us if they are the same? 3**3**3 = 3**(3**3) && result is.F. && We've a look at how our compiler deals with overflow and underflow.? 9**9**9 && ***********************? 1/9**9**9 && 0.00? -(9**9**9) && *********************** We see in this example that the exponentiation operator ** is left-associative (where in mathematics exponentiation is a right-associative operation). The fact that 3**3**3 and 3**(3**3) give two different results means that parenthesis alter the operator precedence: whatever is enclosed in parenthesis is evaluated first.

Even when the operation is left-associative, the result of 9**9**9 is quite a 'large' number (91196809 to be precise, as you can easily check - maybe using some arbitrary precision calculator program, such as GNU bc, which is available on every Linux distribution and as a download for Windows at ) which exceeds the resources Harbour allocates for a number (which is called overflow) and it therefore prints 23 times a * to indicate this error. It also gives zero (0.00) if we try to compute its reciprocal (which is underflow). Overflow and underflow errors happen when the result of a computation is, respectively, too big or too small to be represented with the number of bits a compiler has allocated for the variable in which we're trying to store it in. Boolean Algebra & Flow Control [ ] We can print the result of a comparison, which is a Boolean value (represented as.T. Or.F.), but they are useful with special words in order to branch or repeat the execution of one or more instructions. We have a Boolean expression when its result is true (whose xBase symbol is.T.) or false (.F.). The easiest way to get a Boolean result is to use a comparison (relational) operator: =, ==,!=,, #, >, =, and.

INPUT 'Key in a number: ' TO char char:= 'e' IF ( ( char = 'a'.OR. Char = 'A' ).OR. ( char = 'e'.OR. Char = 'E' ).OR. ( char = 'i'.OR. Char = 'I' ).OR. ( char = 'o'.OR.

Char = 'O' ). Magic Workstation Registration Keygens Digital Insanity. OR. ( char = 'u'.OR.

Char = 'U' ) )? Char, ' is a vowel' ELSE? Char, ' is not a vowel' ENDIF This same thing could however be achieved better by the use of regular expressions. Looping [ ] DO WHILE, EXIT, LOOP, ENDDO are keywords used To repeatedly execute a series of statements (loop body) while a condition is true (i.e. Its result is.T.). Loops come in several flavours: the pre-tested loop, the post-tested loop, and the definite iteration, which is done via a count-controlled loop (usually called a for loop). In practice, we may have a middle-tested loop as well, but no specific syntax for it.

We need to put an EXIT statement within an already existing loop body to get this one. The next program we will key in is of some interest for the mathematicians (Real Programmers aren't afraid of maths, do you know this famous adage?) Here is it. && Function MAIN LOCAL number, sum, n && An anonymous contributor renamed the variable 'num' into 'number', increasing this short program readability, but the line above would give && Error E0030 Syntax error 'syntax error at 'LOCAL' Function MAIN LOCAL number, sum, n CLS? 'Let's sum up the first n odd numbers.' INPUT 'How many numbers shall I sum up?

' TO n sum=0 number=1 DO WHILE number. 'I won't stop.' ENDDO This loop prints 'I won't stop.' As long as 'true' is.

It is thus called an infinite loop because the ending condition will never be satisfied. It is the first example of control flaw studied in computer science classes.

By definition, you incur in an infinite loop every time you specify a tautology as the condition to be checked. It is not always obvious to detect this and other control flaws and errors - it is indeed a process that involves the use of a specific piece of software called a debugger.

Counter-controlled Loops [ ] The FOR.NEXT construct (counter-controlled loop) is useful when we know how many times we want the loop body be executed. We shall now use it to print out and revise multiplication tables. CLEAR FOR I:= 1 TO 10 FOR J:= 1 TO 10 @i,j*4 SAY I*J PICTURE '999' NEXT NEXT this way we can print it much prettier. By the way, when nesting loops and branching statements, it becomes important (practitioning programmers say so, and in my little I agree) to arrange the indentations in order to make the program easier to read.

In The Oasis are available 'source code beautifiers' such as dst314.zip. Harbour gives us the hbformat tool,. PICTURE '999' is the instruction to specify we want the output format - as we specified three digits, the numbers in output will be printed as if they were three digits long, thus aligning them in our multiplication table. Functions and Procedures [ ] A function is a piece of code that returns a result every time it is called.

Let us consider a function to convert Celsius into Fahrenheit. PROCEDURE Main // Random number between 0.01 and 0.99? HB_Random() // Random number between 0.01 and 9.99? HB_Random(10) // Random number between 8.01 and 9.99? HB_Random(8,10) RETURN A good function would function as a 'black box', that is you can use it without worrying about how it internally works. An example usually given at this point is that of driving a car: you can use it without worrying about how the engine works (do you know anybody which looked at the pistons of their new car before buying it?).

Someone else designed the engine. But there may be problems: if we change our Celsius into Fahrenheit function as follows. FUNCTION cels2f( tempCelsius ) tempFahrenheit:= (tempCelsius*1.8 + 32) number:= number + 1 RETURN tempFahrenheit FUNCTION MAIN() number:= 0? Cels2f( 100 )? Number we'll get a side effect.

This program output is 212.0 32.0 2 That is, our new function did not only return a value, it also increased by 1 the variable number. The Clipper Norton Guides read, 'A procedure in CA-Clipper is the same as a user-defined function, with the exception that it always returns NIL' (), thus a procedure is really just a type of function that relies on these side effects to get something done. The utility of functions is that they improve program readability, maintainability. Splitting a program into functions is a good design approach, which lets breaking a complex problem into smaller, simpler problems ( top-down). Harbour has four different kinds of subroutines/subprograms: • the FUNCTION and • the PROCEDURE (which is a FUNCTION with no return value), • the method (which has not an associated keyword, works like every object oriented programming language) and • the code block. Why the Main Function?

[ ] The main function is the designated start of a program written in C or C++ (Java uses a static main method). Since a procedure is a function that returns NIL, we can have a procedure main instead of a function main in our program. With Harbour it is not necessary anymore.

Another characteristic of variables: scope identifiers [ ] Variables have a name, a type, a scope and a lifetime () which may be explicitly declared as (list below copied verbatim from ): • LOCAL: Visible only within the routine which declared it. Value is lost upon exit of the routine. • STATIC: Visible only within the routine which declared it. Value is preserved for subsequent invocations of the routine. If a STATIC variable is declared before any Procedure/Function/Method is defined, it has a MODULE scope, and is visible within any routine defined within that same source file, it will maintain its life for the duration of the application lifetime.

• PRIVATE: Visible within the routine which declared it, and all routines called by that routine. • PUBLIC: Visible by all routines in the same application.

They do not make sense before we work with functions and procedures. /* Work on the following. * hbformat was run on this piece of code * need to provide comments, nest more functions and procedures to help figuring what goes on with scope modifiers */ STATIC x:= 9?

X PROCEDURE A LOCAL x:= 10? 'x from A=', x RETURN PROCEDURE B PRIVATE x:= 5? 'x from B=', x RETURN PROCEDURE C PUBLIC x:= -1? 'x from C=', x RETURN PROCEDURE D? 'x from D before updating value=', x x:= 12?

'x from D=', x RETURN PROCEDURE E? 'x from E=', x RETURN On running this, we get a strange output: 9 x from A= 10 9 x from B= 5 9 x from C= -1 9 x from D before updating value= -1 x from D= 12 9 x from E= 12 9 This program sets a variable x and five different procedures, A, B, C, D, E.

The first three procedures define a variable x within themselves, assign it a value and print it. The fourth function assigns a new value to some variable named x without declaring it. The fifth function shows the value of some x variable, which happens to be the value of the fourth x variable. The main fact to remember here is that two variables are not the same, even if hey have the same name, provided they have different scopes and this feature is called shadowing. X PROCEDURE A LOCAL x:= 10? 'x from A=', x RETURN PROCEDURE B PRIVATE x:= 5? 'x from B=', x RETURN PROCEDURE C PUBLIC x:= -1?

'x from C=', x RETURN PROCEDURE D? 'x from D before updating value=', x x:= 12? 'x from D=', x RETURN PROCEDURE E?

'x from E=', x RETURN 9 x from A= 10 9 x from B= 5 9 x from C= -1 -1 x from D before updating value= -1 x from D= 12 12 x from E= 12 12 As static variables seem to require further informations (they work like C static variables), here is an example. // adapted from 'An example of static local variable in C' (from Wikipedia Static_variable) FUNCTION func() static x:= 0 /* x is initialized only once, the first time func() is called */ x:= x+1?

X RETURN FUNCTION main() func() // calls func() a first time: it prints 1 func() // value 1 was preserved; this time it prints 2 func() // prints 3 func() // prints 4 func() // prints 5 See pascal_variable_scope in tutorialspoint.com and Variable scope is a foretaste of object oriented programming, in the sense that it anticipates some encapsulation concepts. The search for the Ludolphine [ ] Part 1: Using the Clipper Tools (CT) Library [ ] If you checked the list of functions you will have noticed that the xBases have no trigonometric functions. Not that in general they miss them: these languages are targeted database applications such as 'accounting systems and airline reservations systems' (see. ) in which trigonometric functions are not really important. But we now ask ourself how to compute an approximation to the Ludolphine number, π (more informations on this 'search' at ), We can do it using the CT library (see ), or importing the C standard library function atan. // we'll declare and load random numbers from 1 to 100 in an array DECLARE arrayToSort [12] FOR I = 1 TO 12 arrayToSort [I] = Int( HB_Random( 1,101 ) ) NEXT // we review our array FOR I = 1 TO 12?? ArrayToSort [I] NEXT // we'll do Exchange Sort as described in // where there is also a nice animation showing how it works!:) for i:= 2 TO Len(arrayToSort) for j:= Len(arrayToSort) TO i step -1 IF arrayToSort [j - 1] >arrayToSort [j] TEMP:= arrayToSort [j - 1] arrayToSort [j - 1]:= arrayToSort [j] arrayToSort [j]:= TEMP ENDIF NEXT NEXT??

'Sorted array:'? // we look at our sorted array FOR I = 1 TO 12?? ArrayToSort [I] NEXT Here is our basis.

We'll add a flag variable to improve this algorithm. Database making [ ] Let's return to the Wikipedia entry.

Different kinds of database applications exists as well. If you did store your friend's phone numbers and addresses into a word processor, you would have what is called a Free-Form Database (however, a similar expression is an oxymoron in computer science) - askSam is a specialized free-form database application. Now, a word processor lets us search the informations, but other operations, such as sorting them, cannot be done automatically by a word processor. What about attempting to store it into a spreadsheet? We may use one column for the name, one for the surname, one for the telefone number, one for the city.

This quick database, stored in a spreadsheet, may be searched and sorted: for example we can sort it by city and person's name in alphabetical order. This is a flat database,: a flat database is a sequence of newline terminated records of delimiter separated fields, and a spreadsheet shows its limits in data entry and reporting (if you did want to use the data in your table to print out addresses on envelopes a spreadsheet is not a good tool). An example is MyDatabase (). Spreadsheets are much better to do accounting: how much harder a book-keeper's work would be if his data were stored in a wordprocessing program? The purpose here is to have our data structured in a certain way: all the costs in a place, all earnings in another.

Before 1970 complex databases where managed using Hierarchical Databases (very little information is needed about them - see for example and ). An example of a hierarchical database is IBM IMS (Information Management System, which was developed during the mid-1960s for applications in the aerospace industry). Hierarchical Databases and Network Databases together form what today are referred to as Legacy Database Systems.

Network databases where born as an extension to the programming language COBOL by the Conference on Data Systems Languages (CODASYL). Today's standard is a relational database, which is 'a database with relationships between more than one table of records based on common fields'. We will speak of them in detail, but we will briefly mention the fourth approach: Object Oriented Databases. These databases store objects (in the same sense the word is used in the expression object oriented programming). They're not much used, mostly because object are more complex than the simple fields a relational database stores in its tables. Making a first database and recording some data [ ] A verbose way [ ].

CREATE TMPNAMES USE TMPNAMES APPEND BLANK REPLACE FIELD_NAME WITH 'NAME' REPLACE FIELD_TYPE WITH 'C' REPLACE FIELD_LEN WITH 15 APPEND BLANK REPLACE FIELD_NAME WITH 'ADDRESS' REPLACE FIELD_TYPE WITH 'C' REPLACE FIELD_LEN WITH 30 CLOSE CREATE NAMES FROM TMPNAMES && The code above created a DBF file, names.dbf, to be used by the following code. It will add a record to the DBF file. It is equivalent to the 'First Sample Program' of my old PC GUIDE, which missed a line that is necessary in modern xBase. 'First Sample Program' SELECT 1 USE NAMES APPEND BLANK REPLACE NAME WITH 'MIKE BROWN' REPLACE ADDRESS WITH 'ROME STREET, 56' CLOSE && this line is missing in my PC GUIDE but is needed QUIT The CLOSE command is equivalent to the dbCloseArea() function, which closes a work area: Pending updates are written, pending locks are released.

A more concise way [ ] The short code below does the same work of the two pieces of code of the previous section (it only produces a different file name, namesdb.dbf instead of names.dbf). USE NAMES LIST DATE(), TIME(), NAME, ADDRESS Database Design Issue: the First Normal Form (1NF) [ ] The work done in the previous section was intended to exactly reproduce the database proposed in my PC GUIDE.

There are, however, inconvenients: having only one NAME field, this database cannot sort its data on the last name. Also, a careless user might insert the data of some people with the last name first, and some other data with the first name last. When designing a database precautions should be taken of these possibilities. The first normal form (, ) requires you to define fields whose information cannot be divided into smaller parts. So, instead of a NAME field, we should have a FIRST_NAME and LAST_NAME fields. Complying to the first normal form, our little database would be on the on the right track to being a normalized database.

Complicating our simple database [ ] Harbour contains a file named test.dbf. Launch hbrun in its directory and type in use test browse() At this point we see that it is a 500 record table. Move around with the cursor keys and, when you're finished, punch the Esc key to quit this interactive table browser and editor. To get the record number of a person called Ted issue: locate for first='Ted'? Recno() Here is the testdbf.prg source from hb30 tests. It should be discussed in detail.

It is a GPL piece of code poorly commented. LASTREC() DELETE RECORD 4 PACK? LASTREC() In this piece of code the command DELETE marks the fourth record for deletion.

But the file is not altered, not even by a CLOSE command. The PACK command actually removes the records marked for deletion (and also makes some additional work). The RECALL command removes the deleted flags. The function DELETED() returns.T. If the current record is marked for deletion,.F.

The PACK command, which does the actual deletion of data from the table, PACK requires that the current database be USEd EXCLUSIVEly. If this condition is not met when PACK is invoked, CA-Clipper generates a runtime error.

Additional work that PACK does is to update indexes on the table it alters (if any). The commands DELETE ALL and PACK are executed by a single command called ZAP. Distance3d(1,1,1,4,4,4) FUNCTION distance1d( x1, x2 ) RETURN sqrt((x2-x1)^2) FUNCTION distance2d( x1,y1,x2,y2 ) RETURN sqrt((x2-x1)^2+(y2-y1)^2) FUNCTION distance3d( x1,y1,z1,x2,y2,z2 ) RETURN sqrt((x1-x2)^2+(y1-y2)^2+(z1-z2)^2) We defined three functions, with different names, which take as arguments the coordinates. But doing so we need to pass six arguments for the distance in a three-dimensional space.

If we're doing it with object oriented programming we may get something like this. FUNCTION Distance ( Point1, Point2 ) RETURN Sqrt( ( Point1:Abscissa - Point2:Abscissa ) ^ 2 + ( Point1:Ordinate - Point2:Ordinate ) ^ 2 + ( Point1:Zcoord - Point2:Zcoord ) ^ 2 )? Distance( FifthPoint, SixthPoint ) This is, however, not object-oriented programming, as we could have written the same function with a not object-oriented language such as Pascal or C, passing it two structs, or records as Pascal calls them, named Point1 and Point2. It is important the fact that some data internal to the object (set by the real programmer of the thing) can't be changed by the object user.

In real life an example is that of a car engine. The provider of the object set a number of cylinders, and we have not many chances of changing that: we've got to regard it as a constant. There is naturally a number of interesting formulas about engines that engineers use (some to be seen at ). For example the one for computing the Engine Volumetric Efficiency given the volume of air taken into a cylinder and the cylinder swept volume. Here comes the importance of data hiding: nobody needs to know those informations to get his car going. Also, when someone designes an engine they probably don't expect the user to change the volumetric efficiency by operating on the engine. The same thing is obtained in object oriented programming using visibility modifiers, or access modifiers.

[CREATE] CLASS [ FROM INHERIT [.,] ] [ MODULE FRIENDLY ] [ STATIC ] [ FUNCTION ] [HIDDEN:] [ CLASSDATA CLASSVAR CLASS VAR ] [ DATA VAR [,] [ AS ] [ INIT ] [[EXPORTED VISIBLE] [PROTECTED] [HIDDEN]] [READONLY RO] ]. [ METHOD ( [] ) [CONSTRUCTOR] ] [ METHOD ( [] ) IN LINE ] [ METHOD ( [] ) BLOCK ] [ METHOD ( [] ) EXTERN ([]) ] [ METHOD ( [] ) SETGET ] [ METHOD ( [] ) VIRTUAL ] [ METHOD ( [] ) OPERATOR ] [ ERROR HANDLER ( [] ) ] [ ON ERROR ( [] ) ].

[VISIBLE:] [EXPORTED:]. [FRIEND CLASS ] [FRIEND FUNCTION ] [SYNC METHOD ] ENDCLASS [ LOCK LOCKED ] Another example [ ] Copied verbatim from. #include 'hbclass.ch' PROCEDURE Main() LOCAL oPerson CLS oPerson:= Pers on():New( 'Dave' ) oPerson:Eyes:= 'Invalid' oPerson:Eyes:= 'Blue' Alert( oPerson:Describe() ) RETURN CREATE CLASS Person VAR Name INIT ' METHOD New( cName ) METHOD Describe() ACCESS Eyes IN LINE::pvtEyes ASSIGN Eyes( x ) IN LINE iif( HB_ISSTRING( x ).AND.

X $ 'Blue,Brown,Green',::pvtEyes:= x, Alert( 'Invalid value' ) ) PROTECTED: VAR pvtEyes ENDCLASS // Sample of normal Method definition METHOD New( cName ) CLASS Person::Name:= cName RETURN Self METHOD Describe() CLASS Person LOCAL cDescription IF Empty(::Name ) cDescription:= 'I have no name yet.' ELSE cDescription:= 'My name is: ' +::Name + ';' ENDIF IF! Empty(::Eyes ) cDescription += 'my eyes' color is: ' +::Eyes ENDIF RETURN cDescription Harbour CGI [ ] and see the side box.