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.
Related
Shapelib is a library originally written in C, which provides the ability to write simple programs for reading, writing and updating ESRI Shapefiles.
I managed to compile shapelib.dll for 32bit and 64bit on the basis of https://github.com/OSGeo/shapelib and then I wanted to test if that works with the help of ShapeFileII.pas (available in that repo).
I am using Delphi 10.3. I started with Win32 and I wrote simple program which opens .shp file and reads geometry type and coordinates. Everything worked exactly how I wanted.
Then I add Win64 platform and wanted to test it. Unfortunately, program does not work properly on Win64. I can read only geometry type, other info like coordinates etc. are mostly null.
Did someone try to use shapelib library?
Could you give me a hint? Maybe there is some distincion between Win 32/64 data types?
I appreciate any kind of help.
Update
To be more precise, I added screenshot covering the same test object on Win32 and Win64. Running on Win32 gives me values just how i want - I need especialy nVertices and padfX, padfY, padfZ. Running on Win64 gives me incorrect value of nVertices (0) and weird one-line displacement (padfX in Win32 is now padfY in Win64).
Besides eventual 32/64 bit related issues,
ShapeFileII.pas
That's a 20 years old legacy code.
I would recommend using the free ArcView ShapeFile OCX and DLL, instead.
VB6 OCX & DLL, .NET 64bit specific and AnyCPU DLLs are included.
Pascal code snippets used to be included in the library's docs, as far as I remember.
In any case better check the author's repository:
https://github.com/rosspickard/ArcShapeFile
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.
Recently we upgraded our code from Delphi 2009 to Delphi XE and updated our Indy components (not sure if this is relevant).
But ever since then we have had errors on Windows Server 2003 machines when loading and saving XML files.
XMLDoc.LoadFromFile()
XMLDoc.SaveToFile()
The DLL msvcrt.dll is much smaller on Windows Server 2003 (300kb or so) compared to over 600kb on other operating systems... So its missing something in that file and its causing the error...
Does anyone know how to fix this? Or is there an alternative to TXMLDocument that I can try?
By default, TXMLDocument/IXMLDocument is just a wrapper around the MSXML COM interfaces when running on Windows platforms. Neither TXMLDocument nor Indy use the _ftol2_sse() function, or even link to msvcrt.dll. Something else in your project is at fault.
msvcrt.dll is (part of) the Microsoft Visual C++ Runtime. I think you got an older (or maybe even newer) version of this runtime that doesn't include this function.
Now you'll have to find out where this function is called. Do you link obj files with your project or use (other) 3rd party dll's?
To answer the last part ("is there an alternative?"), you might want to check out Jedi Code Library's TJclSimpleXML class. It does not require any external DLL, is quite fast, and is very easy to use. Besides, these days JCL and JVCL are a must-have anyway if you code in Delphi.
http://wiki.delphi-jedi.org/wiki/JEDI_Code_Library is their page I believe. I hear in seattle you can get it through IDEs integrated package manager.
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.
I'm trying to use the Pegasus Imaging PrintPro v4 ActiveX control with Delphi 7 on a Win2K box. When I drop the ActiveX control on the form I get the extremely helpful error message
"Access violation at address 00000000. Read of address 00000000."
and the component doesn't appear on the form.
There are a bunch of other Pegasus Imaging ActiveX controls installed and they work fine.
Any suggestions on where to start troubleshooting, I'm not very experienced with ActiveX control (I usually go for native VCL only).
Lachlan
If you download the latest changes file it says that "Fixed an issue where the ActiveX DLL would not register on Windows 2000.".
You should try upgrading to the latest version.
Something in the control is not configured properly. You might not be able to "drop" it on the form, but might have to instantiate it manually. The access violation you are experiencing is the attempt to get the value out of a pointer which is null. Most likely the control has a required construction parameter which is not being set by the Delphi ActiveX component wrapper.