I need to add TWAIN scanning to an Delphi application and am having trouble locating an off-the-shelf component to do so.
I downloaded TDelphiTwain but, when used in D2010 on Windows Vista, it does not appear to recognize any Twain sources on my system. I also tried the trial version of Twain Toolkit for Delphi from MCM which has the advantage of being currently updated (DelphiTwain's last update was 2004), but the Twain Toolkit will not even compile on my system (I think some of the DCUs are out of date).
Can anyone suggest a simple method of getting TWAIN scanning into my Delphi application?
UPDATE: Using vcldeveloper's update to DelphiTwain (see below) I was able to get this working. Also, I also discovered that Envision Image Library supports Twain scanning as well as assisting in handling multi-page TIFFs, and has been updated for compatibility with D2010.
Late Breaking UPDATE VCLDeveloper's code, below, works fine. However, I settled on Envision library which includes the ability to easily create multi-page TIFF files. I got the Envision scanning, including multi-page file handling, implemented in a few hours.
I changed DelphiTWAIN to work with Delphi 2009 and 2010. You can download the source code from here: http://www.kluug.net/delphitwain.php
Additional links are here:
http://torry.net/pages.php?id=507
and here: http://www.delphipraxis.net/1179589-post3.html
Another graphic library that also supports TWAIN scanning is ImageEn which also can save the scanned documents as PDF (as well as numerous graphical formats). That feature alone sold me on that product years ago.
Related
I have used the Synactis product PDF-in-the-box in Delphi 2006 projects and also a free component they had called TPDFViewer, which allows you to embed a PDF viewer in your application.
I am porting one app to XE and - having found that trying to install the TPDFViewer I had in XE did some serious damage to my installation - I'm looking for a replacement.
I have installed XE-supported trial versions of their current offerings PDF-in-the-box 4.04 and All-in-the-box 4.04 but can't see any sign of the TPdfViewer component in either. Their website FAQ implies this functionality has been replaced by functions to start Adobe Reader.
So I want a (free would be nice, but not essential) PDF viewer for Delphi XE which doesn't just chain to Adobe Reader and allows user interaction or programmatic control over zoom, page number etc.
I tried several times to find a good PDF viewer. Most of them were fake components. The best way is to embed acrobat reader dll directly into your application and command it from there.
It was 8 years ago, so I do not remember the code that I used to do this. You import the acroXX.dll file directly into Delphi, it prepares a user component for you and then you install this component directly in to your Component palette.
The worst thing in this configuration is that you have to take care of the acrobat reader dll that is installed on your clients. Any update/upgrade of the reader may cause your application to fail.
Here is the screenshot of the Adobe Encore program.
Here you can see the set of the darkish components.
Can such be bought, downloaded, etc? Are they made public from Adobe Cor.?
Thanks
The easiest way to achieve that look and feel is either:
To purchase a skin engine or component library that has skins enabled, if you must use an old version of Delphi prior to XE2.
But the preferred method is to just use the VCL skins library that comes in Delphi XE2, called VCL Styles. Unfortunately it has bugs, but so do all the other skin libraries. You can also achieve similar results in Delphi XE2 using the Firemonkey framework, which like whatever non-delphi technology is used in Adobe products, eschews native controls for a completely self-contained environment that can look any way you want it to.
If you want funky/pretty user interfaces, personally, I recommend you get Delphi XE2. If you insist on "try/buy/component" then I suggest you look into the Developer Express component suite, or one of the ones listed in this question such as VCLSkin.
I decided to have a concerted effort to get the excellent DWScript (Delph Web Script DWS) integrated into a simple IDE using SynEdit. DWScript is currently being agressively developed and has a number of advantages over other Pascal Script libraries, however it does not contain an editor or any IDE example beyond a simple memo control to prove execution capability. It does contain a number of hooks for editor / debugger integration and in fact when DWS was reawakened a while ago, releases did contain an example of a SynEdit / DWS2 (as it was then) integration. An example can be found in the file dws2src20-20030907.zip in the \dws2rel\dwstools\idedialog\source where there is a 'mini-IDE' with editor window, call stack, breakpoint window etc. Really nice. I did get this working some months ago using an old SynEdit and the DWS2 that was included in this file.
So, I have now tried achieve this (or a similar) ide using the latest SynEdit (downloaded from SVN) and the latest DWScript (also from the SVN). Both libraries are installed fine into XE and their demos run fine. I then tried taking the ide example from the old "\dws2rel\dwstools\idedialog\source" and updating the code but much has changed. Frustratingly, not so much has changed that I gave up quickly - I tried searching for the various 'old' type definitions in old source and matching them up with 'new' definitions. Finally though, after several hours mired in code I decided that someone, somewhere must surely have been down this route?
Has anyone got an example of a DWScript - SynEdit integration using recent DWScript code please? I'm very happy with something simple that I can learn / build upon.
Thanks
SynEdit component has received little maintenance, and even some projects as Inno Setup have changed to Scintilla, Inno Setup is not using DWS but the code can serve you as a basis for new IDE
Dws have a editor on the demos with debuger and remote debuger just download all versions of dws one
I have imported Acrobat Reader using Components | Import Components. The AcroPdf_TLB unit is created in the Imports directory.
When I try to use the AcrobatReader component, as follows ...
AcroDoc := TAcroPDF.Create(nil);
... I get an 'Unspecified Error' exception (EOleSysError). Any ideas?
Thanks, Pieter.
If you are unhappy with the results you are getting there (I was), you might consider giving QuickPDF a try. The price is not unreasonable, they have lots of good PDF functions included and you can display a PDF accurately in a TImage control with a call to RenderPageToStream. One thing I discovered working with form fields is that I had to use their FlattenFormField before rendering to get the form field contents to be included in the rendered image.
Follow up:
I did not mention originally that QuickPDF also works for printing. For form fields, you have to do the same FlattenFormField routine, but the results look good with much less overhead than relying on Acrobat Reader.
We use the Adobe Reader plug-in and face this issue often. It particularly surfaces after a user performs a web-update on the Adobe Reader.
Try un-installing (via the Control Panel), then re-installing the latest Adobe Reader.
That invariably clears the issue for our users.
Put the component on a TForm, then it probably works.
The Acrobat ActiveX/COM object is notorious for not supporting interfaces of older versions properly. You get EOleSysErrors all over the place.
What I have personally done for a couple of clients, is load the PDF documents in a TWebBrowser.
TWebBrowser is a wrapper around the ActiveX/COM component that Internet explorer uses to display everything.
Adobe is pretty good in making that work with each Acrobat update, so the TWebBrowser then also works.
Note that this only makes sense for displaying the PDF document.
--jeroen
We successfully used the acrobat v6 reader component in our Delphi 7 app, but found that it really requires acrobat v6. Users today who install only acrobat v9 get an error when they use our app to view a pdf because the acrobat component is not backward compatible in this way.
So yes, you can do it, but there are probable issues going forward.
A third party tool is prob best...
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!