[lazarus] CVS Changes

[Shane Miller]

TUnitInfo is no longer going to be used so we can't rely on it for anything.  

See, if you load a file you call TSourceNotebook.OpenClicked (when they click on the Open menu item).  OpenClicked will display the OpenDialog and then it creates a new TSourceEditor and set's it's FIlename to OPenDialog.Filename.  Then it calls TSourceEditor.Open.

Saving:  IF you click the menuitem Save it calls TSourceNotebook.SaveClicked.  Then the ACTIVE SourceEditor is saveed.  TSourceNotebook searches to see which TSourceEditor is on the active TSourceNotebook page and then it saves that file.  Closing is done the same.

When you load a project, the only difference is that the TProject class should load it and then I was planning on having the OpenProjectClicked method run through the PRojectUnitInfo list and for everyone of them add it to the TSourceNotebook.  Some will appear visible and others will not depending on the state of them when they were saved.

When AddUnit needs to get the source code to parse and add a line I think it would be best to call a TSourceNotebook function like  GetSourceFromUnitname passing it the Unit's name and then a TStrings is returned (TSourceNotebook would get the source from a TSourceEditor.)  We could pass the address so changes are made on the TSourceEditor too.  Otherwise we could create a function called SetSourcefromUnitname and send it the Unitname and the TStrings.

Does that all sound good?  TSourceEditor really does all the saving and in order to cause that, MainIDE and TProject call functions in TSourceNotebook.

So, does that sound like a good way of handling it???

Shane


>>> cwhite at aracnet.com 01/29/01 11:22PM >>>

Shane Miller wrote:
> 
> OK  I've looked at the project code and it's a good start.  I have a few questions so I can help integrating it into the mianide.
> 
> Questions:
> 
> 1)  I assume there will be a TProjectUnitInfo class for each unit, including the project file.  If so, should the TProjectUnitInfo class hold a reference to a TStringList for the source or not?  See, if the AddUnit function is going to change the Project file then you will need to hold the source somewhere.  You can't be sure that it's ever been saved so the filename property could be blank.  This would mena that you would need to either have a reference to a stream or a TStringlist that holds the source.
> 


Yes, there will be a TProjectUnitInfo class for each unit. I hadn't
originally planned on having this class hold the source code for the
units. There is currently a TUnitInfo class in the global.pp file. I
thought that class managed units. But now that I think about it (I also
just looked at TUnitInfo), all the unit info should be in a single
class. So we can probably combine TProjectUnitInfo and TUnitInfo into a
single class. I think it should be called TUnitInfo. I also need to add
a property in the TProject class to hold the project source code. The
Source property would just be a TString.


> 2)  If we have the projectUnitInfo class hold the source, is it going to do the actual loading of the source or should the OpenProjectClicked load the details of the project, then run through all the units in and add them to the editor if they are visible.


[assuming we combine TProjectUnitInfo and TUnitInfo into TUnitInfo]

I think that TUnitInfo should know how to completely manage a unit,
including loading and saving it. TProject should be the same with
project files.

The OpenProjectClicked should just need to ask the TUnitInfo class for
the source code for a unit and add it to the editor. The TUnitInfo class
should not know anything at all about the editor. So OpenProjectClicked
would have to ask TProject for a list of units (UnitList property). Then
just walk through that list and read the Source property of each one,
putting the source code into a new editor.

TProject will need to know about TUnitInfo classes, so when a project is
loaded, it should call a method in TUnitInfo to make it load the source
code for all the units in the project.


>   I would guess that MainIDE would call the Project class to load the project.  Then it would run through the UnitList and see how many should be displayed in the editor.  While doing that it could fill in a variable in the Project class that holds each source file.  If the file's loaded into an editor, then the project's TSitrngList would point to the editor's.  That way when the editor's changes the one in TProjectUnitInfo would too.
> 


Exactly.


> 3) Should there be a TProject.Loaded function to see if a project is loaded or should I be looking at TProject.ProjectFile to see if it's <> ''?
> 


We could probably add a Loaded property that is a boolean to TProject.
The TProject.ReadProject method would set this property to true. It
would be false by default. I think that would be better than checking
the ProjectFile property for a null string. This should also be added


> 4)  How are we going to handle opening multiple projects?  :-)
> 


Well, this would actually be very easy. When the user selects Open
Project, a dialog box would open and allow them to select the project.
When they do, the TMainIDE class would create a TProject class, set the
Filename property and tell it to load the project. We could add a
ProjectName property to the TProject class. When TMainIDE opens the
project, it could add the ProjectName to a list of open projects. It
couldn't open two projects with the same name. But that makes sense
anyway because if they have the same name, there would be no way to
distinguish which one is which. 


> If I can figure out who's going to be responsible for loading the source and how TProject is going to modify it then I can integrate it with TSourceNotebook.
> 


I think I explained this above. If any of it doesn't make sense, let me
know.

I probably won't have enough time tonight to make these changes. I will
work on it some tomorrow evening when I get home from work.

BTW, this email address is my home email address. I don't see it until I
get home in the evenings. If you want an answer to anything sooner, you
can send email to my Yahoo email address. I can check that one from
work. It is soaro77 at yahoo.com.


> Shane
>

_________________________________________________________________
     To unsubscribe: mail lazarus-request at miraclec.com with
                "unsubscribe" as the Subject
    archives at http://www.miraclec.com/list_archives/lazarus