Exporting application data to excel works for some users but not others

Question

I have a legacy application (Delphi 5) that allows the user to export data to excel. To the best of my knowledge, this application worked for ALL users prior to Office 2013. We have recently begun rolling out Office 365/2013 - after getting O365 some users are no longer able to export the data to Excel. As near as we can tell, for these users NOTHING happens (Excel doesn't get focus, no new worksheets / tabs are added to existing instances, Excel doesn't start if it isn't running). Other users who have gotten O365 seem to have no trouble with the application.

A couple months ago, we had a user experience this problem after receiving Office 2013 (non O365). Before any coding / significant research occurred, the user was given a different hard drive (I think it was her previous hard drive, but am not 100% sure) and, voila, everything worked for her. This leads me to believe it may be a registry setting or some other configuration issue.

Is anyone aware of any registry settings / application configuration settings that could cause / resolve this, do we have to re-write the logic to export the data, or is there something else that I'm not thinking of?

For reference, here is the code snippet that performs the export to Excel (I added the 'ExcelApplication1.Connect;' as shown here http://www.djpate.freeserve.co.uk/AutoExcl.htm#StartingExcel - however, that did not resolve the issue):

interface
uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, StdCtrls,// excel_tlb,
  Forms, Dialogs, checklst, Buttons, ToolWin, ComCtrls, Menus, Grids, DBGrids,
  ExtCtrls, Db, DBTables, DBClient, About, Report, IniFiles, Cdberr32,
  Ulogin32, ComObj, olectnrs, Find, ImgList, excel97, OleServer, clipbrd,
  AppEvnts;

. . .

procedure TfrmMain.btnExportClick(Sender: TObject);
var
    RangeE :Excel97.range ;
    I, Row : integer ;
    myClip : TClipBoard ;
    Arr : variant ;
    j : integer ;
begin
 //Replacing zoli code with OLE server code  GM
 //Create and show Excel spread sheet
    if qrylocations.RecordCount = 0 then
      Exit;

    try
        //Replace the after scroll procedure slows down process.
        qrylocations.AfterScroll := DummyMethod ;
        //Open Excel App and create new worksheet
        ExcelApplication1.Connect;
        ExcelApplication1.Visible[0] := True ;
        ExcelApplication1.Workbooks.Add(Null, 0) ;
        Arr := VarArrayCreate([1,qryLocations.Recordcount,1,3],varvariant) ;
        //Set teh data to the variant array
        with qryLocations do
        begin
            First;
            DisableControls ;
            for i := 0 to recordcount -1 do
            begin
                Arr[i+1,1] := Fields[0].ASstring ;
                Arr[i+1,2] := Fields[2].ASstring ;
                Arr[i+1,3] := Fields[5].ASstring ;
                Next ;
            end ;
        end ;
        //Set the excel worksheet to the variant array
        ExcelApplication1.Range['A1', 'C' + IntToStr(qrylocations.recordcount)].value := Arr ;
    finally
        qryLocations.EnableControls;
        //Reset the after scroll method back to original state
        qrylocations.AfterScroll :=  qryLocationsAfterScroll ;
    end ;
end;

The properties for ExcelApplication1 are as follows:

AutoConnect = false
AutoQuit = false
ConnectKind = ckRunningOrNew
Name = ExcelApplication1
RemoteMachineName = [EMPTY]
Tag = 0

It is possible that your users don't have necessary Office OLE Automation component installed. If my memory serves me correctly in later versions of Office you need to specifically select this component to be installed while in older versions (prior 2013) it was installed with default installation. Also do note that there were considerable changes in Automation API made with the release of Office 2013 so may need to update your code accordingly. — SilverWarior, Jun 03 '16 at 12:33
This might help. http://stackoverflow.com/questions/25509960/how-to-make-win32ole-work-on-64bit-ms-office-installation — Michael, Jun 03 '16 at 19:08
SilverWarior - thanks for the info. I have the team that installs O365 looking into that. I will keep you updated on the resolution. (EDIT to correct spelling of SilverWarior). — Bill, Jun 06 '16 at 17:51

score 1 · Accepted Answer · edited May 23 '17 at 12:31

1

I suspect the problem is that newer versions of Office run in a "virtual sandbox", sort of a pseudo virtual machine that cannot "see" everything installed on your machine and traditional methods of automating Office from a non-Office application no longer work, as your application cannot "see" that Office is installed.

Take a look at Is it possible to automate a Click-to-run application? for more details.

edited May 23 '17 at 12:31

Community

1
1

answered Jun 03 '16 at 19:25

Jon Robertson

591
6
18

Jon, I am checking with the team that installs O365 to see if they installed it as Click-To-Run or not (initial feedback was that they are installing as stand-alone but they are going to confirm). Thanks for the help! – Bill Jun 06 '16 at 17:52
I am accepting this as the answer even though I have not been able to confirm it for my issue. Apparently, O365 was installed as C2R for everyone and to re-do it as stand-alone is going to require more effort than we are currently willing to do. Given that O365 was installed as C2R, it seems likely this is our issue. Thanks for the assistance! – Bill Jun 22 '16 at 14:18

Exporting application data to excel works for some users but not others

1 Answers1