🚀 go-pugleaf

"Cl�ment Doss" <cdoss@dhs.com.br> wrote in message 
news:486b8973$1@newsgroups.borland.com...

> I reached a point where setting fastmm for a project,
> messes the settings for another.

How so?  Please be more specific.

> Is there a better option to work with fastmm other then
> copying it for every project?

Not really.


Gambit 

Hi Gambit!

Remy Lebeau (TeamB) wrote:
> "Clément Doss" <cdoss@dhs.com.br> wrote in message 
> news:486b8973$1@newsgroups.borland.com...
> 
>> I reached a point where setting fastmm for a project,
>> messes the settings for another.
> 
> How so?  Please be more specific.

When fine tuning the {$DEFINES} (I'm using Jeremy North interface to set the 
options). But all I'm doing in fact is set a "global" setting for fastmm4, and all my 
projects will be compiled using this settings. For example: I set FullDebugMode and 
LogMemoryLeakDetailToFile. Some projects will crash because the debug DLL is not in 
the program path. And they shouldn't, because those projects are fine. So if I don't 
remember to change the settings back..
Another case: I'm using Fastmm to share information between the main application and 
DLLs. So I must set ShareMM for this project group. But when I get to another project 
group, I must change the settings back. When debugging such project I really change 
the configuration a LOT. I just don't trust myself returning all the settings back.

In fact 3 large projects should have their "own" copy of fastmm. That's what I did. I 
copied FastMM with the correct settings in the project folders. This way, each one 
get its own version/setting of fastmm. The other smaller projects can have the 
"global" version of Fastmm.

> 
>> Is there a better option to work with fastmm other then
>> copying it for every project?
> 
> Not really.

I just figured that there's so many nice features, that I am must probably missing 
something. Oh well. Not a problem. I'm just happy with fastmm and just would like to 
get the most of it. :-)


Thanks

"Cl�ment Doss" <cdoss@dhs.com.br> wrote in message 
news:486bd90a@newsgroups.borland.com...

> When fine tuning the {$DEFINES} (I'm using Jeremy North interface
> to set the options). But all I'm doing in fact is set a "global" setting 
> for
> fastmm4, and all my projects will be compiled using this settings.
> For example: I set FullDebugMode and LogMemoryLeakDetailToFile.
> Some projects will crash because the debug DLL is not in the program
> path. And they shouldn't, because those projects are fine. So if I don't
> remember to change the settings back..

FastMM's full debugging features require the DLL.  If you don't want the 
settings to effect other projects, then each project needs its own .inc file 
rather than sharing a common file.  Then you can tweak the settings all you 
want on a per-project basis.

> Another case: I'm using Fastmm to share information between
> the main application and DLLs. So I must set ShareMM for
> this project group. But when I get to another project group,
> I must change the settings back.

Again, because you are sharing a single settings file amongst multiple 
projects instead of giving each project is own local file instead.

> In fact 3 large projects should have their "own" copy of fastmm.

That is what you have to do.


Thanks 

> I reached a point where setting fastmm for a project, messes the 
> settings for another. Is there a better option to work with fastmm other 
> then copying it for every project?

Yes. Disable all the options in FastMM4Options.inc that will differ 
between your applications. Then define the options you need for each 
application in the "Project -> Options -> Directories/Conditionals -> 
Conditional Defines" dialog. That is what I do.

I've added a new option recently, FullDebugModeInIDE, which causes 
FastMM to run in FullDebugMode when it is being run inside the IDE and 
to not install itself outside the IDE (which means the standard memory 
manager is used outside the IDE, which is essentially also FastMM4 since 
D2006). I find that quite useful, since you don't have to recompile 
before you distribute EXEs - you can use the same EXE for debugging and 
deployment.

Regards,
Pierre

Pierre le Riche wrote:
>> I reached a point where setting fastmm for a project, messes the 
>> settings for another. Is there a better option to work with fastmm 
>> other then copying it for every project?
> 
> Yes. Disable all the options in FastMM4Options.inc that will differ 
> between your applications. Then define the options you need for each 
> application in the "Project -> Options -> Directories/Conditionals -> 
> Conditional Defines" dialog. That is what I do.

Wow! That's just great! I will try that one for sure!

> 
> I've added a new option recently, FullDebugModeInIDE, which causes 
> FastMM to run in FullDebugMode when it is being run inside the IDE and 
> to not install itself outside the IDE (which means the standard memory 
> manager is used outside the IDE, which is essentially also FastMM4 since 
> D2006). I find that quite useful, since you don't have to recompile 
> before you distribute EXEs - you can use the same EXE for debugging and 
> deployment.

Any chance that us, poor mortals, can have a "look" in that new feature? :D

> Any chance that us, poor mortals, can have a "look" in that new feature? :D

Ok, I've uploaded 4.84 to SourceForge.

I still have a "to do" list as long as my arm. Unfortunately work 
pressure and the demands of 2 toddlers means I don't often find time to 
work on FastMM. :-(

Regards,
Pierre