-1

I'm in charge of maintaining some legacy code at my office (Pascal) due to it's limitations, I've written a delphi dll to access excel using TExcelApplication.

The dll works perfectly at the office, the machines are running Microsoft Office 2010, Windows 7 32-Bit and 64-Bit. The client is using Novel Workstations, Windows XP, Microsoft 2007.

The dll gives a breakpoint exception when encountering the TExcelApplication.Connect; command.

Other than the differences that I've mentioned, the scenario's are exactly the same.

Are there any limitations regarding accessing Microsoft Excel on a Novel Workstation, alternatively, is there a better way to access Excel documents?

Note: I just want to read from the Excel document, it spans multiple rows, columns and spreadsheets, the source Excel documents are *.xls 2007 documents.

It's primary function was to enable automated reconciliation against the Excel document.

Here is a snippet of the library code

library MyLibrary;
uses
  SysUtils, Classes, Variants, Dialogs, StdCtrls, OleServer, ExcelXP, Windows;
Type
  PString=String[254];

Var
  ExcelObj : TExcelApplication;

Procedure XLSOPEN(THENAME:PSTRING;VAR Reslt:PSTRING); stdcall;
Begin
  If FileExists(THENAME) Then
  Begin
    ExcelObj := TExcelApplication.Create(nil);
    ExcelObj.ConnectKind := ckRunningOrNew;
    ExcelObj.Connect;

    If ExcelObj=nil Then
    Begin
      Result := 'Error : EXCEL couldnt be started!';
      Exit;
    End Else
    Begin
      Result := 'Successful';
      Exit;
    End;
  End Else
  Begin
    Result := 'Error : File '+THENAME+' does not exist!';
    Exit;
  End;
End;

Exports XLSOPEN Name 'XLSOpen';

Begin
End.
RRUZ
  • 134,889
  • 20
  • 356
  • 483
Dwayne Hinterlang
  • 306
  • 3
  • 14
  • 3
    I think you need to give more detailed and precise diagnostics of the error. – David Heffernan Jan 17 '12 at 15:31
  • Disclaimer: Haven't worked with Novell since the early 90's. I do know Novell as a server OS was way more restrictive than Windows was (and is). It may be that Novell simply does not allow COM/OLE automation, or it needs to be specifically "turned on". Which is what you are using here. If nothing like that, help yourself get help by getting detailed error information by adding try except's and logging the error information such as the exception message and the LastOSError code (and message) and providing it here as David already suggested. – Marjan Venema Jan 17 '12 at 19:05
  • @Marjan, it's not Netware. The application runs on the Windows machine, and the "Novel(sp) workstations" are just using the Novell Netware Client as the networking drivers. COM works fine (DCOM across machine boundaries, if you enable remote COM) with Netware. Excel does have to be installed on the workstation running the code, however, just like it would in a Windows network. (We're running Netware at my office on a couple of servers still.) – Ken White Jan 17 '12 at 21:03
  • @KenWhite: thanks for the information, always like to learn. – Marjan Venema Jan 18 '12 at 08:02

1 Answers1

1

You need to add ActiveX to your uses list and use CoInitialize(nil); to initialize the ActiveX components. The reason for this is because Application->Initialize initializes the components, now that it's a dll, you have to manually initialize the component when it's loaded and use UnCoInitizlise; when unloading the dll.

USES ActiveX, Windows;

INITIALIZATION
  CoInitialize(nil);
FINALIZATION
  UnCoInitialize;
Dwayne Hinterlang
  • 306
  • 3
  • 14