- Removed global unit from uses clause of project.pp, main.pp, compiler.pp and idecomp.pp.
- Removed and commented all references to TUnitInfo in TMainIDE class.
- Renamed TProjectUnitInfo to TUnitInfo.
- Added Source properties to TUnitInfo and TProject classes.
- Added WriteUnit and ReadUnit functions to TUnitInfo class.
- Added code to TProject class to save and load units when the project is saved and loaded.

Note: Currently, the Filename property must be set in the TUnitInfo class before the unit is saved. It does not currently check this check automatically. I still need to add that code. This is also true of the TProject class except the property that must be set in it is ProjectFile.

The global unit is no longer referenced in any of the files. That unit can now be removed from CVS unless someone wants to save it for the code it contains.

Curtis

Hi

some changes:
- Removed old LM_InvalidateRect
Since we have the API InvalidateRect we don't need this one

- did some cleanup in old code
+ added some comments on gtkobject data (gtkproc) I wanted to update the counterpart of InvalidateRect (LM_Paint) and family by adding the "invalid rect" Therefore I needed a new gtkobject data member and that resulted in a somewhat "cleaner" solution and before I start with that some cleanup was needed.

Marc

you wrote

Once I figure out how these classes are to work together, I will look into getting fpcmake involved.

The fpcmake interface can be adjusted to your needs for getting it working wel with TProject. It's still in development. And i'm not a classes expert yet.

Peter

Sorry I ment vclglobals.ppu

Marc

Now "vclglobals.ppu" is in "lcl/units", but it happens an error:

Panic : Internal compiler error, exiting.
allunits.pp(29) Fatal: Internal error 9999
make[2]: *** [allunits.ppu] Error 1
make[2]: Leaving directory
`/home/luis/FPC/lazarus/lazarus/components/synedit' make[1]: *** [synedit_all] Error 2
make[1]: Leaving directory `/home/luis/FPC/lazarus/lazarus/components' make: *** [components_all] Error 2

Now both lcl as components should be made. Check the components/units and the lcl/units dir. Marc

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.

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. 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.

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

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

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.

Shane

>> 01/29/01 01:05AM >>>

- Created the TProject class.
- Created a TProjectUnitInfo class to store project information specific to each
unit.
- Moved Project Options and Compiler Options menus to the Project menu.
- Added Project property to the TMainIDE class to allow other units to access the
Project information. Maybe this variable should be moved to the Globals unit. I
still need to think more about that.

Note, the TProject class is not all connected to the IDE yet. But it does all
compile OK now. Also, since the compiler options were moved to the project file, it
no longer works until the project options are being saved and restored.

TODO still:
- All TODO's commented in the Project.pp file.
- Create a new .lpr file from a template (select template from dialog as in Delphi)
and a new project when New Project menu item is selected.
- Add ability to add units to the main project file (.lpr). This needs a parser.
- Add ability to remove units from the main project file. This needs a parser.
- Add functionality for Open Project menu item.
- Add functionality for Project Save and Project Save As menu items.
- Create Project Options dialog.

Curtis

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

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 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

Shane

Problems with this update:

Compiling allunits.pp
Compiling synedit.pp
lcllinux.pp(68,11) Fatal: Can't find unit VCLGLOBALS make[2]: *** [allunits.ppu] Error 1

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

>> 01/29/01 11:22PM >>>

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 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

Shane

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

Under Windows "vclglobals.ppw" is in the directory "lcl/units". Under Linux "vclglobals.ppu" is in the directory "lcl". I copied "vclglobals.ppu" to the directory "lcl/units" and now compiles well.

When attempt to put some component in the designer leaves with this error:

An unhandled exception occurred at 0x080B6C12 :
Access violation
0x080B6C12
0x00000001
0x403B0C14

must be nil
An unhandled exception occurred at 0x0806FF99 :
Access violation
0x0806FF99
0xBFFFE33C
0xBFFFE350
0x00000001
0x00000000
0x08137A10

Marc,
Unit VCLGLOBALS is in the directory "lcl".

Can you take a look at the integration with the new fpcmake available in the fpc/utils/fpcm/ directory in CVS.

isn't it located in lcl/units ??

Marc

This is a common bug in the fpc. It has problems mixing different modes. Add a line
{$mode objfpc}
to <lazarus>/components/synedit/allunits.pp

Mattias

Mattias Gaertner wrote

This is a common bug in the fpc. It has problems mixing different modes. Add a line {$mode objfpc} to <lazarus>/components/synedit/allunits.pp

I forgot that (copied from mwedit). It's in CVS now

Marc

Shane Miller wrote

It crashes when you drop someting on the form?

Yes.

How are you going about that? Are you first selecting New Form then dropping a control?

Yes, normally.

Which control?

Anyone.

Once I figure out how these classes are to work together, I will look into getting fpcmake involved.

Thanks
Shane

>> 01/29/01 10:30AM >>> 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.

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.

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.

Can you also take a look at the fpcmake code to integrate that in the TProject and vice versa. I want also to add source file info and dependency info to the Makefile.fpc.

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

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.

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.

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.

Can you also take a look at the fpcmake code to integrate that in the TProject and vice versa. I want also to add source file info and dependency info to the Makefile.fpc.

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

+ From:
+
+ Marc Weustink wrote:
+ >
+ > At 16:18 29-01-01 -0300, Luis R. Hilario wrote:
+ > >Marc Weustink wrote:
+ > > >
+ > > > At 23:44 28-01-01 -0300, Luis R. Hilario wrote:
+ > > > >
+ > > > >Problems with this update:
+ > > > >
+ > > > >Compiling allunits.pp
+ > > > >Compiling synedit.pp
+ > > > >lcllinux.pp(68,11) Fatal: Can't find unit VCLGLOBALS
+ > > > >make[2]: *** [allunits.ppu] Error 1
+ > > >
+ > > > isn't it located in lcl/units ??
+ > >
+ > >Marc,
+ > >Unit VCLGLOBALS is in the directory "lcl".
+ >
+ > Sorry I ment vclglobals.ppu
+ >
+
+ Under Windows "vclglobals.ppw" is in the directory "lcl/units".
+ Under Linux "vclglobals.ppu" is in the directory "lcl".
+ I copied "vclglobals.ppu" to the directory "lcl/units" and
+ now compiles well.
+
+ When attempt to put some component in the designer leaves with this
+ error:
+
+ An unhandled exception occurred at 0x080B6C12 :
+ Access violation

I guess you got a currupt/wrong version of vclglobals.ppu.

Do a make clean. Make sure that there is no .ppu or .o left i.e. in you lazarus dir:
find . ( -name '*.ppu' -or -name '*.o' )

or to remove them as well:
   find . ( -name '*.ppu' -or -name '*.o' ) -exec rm {} \;

Afterthat do a make components. Now both lcl as components should be made. Check the components/units and the lcl/units dir.

Marc

It crashes when you drop someting on the form? How are you going about that? Are you first selecting New Form then dropping a control? Which control?

Shane

This sometimes happens do a make again (without cleaning)

Marc

I just now took a look at the TUnitInfo class. I don't understand what its purpose is/was. It looks like it has methods to actually manage editing the source code (like adding lines of code, etc.). Is all that still necessary? Are we using it any more? I don't see any place where we are "actually" using it. It exists in TMainIDE, but it doesn't look like it is being used. If we are not using it, then I suggest we dump it.

I would still like to rename the TProjectUnitInfo class to TUnitInfo. I think that describes the class better. I also need to add a Source property to it and to the TProject class. I will add these for now until I hear from someone more about what all those methods are in the current TUnitInfo class.

Curtis

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

- Created the TProject class.
- Created a TProjectUnitInfo class to store project information specific to each
unit.
- Moved Project Options and Compiler Options menus to the Project menu.
- Added Project property to the TMainIDE class to allow other units to access the
Project information. Maybe this variable should be moved to the Globals unit. I
still need to think more about that.

Note, the TProject class is not all connected to the IDE yet. But it does all
compile OK now. Also, since the compiler options were moved to the project file, it
no longer works until the project options are being saved and restored.

TODO still:
- All TODO's commented in the Project.pp file.
- Create a new .lpr file from a template (select template from dialog as in Delphi)
and a new project when New Project menu item is selected.
- Add ability to add units to the main project file (.lpr). This needs a parser.
- Add ability to remove units from the main project file. This needs a parser.
- Add functionality for Open Project menu item.
- Add functionality for Project Save and Project Save As menu items.
- Create Project Options dialog.

Curtis

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

>> 01/30/01 09:28AM >>>

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 with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

Hi,

I added synedit to the components in the Makefiles and removed the option to switch beteween the two version of mwedit. Now both mwedit and sysedit are created, so when time comes one can change the code to use either of them.

Marc

The error has not been solved.
Now in line 34 because that is the last line (allunits.pp).

I executed "make" twice and worked, but when attempt to add something to the form:

An unhandled exception occurred at 0x080B76E2 :
Access violation.............