Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Suggestions on how to debug app problem

Status
Not open for further replies.

DjangMan

Programmer
Jun 1, 2001
1,783
CA
Hi all,

I have an application that interfaces with a bunch of COM objects through interfaces. A transaction is imported into an accounting package through these COM objects. This was working fine for a while: the user could import a file which I then pushed into the accounting package. The user could then import another file and another file and so on.

Then the user turned on some additional functionality in the accounting package to handle serial numbers. Now if I process a transaction with a serial number the next transaction that I post will fail in one of three places. I was hoping that by wrapping the COM objects within an interface that everything would be cleaned up but that hasn't been the case. My workaround is to have the program close and reopen after a transaction has been imported.

I'd love to figure out why I'm not releasing everything properly. I haven't had to do much analysis at this level before so I'm not sure where to start. I'm using Delphi 2009. The problem is that my computer doesn't exhibit this problem. I can reproduce at will on a test database on their system so whatever strategy I use has to log data to a file or to a debug window that I'm sending messages to because I don't have the IDE installed. MadExecept will tell me the line of code where I'm crashing but the issue, I think, is related to how the COM objects are not being cleaned up properly.
 
There really isn't much being said here about the nature of the errors, but something to think about: Is it possible that you didn't quite have the COM/ActiveX part of your code defined quite right and this got revealed when the user turned on the new feature of the accounting package?

I know I run into problems occasionally with COM objects I've used because the type library importer doesn't get it "quite right" and end up having to change that part to get it right.

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.
 
There's three very different errors that appear. One is that a call to get a double value from the database blows up. The next stumbles on ntdll.dll and the third is an error that appears directly from the COM object. It's almost a roll of the dice.

It isn't the COM object but rather the inside of the COM object that is causing the grief. This particular application uses a framework the forces a uniform outward interface. In addition the serial number functionality in this version of the application is weak. (I wasn't happy when they said they were using it.) Something isn't being reset somewhere so perhaps my workaround of closing my application is the only workaround. That's okay because the program is small and starts up pretty quickly. However - my machine works just fine. Now there could probably be a hundred things that are very subtly different that I'll never find.

I might try some further encapsulation like putting all of the code into a TDataModule so that I can not only free up all of the interfaces but I can free up the parent data module as well. Just to make sure there are no lose ends.

Thanks for reading, however, Glenn. I appreciate your thoughts and your posts to this forum.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top