On Fri, 19 Dec 2008 00:09:03 +0100 Hans-Peter Diettrich <[email protected]> wrote:
> Mattias Gärtner schrieb: > > > I'm not sure how synedit should handle the unit concept. > > The lfm is associated with the unit. A unit has a starting file > > (e.g. unit1.pas) and an arbitrary list of include files, plus the > > po file of the project/package, the fpdoc xml file and .res files. > > Each of them work together and need very different code. > > No file should be opened more than once, so there must exist a > centralized manager (file pool), keeping track of all open files and > other related data collections. That manager should have a concept of > units. In MVC terms the file pool is the Model, with various Views > (editor, form designer, code explorer...), and everything is > controlled by (an dedicated part of) the IDE. The files itself are 'opened' by the codetools TCodeBuffer. The unit concept is first implemented in TPascalParserTool and extended till TCodeTool. The TUnitInfo further extends the unit concept, as that not all units needs to be opened and can be part of a project. > > synedit is the 'lines' view of the sources. Most of the lazarus > > code don't work with lines, but with whole files or absolute > > positions. > > Right, but when a file is loaded, there must exist means to access > its contents - no matter whether the contents in memory are organized > in lines, there must exist means to map line numbers into the > associated text. That mapping must be done in one dedicated place, so > why not in the owner of the file itself? TCodeBuffer has GetLine(Index: integer) and GetLineRange. But if you want to edit 'lines', then for speed reasons you should create your own TStrings copy and use the hooks (OnInsert, OnDelete, ...) like the source editor does with TSynEdit. Mattias _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
