qoy: unit with empty interface section

Never mind you can't use that either unless you have something in the interface section, whether it be a var or another unit declared in the uses clause.

Shane

You got my stumped!

Shane

unit Strange;

interface

implementation

uses unit1;

begin
  // do something here;
end.

Yup, good thinking geobul, i forgot about that....

then you could also use the initialization & finalization section as well

Shane

unit Strange;

interface

implementation

uses unit1;

procedure DoSomething(MyObject: TMyObject);
begin
 //
end;

initialization
begin
 myObject:= TmyObject.Create;
 DoSomething(MyObject);
end;

finalization
  myObject.free

robert, you remembers me to restart qow and qom :-))

coming soon
- picture fade effects (qow)
- swarm simulation logic (qom)

meikl ;-))

qow available :-))

Hmm... wonder if someone will come up with Question of the Century and Question of the Millenium? ;-)

Sorry, i should have told that uses needs to be allowed, but of course the uses in the implementation section is good enough.
So the question is effectively answered by geobul and shaneholmes. I think i split the points.

I came across this interesting Delphi trick when i wrote a plugin system for a component and ended up with a unit only
exporting a string const.
The bulk of the work was done by calling a register function in the initialization section. So Strange is still used in
another unit, but only import into Strange happens.

If you Include a file with the {$I} directive, you can do this.

I do not consider including a file into the interface section an empty interface section.

My gut feel is that you don't have to worry about clean-up.  Interfaces are cleaned up automatically.  Therefore, your code is a little simpler and maybe quicker to develop.

interface <> interface section

geobul, you will get points also

Thanks Robert :-) The question was interesting and forced me to remember something well forgotten - that a unit could have begin..end. part.

I plan to write a text about the very fringes of Delphi.
Currently i have "empty interface section" and "private constructor". Anyone knowing other tricks?

What about this OOP technique:

type
  TAncestorClass = class(TObject)
    procedure Bar; virtual;
    procedure Foo; virtual;
  end;

  TDescendantClass = class(TAncestorClass)
    procedure Bar; override;
    procedure Foo; reintroduce;
  end;

procedure TAncestorClass.Bar;
begin
  ShowMessage('Ancestor.Bar');
end;

procedure TAncestorClass.Foo;
begin
  ShowMessage('Ancestor.Foo');
end;

procedure TDescendantClass.Bar;
begin
  ShowMessage('Descendant.Bar');
end;

procedure TDescendantClass.Foo;
begin
  ShowMessage('Descendant.Foo');
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  aClass: TAncestorClass;
begin
  aClass := TDescendantClass.Create;
  try
    aClass.Bar; // calls TDescendantClass method - native behaviour
    aClass.Foo; // calls TAncestorClass method - not that native but very useful
  finally
    aClass.Free;
  end;
end;

Regards, Geo

Robert,

How "fringy" do you want to get?  You can solicit ideas from a lot of sources.  I'm not sure that an EE Delphi Forum question is an appropriate location for such submission.  However, you might use EE to feed some other collection mechanism for your article as well as Delphi user groups and bulletin boards.

If you grouped your solicitations into categories, you might post many EE Delphi Forum questions and distribute the answers.  The problem you will face is that your questions will eventually 'age' off the first page.  So you might have to post weekly reference questions.

Maybe you can ask the Delphi Forum page editor to set aside some static space for your catetory questions.

>Maybe you can ask the Delphi Forum page editor

here i am, still listening :-))

meikl,

Although this isn't my question, I might better explain this "fringy" idea of mine. :-)

Robert is interested in collecting ideas from Delphi developers that either aren't well known/understood or that are infrequently used (but situationally useful).  Rather than treating this research as a common question, create a special static place on the Delphi Forum page for his question(s).  They will have a limited lifetime and will be closed and removed within an agreed upon period.  I am thinking along the lines of the current page sections you have for "Hot Solutions".

In addition, Robert might organize a team of Delphi developers to glean "fringy" ideas from the PAQ pool.

It just seems to me that such a project wouldn't readily fit into the current Delphi Forum structure (question type) and that the aging of questions would reduce the visibility of the questions and, thus, reduce the number of submissions.

BTW...a few years ago, I organized a team of user group members to create Delphi quiz questions and pointed them to the Delphi PAQ pool.  We divided the range of questions to prevent overlap.

============================
I would also think that a project to consolidate and categorize discussion threads from the PAQ pool would be quite useful.  I'm sure there are many duplicate questions and the Google search engine could produce better results if we were to supply some classification meta data to the PAQ pool.

I actually suggested "sticky postings" to CS before (erm... 2 years ago?)... but no news from 'em.

Sounds good to me :-)

well,
good suggestions,
but i cannot not free handle designissues or
specific sections.

i will see, if a subtopic can be esatblished,
like "couriouses and trickys around delphi"

meikl ;-)

We might become an open-source, collaborative gold mine for the Delphi developer community.  I have ideas, but don't want to overly influence this.  I'm too much of a Delphi novice.

I am a member of Project Jedi (namely the JediVCL).
I think we ARE already an open-source, collaborative gold mine for the Delphi developer community :-)

BTW there is a really bad trick in it where properties are added dynamically at runtime!

robert,

I had JEDI in mind when I wrote my comment.  I've used some of the JEDI API wrappers and submitted an item to the project.  Project JEDI is quite good and I'm glad it exists.  However, the Delphi Forum PAQ and the EE Delphi community have a great unrealized potential (IMHO).  

Soapbox time...
What are the biggest differences between Delphi and VB?
1. marketshare
2. quality of online help
3. background resources - KnowledgeBase and MSDN

If I have a VB problem, I can usually find a good answer at microsoft.com.  I can't say the same if I have a Delphi problem and turn to borland.com.  Developer communities like EE are very important to the Delphi developer community.  However, I think there is enough material at EE to create a DelphiKB or more.  Such a project doesn't have to be confined to EE, but can sure start here.

I would suggest that the initialization and finalization are the only really useful bits since nothing can access the implementation otherwise.  This could be used to force certain steps to happen within an application without necessarily putting these startup and shutdown calls within the individual units themselves.  This would have some advantages that come to mind right away:

1.  Used correctly, this puts the initialization and finalization in one location, guaranteeing execution order.

2.  This allows the units being called by this no-interface unit to be more compartmentalized way -- they could be initialized in an application specific way without prior knowledge of how the application uses them.  

An example:
====================================================
unit AppToolboxInitialization;

interface

// This unit is used to do application-specific initialization of the toolbox components.  It does not provide
// any definitions that are used by the rest of the application.  It's sole purpose is to perform operations
// to initialize the toolbox without requiring a call from the application itself, thereby relieving the programmer
// form remembering this step.

implementation

Uses
  TBEnvironment,
  TBDataAccess,
  TBAppClassFactory,
  TBCOM;

procedure InitToolbox;
var
  SysMetrics : TtbMetrics;
begin
  CollectParams;
  CollectMetrics( SysMetrics );
  ResetAppMetrics( SysMetrics );
  ConnectionPool;  // referencing this method causes the fConnectionPool soliton variable to be instantiated.
  InitCOMFacility( DBConnectionParams, DriveList );
  InitClassFactory( DBConnectionParams, SysMetrics );
end;

procedure FinalizeToolbox;
begin
  FinalizeClassFactory;
  FinalizeCOMFacility;
  FinalizeConnectionPool;
end;

initialization
  InitToolBox;
finalization
  FinalizeToolbox;
end;