home *** CD-ROM | disk | FTP | other *** search
/ Amiga MA Magazine 1998 #3 / amigamamagazinepolishissue1998.iso / bazy / db3.4 / readme < prev    next >
Text File  |  1997-03-16  |  3KB  |  81 lines
  1. Source code for db3.4
  2.  
  3. Legal
  4. -----
  5. I've released the source code for db so you may add what you need.
  6. However you are not allowed to use the source code for commercial
  7. purposes, nor release modified versions under the name "db" without my
  8. permission.
  9.  
  10. You can reach me at the following address if you have any questions:
  11. david-ek@dsv.su.se
  12.  
  13. Regards
  14.  
  15. /David Ekholm
  16.  
  17.  
  18. Building db from the code
  19. -------------------------
  20. The source code for db will compile under the SAS compiler (6.xx). Just
  21. doubleclick on the build icon. Changes made to the SCOptions file will cause
  22. a total rebuild of the project thanks to an intellegent makefile. This
  23. makes it easy for you to make special versions for your particular processor
  24. (020, 040, 060). However don't expect that much speed increase.
  25.  
  26.  
  27. The main files
  28. --------------
  29. db is split upon many source files. Some of them are very specific, and some
  30. are more general. Biggest of them all is db.c. It's a big and hairy one (the
  31. first file). Others are very clean like the ARexx files. They can be used to
  32. add ARexx ports to any program. Start your tour by reading db.h. There you will
  33. find struct definitions that describe how db stores it's data internally.
  34.  
  35. The file dbparser.c handles parsing of the RFF format and building internal
  36. structures that mirror this format.
  37.  
  38. dbGUI.c contains code that calculate the field positions and handle input
  39. events which are in turn directed to db.c
  40.  
  41. Design.c contains code that allows the user to redesign a database view.
  42.  
  43. Select.c contains the code for the Browser window. It is made to work as
  44. a general object for any purpose. You can easily create and use many select
  45. objects at the same time.
  46.  
  47. The DesignGUI files are not used. They could have been the base for a
  48. db with a better GUI design system.
  49.  
  50.  
  51. Internal structure
  52. ------------------
  53. I really should describe this more thorougly, but I don't have enough
  54. inspiration so you will have to stick to this short text:
  55.  
  56. I wan't things to be as dynamic as possible in db in order not to run into
  57. some annoying limitation. Therefore most data is stored in linked lists.
  58.  
  59. The main struct in db is the Pro struct. It stands for Project. Projects may
  60. be stored in linked lists, thus enabling db to handle multiple databases at
  61. once, but that possibility has never been exploited so only one Pro struct is
  62. used. A global variable called CurrentPro points to this single project.
  63.  
  64. A project has it's own set of records stored in a doubly linked list.
  65. Each record has a set of fields stored in one dynamically allocated chunk of
  66. memory for speed and memory saving reasons.
  67.  
  68. A project also has a linked list of internal field information (FldInfo).
  69.  
  70. A project has a number of Layouts (that is the internal name for Views).
  71. Each layout has a window with a number of visual fields (VisFldInfo).
  72. Each visual field has a corresponding gadget which is displayed in the window.
  73. Each visual field has a separator that controls how the next visual field is
  74. drawn on the window in relation to itself. (A separator can be a space, tab,
  75. newline or double newline.)
  76. Each visual field also has a corresponding internal field in the database.
  77.  
  78. The projects, fields, layouts and visual field structs also has linked lists
  79. of RFF tags that control different aspects of db.
  80.  
  81.