[lazarus] CVS Changes

Curtis White cwhite at aracnet.com
Wed Jan 31 00:04:56 EST 2001


I think we should do it the right way now. Otherwise, we might end up
with a mess later that will be much more difficult to fix. I will try to
combine TProjectUnitInfo and TUnitInfo into a single class called
TUnitInfo tonight. That class will be included in the TProject where
TProjectUnitInfo is now.

It seems to me that it shouldn't be all that difficult to fix
TSourceEditor to just call the proper functions in the TUnitInfo and
TProject classes to load and save the units. If you want, I can take a
look at TSourceEditor as soon as I get TProjectUnitInfo and TUnitInfo
combined into a single class (probably not until tomorrow evening).


Curtis


Shane Miller wrote:
> 
> Maybe you are right but it's currently working this way.  Do we want to take the time to create a new UnitInfo class and redo TSourceEditor or should we just use it and discuss changing it later?
> 
> Shane
> 
> >>> cwhite at aracnet.com 01/30/01 09:28AM >>>
> Shane Miller wrote:
> >
> > 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???
> >
> 
> I don't understand why TSourceEditor has to be the one to do all the
> saving. It makes more sense in OO terms for the TUnitInfo (or
> TProjectUnitInfo) to know how to save and load its own units. Then
> TSourceEditor would just know how to interact with TUnitInfo. It
> shouldn't know anything at all about loading or saving units. It should
> just call a function in TUnitInfo to tell it to go ahead and load or
> save the unit. Then TUnitInfo knows how to do that. TSourceEditor would
> just get or set the TStrings property in TUnitInfo.
> 
> I really think that TProject and TUnitInfo should not know anything at
> all about a TSourceEditor component. They should only know how to manage
> projects and units. TSourceEditor should know how to work with TUnitInfo
> and TProject classes and get what it needs from them.
> 
> Curtis
>






More information about the Lazarus mailing list