[lazarus] CVS Changes

[Shane Miller]

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

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