-2

I have seen other questions with this same problem on XE Forums, but still no answer. I run my application from with the XE IDE and I get an EOleSysError - 'The system cannot find the path specified'.

But, I can go out to explorer to the same directory and run that same app outside the IDE and it runs fine. No errors. All of my assemblies are located in the build directory of the application, so I'm not relying on GAC or anything, just directory the executable is in.

Is this a known bug with XE and Windows 7 x64?

Is this a path problem? Environment variable issue? It almost seems like the IDE is running my exe from another directory, but the exe is only being compiled in one place.

Any help here would be appreciated.

Thanks,

Rick

user3067455
  • 1
  • 1

1 Answers1

3

It's not a bug at all. The debugger is catching the exception, and letting you know about it before it passes it to the exception handler in the code. It's working by design, letting the developer know that the exception happened.

If you want to avoid this happening, you can do one of a few things:

  • (Easiest) Set a breakpoint on the line immediately before the exception is raised. Right-click the line, and choose Breakpoint properties from the context menu. Click the Advanced... button, and then uncheck the Break checkbox, and check the Ignore subsequent exceptions checkbox, and then click OK to close the dialog. Set a breakpoint on the line after the exception is raised, and repeat the process above, except this time check the Handle subsequent exceptions checkbox. I say this is easiest because you can disable it to break on the exception simply by disabling the breakpoints, and remove it entirely by just removing the breakpoints, and you get a visual indicator that something is different for that block of code.

  • Disable IDE error handling for all EOleSysError exceptions, from the Tools->Options menu, find Debugger Options->CodeGear/Embarcadero Debuggers->Language Exceptions, and add EOleSysError to the Exception types to ignore dialog, and make sure the item is checked. It's the way Indy's exceptions are prevented from stopping the debugger, for instance.

  • Just click the Continue button in the exception dialog, and let the code keep running. This gets a little annoying sometimes, such as when you're running code in a loop, and something in the loop is raising the exception; you keep getting the dialog over and over again.

Ken White
  • 123,280
  • 14
  • 225
  • 444
  • I understand that i have an exception. My question really is why am i getting an exception at all. I don't get the exception outside the IDE, only inside the IDE. – user3067455 Dec 04 '13 at 21:55
  • 1
    @user Presumably your code provokes it. Only you can see your code. Are you really asking us to explain why your code provokes an exception and at the same time denying us sight of that code? – David Heffernan Dec 04 '13 at 22:41
  • 1
    I explained that in my very first paragraph. You're getting the exception because it's happening. Code that normally handles it with a `try..except` block prevents you from seeing it outside the IDE; when you're running inside the IDE, the **debugger** catches it in the `try` portion, tells you, and then if you choose to continue lets the normal `except` block handle it. So you get one behavior **in** the IDE (you have a debugger involved), and a different behavior **outside** the IDE, where there is no debugger. – Ken White Dec 04 '13 at 22:47
  • 1
    It might be interesting to know in that context, that there is a first phase and a second phase. Any attached debugger get's a first chance and (typically) shows it. If the exception is not handled within the code, then the debugger gets a second chance. Without a debugger, you then get well-known "an error occurred in your application" dialogue in that latter case, and the app will terminate. See also http://stackoverflow.com/questions/4070040/first-chance-vs-second-chance-exception – JensG Dec 05 '13 at 00:19
  • I'm not asking anyone to debug my code as I really don't think it has to do with the source code. The exception that I am getting is the generic COM exception when it thinks your COM object isn't registered. Other users have had this same problem with Delphi XE, where you run inside the IDE and get COM errors, but run outside the IDE and it runs fine. I'm just looking for someone who might have ran across this problem and knows the work around or a fix. It has to be a delphi setting. It acts like delphi cannot see the DLL's in my output directory. It works fine in Delphi 2006. – user3067455 Dec 05 '13 at 15:39
  • Ken, also... just fyi, I can click continue all i want and the com object never gets created. So, my assumption is that this exception never fires outside the IDE, but only inside the IDE. Outside the IDE, the COM server is started, the object in instantiated and my program works flawlessly, just like when i am running inside the Delphi 2006 IDE. – user3067455 Dec 05 '13 at 15:43
  • 2
    When it thinks, the object is not registered ... well, either the object is registered, or it is not. There is no in between. What may happen (and I have seen this), that the environment of the debuggee is different when running from within the IDE. Maybe it is a missing dependency, so the COM server could not be loaded, because search paths are slightly different. If I were you, I would fire up SysInternals ProcessMonitor and take a look at what happens behind the scenes. – JensG Dec 05 '13 at 18:52
  • Thanks for the insight JensG. Your help was constructive, unlike the snarkiness of previous comments. I am going to investigate whether it could be an environment variable issue, etc. – user3067455 Dec 06 '13 at 15:58