I'm working with Delphi's MS Office interop, OfficePartner, and I can't seem to find out how to insert a Continuous Section Break into my doc (this can be done in .Net via an InsertBreak() call). Actually, any break will do I can probably figure out this specific one if I get a nod in the right direction.
Thanks!
I wonder why use the TurboPower components, instead of just using the COM (OLE Automation) interfaces for MS Office.
It's so easy to do OLE Automation COM interfaces (using Variants and not bothering about Type Library Imports or ActiveX controls).
Related
Connecting to ADO is hard from installation in Delphi, so I decided to use VBscript, which I have never used before. VBscript has little support in Delphi, so how do I run a Windows script editor to get support and carry it over to Delphi? I do not understand the statements in VB script very well yet
My Delphi TTable is connecting to
the ADO
I need to connect to a
Microsoft DB file in c:\program
files\common\my folder\my file
I need to disconnect the ADO to
relocate this file and place a new
copy in its place periodically.
I looked up the MSN web site and it's not that helpful.
I see scripts that could be useful for many things if I can get them working.
Can anyone help please?
Lex Dean
The best way is to use the native (and easy) ADO components in Delphi.
You will found a example of 'how to do', with source, here :
http://sourceforge.net/projects/axbase/
You do not connect to ADO. You connect to a DB through ADO. ADO is a technology to connect to different databases using a common API - the database native API is taken care of by ADO drivers.
You say you need to connect to a "Microsoft DB" file but do not specify what kind. ADO can connect directly to Access files, but if you use SQL Server you never connect to a file, you connect to the database server.
Delphi has a different set of components to connect through ADO. They are the TADOxxxx component. TTable is built upon the BDE, and can't use ADO. Use TADODataset or TADOTable.
Using VBScript from Delphi is possible, but would not solve your problem easily - you will have to pass ADO objects to and from Delphi and VBScript, and it requires a good knowledge of Delphi, Windows, COM and so on. If you need to use ADO, take the straight path.
in C# you can easily open an assembly (just another word from an EXE) and then get reflection information from that assembly. I've been looking for something similar for Delphi where I can write a Delphi program that can point to a Delphi EXE then get me reflection information. How can I archive this? Thanks
There are a handful of programs that can extract RTTI from Delphi programs and DLLs. It's not as rich as what's available for .NET, but it can be done to a limited degree. There's a lot more RTTI available in Delphi 2010 and later versions, but as far as I know there's no program out yet that can extract info from them.
I was at the conference where this system was formally announced, and a bunch of people asked how this would affect security. Barry Kelly, who created the new RTTI, said that there would not be enough metadata available to create a "Delphi Reflector".
Well, sad news is, you probably can't. You can easily view .NET assemblies because they a) are compiled to what is called intermediate language (thus you can even get the code back using the likes of Reflector etc.), and b) contain metadata. Delphi, on the other hand, compiles to native code that and produces regular PE files that do not include rich metadata like a .NET assembly.
Delphi just doesn't work that way.
There are tools that can assist in reversing (Delphi written) executables but it will never be easy and it requires good x86 assembly knowledge.
Some examples of such tools are:
IDA Pro and/or Hex Rays
DeDe
Interactive Delphi Reconstructor
PE Explorer
The resource sections of a Delphi Executable also reveals usefull info like the form and it's components.
See also Is there a program to decompile Delphi?
If you have Delphi2010+ you can load a bpl and then use the rich rtti over it lik. e you do with c# and a .net assembly. If you need to do this in a .exe AFAIK you can't.
TestComplete seems to identify most objects in a running Delphi executable. You can extract this information with a script. A demo can be downloaded from http://www.automatedqa.com/downloads/testcomplete
This is maybe not the type of application you want as it is big and made for GUI-testing, but yes it can identify the objects.
As mentioned Remko, IDR (Interactive Delphi Reconstructor) can extract all RTTI information (if program contains it!) for Delphi version from 2 to 2009. Version 2010 will be available later. Moreover IDR can use all information that it finds in program to create a lot of comments to disassemled program code (this is a first step of analyses). You can also look forms and easy go to event hadlers associated with controls.
I'm trying to generate _TLB import units for Outlook 2003, 2007 and 2010 (and also other OLE servers) analogous to the ones bundled with Delphi for Outlook 2000 and 2002. However, I couldn't get the type library importer to also generate the code for capturing events from the OLE servers that is found in the bundled units. The option to "Generate component wrappers" only creates wrappers for servers that are directly instantiatable but not for objects that are only returned via methods of other objects like TInspector, TExplorer, etc.
I could of course create the event handling code myself but that would be really tedious work.
Does anyone know if the importer contained with Delphi 2010 (tlibimp.exe) can be tweaked to generate that code? I really doubt that back in the day Borland created the existing Outlook2000.pas and OutlookXP.pas units manually...
Are there maybe any other tools around that can do this?
Good question! I never noticed that those components were not created (I only use Word_TLB). After playing a bit with tlibimp I found out that you need the -Yc+ flag. Probably all ignore flags are default on.
NB: this is on Delphi 7 with tlibimp.exe version 7.0.4.453
I'm looking for a light-weight database engine for Delphi 1 (don't ask, it's a long story). Delphi 1 is 16-bit. The engine should compile into the EXE. SQL would be nice, but not mandatory. Any info would be great. Thanks, Carl
A 16-bit version of Microsoft Jet should be easy to integrate even with older versions of BDE (ODBC driver).
Otherwise you can use .db files (dBase - xBase), BDE should be able to handle them directly.
How about sqlite?
Turbo Power Btree Filer ? IIRC TP's is open source and TP was 16-bit.
Maybe this or the other DBF tool has 16-bit options. However the one I used (TDBF) doesn't afaik.
A long time ago I used VB/ISAM with Delphi 1. It works well with Delphi 16bit even though it was originally made for VB. It is from Software Source. I think we were using v4.x.
why not check on Delphi Super Pages web site. They use to maintain a complete code and component collections for Delphi 1.
I don't know the current situation though ;)
If you want I have a VBX based DB engine called VSData.
I never used Delphi 1 so I don't know as to how good it was at handling VBX. I have used this db engine as at that time this was the only engine to support storing multimedia files!
I'm using Turbo Delphi 2006.
The DLL will be called from within Excel as part of a VBA/DLL combination.
The first part of the problem is trying to find out how to pass to the DLL a reference to the current Excel session. Most other code I've seen was that it launched a separate instance of Excel apart from the one you're in.
I've seen some C++ code that creates an instance of IDispatch and then passes something in to a method of the IDispatch object, but not knowing much C++.
Any ideas?
What you describe is called writing a COM addin. You need to create an automation DLL and implement the IDTExtensibility2 interface. You will then receive the Excel Application interface as a parameter to the OnConnection method.
You will also need to register your DLL as an addin so Excel will automatically load it.
EDIT: Forgot to mention: You might want to take a look at Add-in Express. Their framework and components make getting started with the creation of Office addins ridiculuously easy. You definitely won't have to bother with the details of IDTExtensibility2. All that comes with a (well-justified) price tag, though.
Delphi comes with a set of ActiveX controls to give complete access to Excel and the other Office applications. They should be on the "Servers" tab of the Tool Palette.
If the aren't there, then select Components|Install Packages, and scroll down the list there until the very end, and select the right package.
In a default installation, they should be called:
Microsoft Office Sample Automation Server Wrapper Components
and there should be one for XP and Win2k. The XP ones will work for Vista.
Now that if if you want to automate Excel.
If you merely want to add functionality to Excel by using Delphi, I'd suggest using a COM object, as I suspect that Excel is very accepting of COM objects. Otherwise, you can create a straight DLL, and use that the same way that Excel uses any other DLL.
I do not know much about Office, but I guess you should use COM/ActiveX. Then you also get your IDispatch. See http://delphi.about.com/od/comoleactivex/OLE_COM_DCOM_Automation_ActiveX_Delphi_knowledge_base.htm