"Application" global variable not recognized

Question

I work on a large project in Delphi 5. Today, after merging two branches of the app together, one of the hundreds of units, UnitMain (the main form's unit, would you guess) stopped recognizing the Application global.

This is a rather bizarre problem - I could get the program to compile by defining Application: TApplication in UnitMain, and setting that to the Application from our .dpr project file, but that leads to an access violation, which isn't much of a surprise with Application being the special thing it is.

I'm hoping someone has faced the same problem before, or knows enough of Delphi VCL's inner workings to help me out here.

unit UnitMain;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  Menus, ComCtrls, StdCtrls, cxButtons, ExtCtrls, IniFiles, ShellAPI,
  LMDControl, LMDBaseControl, LMDBaseGraphicControl, LMDGraphicControl,
  LMDScrollText, cxControls, cxContainer, cxListBox, Psock, NMFtp, db, DBTables,
  FileCtrl, Configs, cxHint, DSetFunc, OleCtrls, DsInformation,
  InterAppComm, ActnList, ADODB, OleServer, CRAXDRT_TLB;

The exact error is that the compiler does not recognize Application in this unit. For example, for a Application.ProcessMessages; call, the error is "Object or class type required". None of the other units has this problem.

Thibault

Answer 1

I think it is most likely that you have two symbols called "Application" in scope, and the one from the Forms unit isn't the active one. Make sure the Forms unit in the uses list comes after any prior unit that contains a symbol called Application.

But, you need to provide more information. The exact error messages, etc.

Moitoso

Well, I'll be damned, this was actually it - Changing "Forms" to be the last included unit brings the correct Application var into scope. The Crystal Reports unit might be the one defining another Application, since that's one of the few things I've lately added. – Thibault

Another option would be to explicitly reference Forms.Application – Spacious

Answer 2

I'm pleased to see everythings working now, but I'll add that another way to solve such problems, especially if you don't want to rearrange your uses clauses is to prefix the unit name to whatever you want to use, eg.

Forms.Application.ProcessMessages;

Ethelstan

Answer 3

What units are in the uses clause at the top of the file? Application comes from the "Forms" unit.

eg.

unit MyUnit;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms;

Thus