So if it were possible (which it doesn't seem to be) to create a new sheet from a template by using manual actions in Excel, you could just record those actions to a macro and look at the resulting code, and then duplicate the effort in Delphi (it'll be VERY similar but not the same). If you can do something in Excel by using the menus or shortcut keys, you can record it as a macro. VBA is the language that MS Office records / runs its macros in, and is quite simple to understand / write. I don't know what your Delphi / VBA proficiency is, so please forgive me if this is too simple.Īs mentioned, the VBA (Visual Basic for Applications) documentation is your best friend, or any sites that focus on VBA. I'm using Delphi 7 for some old projects that, in spite of myself (swear!), I still can't migrate to new horizons (it's a long story, but it's definitely off-topic compared to this thread and Jitendra, to whom I send my greetings, could throw us out !) :)
I'm now waiting for the official release of 10.4 (don't know the name), which is already active in Beta, and will install that. for my laziness :) I've not yet installed last two versions 10.2 (Tokyo) and 10.3 (Rio).
With regard Delphi 10 versions, I have an active Delphi Professional subscription, and I own all the versions released to date, but I have never installed nothing after 10.1 (Berlin): from Berlin experience I was expecting at least update 2, but then they announced the 3 and.
In fact I wouldn't know how to manage my app on machines with online versions of MS-Office but, not having managed it to date even with "physical" versions for the moment my concern is premature :) Thanks Donald for your suggestions, preventive bitness testing is a very good solution!
You could most likely using Lazarus to target 32 bit and 64 bit in the same way, but I've never done COM level stuff with Lazarus, just "normal" client-dataset type DB apps and reports and such.You might be able to get more info here: Using Delphi 10 would allow you to target the various bitness platforms. Please adhere to the rules regarding use of that version. Remember if you're stuck with Delphi 7 only, and your app / business doesn't generate a lot of money, you can use the latest Delphi 10 community edition. A good idea would be to doing a number of bitness tests in your 64-bit "main app" (to evaluate whether you should execute your 32 bit or 64 bit COM utility) and then to ship both 32 and 64 bit utilities with your application to clients, always. Even worse, your users could be using Office 365 "online only" which means that the API's aren't available through COM on the machine at all. If the OS is 64 bit (which it usually is these days) then MS Office could be 32 bit or 64 bit (it's often still 32 bit) and Delphi apps could be either as well and if your Delphi app's bitness doesn't match that of Office your automation might fail.
You've now touched on a touchy subject in respect of "bitness". Thanks again for explaining the Excel approach with Delphi in a simple way and for the really good Delphi blog.ĭonald Klopper at 11:39 that's why I posted my ideas in the comments as well. Unfortunately I will not be able to apply the same solution with Delphi 7 because it does not have a 64-bit target, but I am happy to have solved the problem. So I tried to change the Delphi target, from WIN32 to WIN64, in Berlin version of the project and recompiled it, without changing anything and. Looking for "EOleSysError" online, I found that one of the possible causes is access to a 64 bit server (my Excel) with a 32 bit module (my Delphi application). I couldn't understand where the mistake was. "Įrror #2: "Access violation at address 006695C6 in module 'ExcelTest.exe'. OpenFileName := FileOpenDialog1.FileName Procedure TForm1.OpenExcelFileClick(Sender: TObject) ĭisplayName := 'Excel files (*.xlsx *.xls)' įileOpenDialog1.Title := 'Select file to open' Procedure OpenExcelFileClick(Sender: TObject)
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Excel2010, Vcl.StdCtrls, Vcl.Grids Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, The code that I have written as the test is: The crash is at function TExcelApplication.GetDefaultInterface: _Application, at the first line: The crash occurs in Excel_TLB.pas, which I imported as Donald Klopper suggested.
Has anyone else had this and been able to solve it? I get an exception class $C00000005 error with access violation at Oxoo62fd0b: read of address 0x000001bc when I use Workbooks.Open. I have been trying to read from Excel and used this information as the basis for a test program.