How to disable warnings from given unit without modifying that unit?
Asked Answered
T

3

8

So I am including in my unit some other units and after building application I receive a huge amount of warnings from those units. The amount is so large that I'am having problems in finding my own warnings on the list. ;-)

Is there some compiler directive which would allow me to turn those warnings off? But please note, that I don't want to modify those units in any way. I would like to achieve something like this:

unit MyUnit;

interface

uses
  UnitA, {$WARN EMIT_WARNNIGS OFF} UnitB, {$WARN EMIT_WARNNIGS ON} UnitC, UnitD.

implementation

uses
  UnitE, {$WARN EMIT_WARNNIGS OFF} UnitF, UnitG, {$WARN EMIT_WARNNIGS ON} UnitH.

This is an imaginary compiler directive which I would like to have, or maybe it exists and I don't know about it?

Thanks for your time.

Tila answered 4/7, 2011 at 14:1 Comment(4)
Just a guess, have you tried uses ..., {$Warnings Off} UnitB {$Warnings On}, ...?Jumna
Counter-question: Why dont you want to address these warnings and... ugh... khm... fix them?Argument
Fix it or Boor it! Believe me, you don't want to use warning bloated code if it can in any way be avoided. You can count on a variety of errors and access violations and plenty of your time wasted.Bamboo
just add {$WARNINGS OFF} to each miscreant and be done with itKennakennan
S
8

There is a compiler directive to turn warnings off, but this can only be set in either project options in which case it applies to all units, or in a unit itself in which case it applies to that unit alone.

So, you're left with a few options.

Unrealistic option that does exactly what you ask:

So the only solution would be to disable warnings in your project and then enable them in all your own units using that directive.

Easiest and most realistic option:

Compile the units once and only use the DCUs by removing the source from your library path. That's easiest if you do not want to edit them anyway.

You can still add them in your browsing path which is different from the library path. In that case, the DCUs are used, but Delphi can still find the sources, so you can still navigate them whilst debugging.

Small advantage is that building your project is faster too, because these units don't need to be recompiled on each build.

Best option:

Stop using those units at all. Units with so many warnings are inferior software and can cause serious problems.

Other solutions:

  • Set aside your wishes of not modifying the units and add the compiler directives to those units anyway
  • Solve the warnings
Shul answered 4/7, 2011 at 14:13 Comment(5)
+1 for the "set aside your wishes...", because that's what I did when faced with this problem. The most important issue when modifying 3rd party source is that you might have problems upgrading later, but a single {$WARNINGS OFF} doesn't create any problem because it doesn't affect the actual code in the unit.Decoupage
Thanks for the tips, I am marking this as an answer cause you gave me a broad spectrum of choices.Tila
Just to clarify, when you say source path do you mean Browsing Path ? Delphi pathsChiquitachirico
@outlier Yes indeed. I've updated the answer. Thanks!Shul
It's sad to say that using VclStylesUtils (extremely common) is producing a load of hints. The ideal solution would be to fix them, but then if I update that source, it would be un-fixed :-/Calcimine
C
4

I use Delphi 7 and here's how I do it...

Do not include the unit it the project .dpr or this will not work, add the folder of the unit on the search path of the Project Options.

Then in every unit you use it, use these compiler directives:

  uses
    {$WARNINGS OFF}{$HINTS OFF}
    TheUnitHere;
    {$WARNINGS ON}{$HINTS ON}
Coonskin answered 10/7, 2017 at 10:18 Comment(2)
still use delphi 7?Sumo
That is a nice tip, +1.Tila
B
2

No, I don't believe there is such a directive.

The only way I have found to achieve this, is to

  • compile everything
  • put the dcu of the offending unit somewhere where the compiler will find it
  • make sure the dcu is found BEFORE the source for that dcu, or make sure the source cannot be found by the compiler

This will ensure that the pas is not compiled so you won't be swamped by the warnings from the offending units.

It is an approach I often take with library units (which we always compile from source) when I do not want the debugger stepping into them. I compile the release configuration (debug = off) then pick up the dcu's of the units that I do not want to step into and make sure that they are found by the compiler before their corresponding pas files.

One caveat: make sure that when you (need to) work on the offending units, the dcu gets removed, or you will be in for a lot of confusion. GExperts' "Clean directories' can help with this.

Barca answered 4/7, 2011 at 14:10 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.