views:

113

answers:

3

I'm using Delphi 2009. My program has been compiling and running fine. I use Action lists and have them built into my program - although I haven't changed them in a while.

So today I go to simply add a new action to my ActionList in the normal manner that it is done. Without doing anything else, I now build and run my program and I get the following error:

[DCC Fatal Error] Userface.pas(1): F2092 Program or unit 'Userface' recursively uses itself.

I have done nothing to change any of the uses clauses. I can't find any instances of my Userface unit calling itself or calling another unit that calls Userface. I place potentially recursive calls in the Implementation section as they should be.

If I exit Delphi without saving, rebuild and run it, it runs fine. If I attempt again to add a new action to the action list, the fatal error happens again.

I'm at a loss to figure out what is happening. I would appreciate any help to figure out how to get around this.


Edit: After Uwe's answer, I double checked to make sure it was still happening. Sure enough, I did it again as I described in my comment to Uwe. After building, it happened again.

... But then, by accident under the Project Menu I missed picking "Build" and selected "Compile" instead. It compiled fine. Then I tried building and now the build works correctly. No Fatal Error! Everything seems fine for me again.

If I try to add another action and then build, the error comes up again. But if I compile, then I can build it successfully - so at least I have a workaround.

This must be some sort of a glitch. I don't know what happened. Does anybody know what this is or why it might be happening?


Followup. As Marjan states, it can occur in other circumstances, and one of those happened to me. So it is probably NOT directly related to the adding an action, which my question asks.

None-the-less, it is a relatively rare happening so far for me and has only turned into a minor annoyance. It may already have been fixed in Delphi 2010, and my ultimate solution will be when I next upgrade to Delphi 2011 or 12 once they add either 64-bit or multi-platform.

+1  A: 

Sometimes adding a component automatically changes the uses clause. This can either be done by Delphi itself or by a third-party plugin like ModelMaker CodeExplorer. You can use the history tab to quickly identify any changes.

Without the source nothing more say I can...

EDIT: Taken into account your additional info I suggest to check the project for

  1. cyclic dependencies
  2. units with the same name somewhere in the search path

For the cyclic dependencies you can use the free Unit Dependency Analyzer from ModelMakerTools. You can find the download link at the bottom of that page.

Uwe Raabe
Thanks for the idea, @Uwe, but I'm not adding a component. I'm double clicking on the ActionList component that's already on my form. Then I'm Clicking on my "View" category. Then I click on the "New Action" icon which adds "Action1" to my list of actions. I close the ActionList. Build Behold, and get the fatal error is the message list. And then ... (see my edit of my question) :-)
lkessler
You are adding a TAction which actually is a TComponent descendant. To see that my suggestion is not that far behind, try to add a sdandard action like TFileOpen. This will include StdActns into your uses clause.
Uwe Raabe
+1  A: 

If you are absolutely sure that you compile the right source (.dpr paths!) and the uses parts are the same, it might be that Delphi can eliminate mutual references if very simple or unused.

IOW maybe the compiler lets it pass if A and B import eachother, but one of them doesn't use symbols from the other. As soon as you start using symbols (because of previously dead code becoming reachable by selecting the action), it turns into a mutual reference conflict.

Marco van de Voort
@Marco: Well, I've been busily working on my program for the last few weeks and it's been building fine. It was only when I did this attempt to add an action that I encountered this problem.
lkessler
Comment out all code the action activates, and see if that changes. Anyway, don't forget about death code elimination when looking for changes.
Marco van de Voort
@Marco: I didn't implement any code. I just added the action. Never heard about "death code" before. Sounds scary.
lkessler
Dead (not death) code is code that is not compiled into the .exe because it is unreachable (aka smartlinking). Note that it is just speculation what you could test, to figure out what is going on. Not a foolproof explanation
Marco van de Voort
+1  A: 

As per request my comment as an answer.

Don't know why it may be happening, but if its any consolation, I have seen it happen in other situations as well. A build immediately following a change would fail, a compile, then a build would succeed.

What sometimes also helps in these situations is an explicit Save All before the compile/build.

I guess it may have something to do with timing and caching in the IDE. Possibly the compilation thread(s) that enable code-insight, error red lining etc are involved as well.

Marjan Venema
@Marjan: I just had it occur in another situation as well. Don't know exactly what's going on, but between my "compile" solution and your "save all" solution, it is turning into a relatively infrequent minor annoyance.
lkessler