I am working on the development of a large management application that I am translating with the tools provided with Delphi (language DLL).
When I run the translated version, I have an EResNotFound exception when I want to run my reports.
Some components of the report generator used in the application are inherited from a TForm. And the DFM of the components are not recovered by the translation tool.
Unfortunately, it is not possible to change the report generator and the editor has still not responded to my support request.
How can we get around this problem? Has anyone ever faced this problem?
Thanks in advance.
Regards.
Related
I am facing an issue while recognizing Delphi Objects using UFT.
I have even checked the Delphi plugin while recognizing the objects but every time it is showing a Window's type Object. Below is the screenshot for the same.
Please suggest some solution for this.
Thanks in advance.
To use Delphi add-in, you MUST have access to source code of application - to be able to re-compile it with QTP integration (and possibly with Delphi extensibility) units. You can't use Delphi add-in with your application out-of-the-box, without re-compiling it. Please, refer to Delphi add-in help in UFT.
as the title says, I'm trying to compile a Win32 program without the aid of an IDE, just so I can learn. I'm using Borland Studio 2006, and my first thought was to take some files generated from a Forms application from the IDE and compile the project file... that gave me errors about expecting unit and finding object instead. I know that's from the dfm file which holds all the settings for a form, but I don't get how the IDE deals with that file, can anyone help me understand the system better? :)
If I have understood correctly, you need to grasp the structure of a Delphi project and how Forms and units work together. You cannot just cherry-pick some files and expect to be able to feed them to the compiler.
You also have to set the path to the library/components/used files so that the compiler can find everything it needs, starting with the project dpr.
I would recommend that you try first to run your project from the IDE, then once it runs, you can try it from the command line.
I found out all I needed to do is compile the top level unit into a dcu, and then the project will compile :) If anyone else is trying to do the same thing, there's some great info at the bottom of this page
http://www.codexterity.com/raw-delphi/index.htm
WANT automates the process of building, testing, and packaging applications and libraries much like Jakarta Ant does
You wrote in question that you are using BDS 2006. If you want to learn more recent build process in Delphi I suggest you to upgrade at least to Delphi 2007 which introduced MS Build usage.
Of course MS Build acts like "wrapper" so this is not must have but nice have :-)
HI:
I've a Delphi 7 program that I wrote many years ago, but I've lost the source code. It's a small program but very useful for me.
I've tried to 'install' it again in a new Windows XP computer, just copying the folder with de data (.db paradox files), and configured the BDE connection.
When the programm starts I receive an "Unknown exception" and halts. I've no idea why this happens, and can't debug cause the lost source code. I've tried in another computer with the same results.
Any suggestions or ideas? What do you do in a situation like this?
Thanks in advance.
EDIT:
When I installed Delphi 7 in the new XP computer, the exception came from unknown to known. It was something related to the folder for the Paradox.net file. Thnk you all.
Delphi IDE can attach to a running process and debug it (Run -> Attach to process), although without debug symbols you will end up debugging plain assembler code, which requires some knowledge of assembler and how a Windows application works. And debugging startup exceptions could be pretty difficult if the debugger can't start the program. You can also use the WinDbg debugger from Microsoft.
There are disassemblers (I used the very powerful IDA Pro) that are able to recognize standard library calls helping analysys a lot. You may also find decompilers, although decompiling native applications is a bit more difficult than with those using a p-code or the like.
If the error is not due to a misconfiguration, patching a binary file is not easy.
You can use any debugger, either Visual Studio one, or a free OllyDbg, don't know if Delphi IDE have a simple external-exe-debugger.
But debugging will be very hard w/o source codes, and you must have at least basic knowledge of Assembler Language and win32api.
Alternatively you can use tools like FileMon & RegMon to examine your app activity and find potential problems.
You can try "Run|Connect to process..." in the Delphi IDE. But what zed_0xff said regarding debbugging without sources still applies.
I would go for the disassemble approach like ldsandon suggest, especially since you have (some) knowledge about what your exe is doing.
Besides IDA Pro also take a look at tools aimed specifically at Delphi such as IDR (Interactive Delphi Reconstructor), DeDe and PE Explorer.
To make sure it is not BDE related, I would build another rudimentary application trying to access the same data on this machine.
Once this application works, you can move on to test on the Pascal code side of things.
I have had my share of BDE oddities so I'd prefer to rule this out.
A vendor has developed an ActiveX control in Microsoft C++. The ActiveX worked fine when they were using the 16bit version of the compiler. The control does not work when compiled using the 32bit version within the Delphi2007/D7 environments. If you drop a control on a form and run it throws an "Floating Point Error".
It is a Delphi issue. We are able to use the ActiveX in other applications.
Anyone ever have a similar problem or have a solution for this?
Sounds like an FPU problem - check out Set8087CW in Delphi's help file.
I'm porting an application from Crystal Reports 8 to Crystal Reports XI in Delphi 5, using the RDC/ActiveX interface.
In Crystal Reports 8, I was able to bring up the crystal reports default report viewer window for a report like so:
RptInvoicing.Destination := 0; // To: window
RptInvoicing.Action := 1; // Execute
However, this does not fly with CR XI. Printing and exporting I've figured out to work like this:
crReport.PrintOut(True);
...
crReport.Export(True);
But I haven't been able to find anything relevant to show the default preview window. I've tried implementing my own using the report viewer component, but it has a lot of problems like locking up when resizing, freezing and crashes, so it's not a viable solution for a production app.
Even the official support forums weren't of help, I only got a nasty answer to go look at the manuals, which I've been through several times and can only refer to as bad. It's not every day you see such bad documentation for an enterprise product. I found nothing relevant to this in their manuals, so I'm led to think their own staff have no idea about this either.
So I'm hoping someone here could tell me if the default report viewer still exists in CR XI, and if it does, how to invoke it? If it doesn't, is using the report designer component really the only solution to create one?
I recently had the same problem, and described the solution here. I am using Delphi 2007, but since the code involves calls to an external ActiveX DLL, it should work for you too.
From their documentation:
Craxddrt.dll (Crystal Reports ActiveX
Designer Design and Runtime Library)
is a unified object model that
combines the runtime capabilities of
the Craxdrt.dll (Crystal Reports
ActiveX Designer Run Time Library)
with the design time capabilities of
the Craxddt.dll (Crystal Reports
ActiveX Designer Design Time Library).
Craxddrt.dll will replace Craxddt.dll
for versions 8.5 and up. Both the
Craxddrt.dll and the Craxdrt.dll
contain all the objects and associated
methods, properties, and events needed
for creating, opening, exporting,
saving, and printing a report at run
time. In addition, Craxddrt.dll is
either used with the RDC ActiveX
Designer when designing reports at
design time, or used with the
Embeddable Designer when designing
reports at run time. See “Embeddable
Crystal Reports Designer Control
Object Model” on page 343 for more
information.
Note: The RDC ActiveX
Designer is only available in
Microsoft Visual Basic.
Prior to
version 8.5, the Craxdrt.dll would be
distributed with an application. Now
the developer has a choice of two
automation servers to distribute.
Craxdrt.dll is backwards-compatible
with previous versions and contains
all the features introduced in this
version. Use the Craxdrt.dll for any
client-side application that does not
contain the Embeddable Designer, or
use it for any server-side
application. Craxddrt.dll is
apartment-model threaded, but is not
thread safe, and can only be used in a
client-side application. Although the
Craxddrt.dll is a fully functional
automation server for the RDC, and can
work in any client-side application,
it will increase the install size.
Therefore, it is recommended that you
only use Craxddrt.dll with the
Embeddable Crystal Reports Designer
Control.
I can't say anything about Delphi, but in VB we are using CRViewer ActiveX Control. Using it is straightforward - you put viewer control on form and assign RDC object to it. This is covered in CR help somewhere. (I can't look at code ATM to provide working exmples.)