Error in exe runs OK in IDE

[murraymc]

I have an application that hosts several OCXs. Many are custom the main one hosts a number of OCX's itself.

The problem is that when the application is compiled and the regional setting set to Frech (decimal point = , (comma) and 000 separator = .(dot) or space) a database (ADO) update call (in ESRI Map Objects) fails with an Update Failed error. If I load the EXE into the VB6 IDE and run it there everything works.

I do not run any other code in the IDE so I am still running the compiled OCXs. I have tried everything I can think of but can't get it to work compiled.

On a new PC built just for the compile of this application the Update call fails regardless. I can load the EXE code and run it in the IDE or all the code in the application into the IDE and I still get the Update error.

Any ideas or things to try would be greatly appreciated.

I should also mention that the OCX project (written by a 3rd party) has a history of being "difficult" to compile.

Murray

[Al42]

If I load the EXE into the VB6 IDEDo you mean if you load the .vbp (or equivalent in .net) file? You can't load an .exe file into the IDE.

I do not run any other code in the IDE so I am still running the compiled OCXs.Are you sure the project file isn't loading some .ctl files?

On a new PC built just for the compile of this application the Update call fails regardless.Exactly what is failing? What error message? Have you put error trapping into the .ocxs, so that they'll give you a more extensive error report?

I should also mention that the OCX project (written by a 3rd party) has a history of being "difficult" to compile.Try fixing the "difficulties". "Difficult to compile" usually means "badly written".

[murraymc]

Do you mean if you load the .vbp (or equivalent in .net) file? You can't load an .exe file into the IDE.
Sorry, not thinking clearly. I load the core EXE project (vbp) into the IDE.
Are you sure the project file isn't loading some .ctl files?
Absolutely positive. I wrote the EXE which hosts the Problem OCX on one of the (many) forms.
Exactly what is failing? What error message? Have you put error trapping into the .ocxs, so that they'll give you a more extensive error report?
yes, I have put individual line checks. What fails is an update call to a new record created in an ESRI Map Objects Feature Layer (Shape File).
Try fixing the "difficulties". "Difficult to compile" usually means "badly written".
If I could do that I would be very happy but it will take a minimum of 3 months. This is an application/OCX that has "on error resume next" at the top of every function and often at the top of loops. I have a contractor starting Monday to undertake the work of injecting my error handlers throughout the application but cant wait for him to finish to resolve this issue.

In the past many of the problems seem to be around compilation, It all compiles OK on one PC but not on another. Never got to the bottom of it.

In this instance all compiles OK but throws an error under French, German and Norwegian not English, Chinese, Japanese, etc.

I have placed the OCX onto a separate new single form application and set up the relevant calls and it works however the setup and all the data and relevant calls are identical. I can't see why the behaviour is different.

Driving me nuts.

[Al42]

This is an application/OCX that has "on error resume next" at the top of every functionDo a global replace of On Error Resume Next with nothing!

While there are valid uses of Resume Next, hiding all errors is NOT one of them.

and often at the top of loops. I have a contractor starting Monday to undertake the work of injecting my error handlers throughout the application but cant wait for him to finish to resolve this issue.Since you can't resolve the problem until that's done, you have two choices - wait or start changing code.

In the past many of the problems seem to be around compilation, It all compiles OK on one PC but not on another. Never got to the bottom of it.This is a clear case of "We don't have the time to do it right the first time, but we have the time to do it over and over, trying everything short of doing it right."

In this instance all compiles OK but throws an error under French, German and Norwegian not English, Chinese, Japanese, etc.And, with no error trapping, you'll never find the error. You could waste a few months guessing, or you could spend a few weeks finding and fixing the errors.

I have placed the OCX onto a separate new single form application and set up the relevant calls and it works however the setup and all the data and relevant calls are identical. I can't see why the behaviour is different.And you won't until you trap an error actually happening and look at the relevant data and code.

[murraymc]

Since you can't resolve the problem until that's done, you have two choices - wait or start changing code.

Not really, the code has been in production for 2.5 years, the problem has to be something that has changed from the shipping version.

This is a clear case of "We don't have the time to do it right the first time, but we have the time to do it over and over, trying everything short of doing it right."

The OCX code (a full blown mapping application) was bought in, not done in house. It represents 3-5 man years of effort, fixing that is no trivial thing.

And, with no error trapping, you'll never find the error. You could waste a few months guessing, or you could spend a few weeks finding and fixing the errors.

Again not always true, you have to be pragmatic about these things, it has been running on client sites for years. Admittedly the code improvement should have started a long time ago but it is always hard to justify fixing things that work and the next version had to be completed in the next 2 years.

Happily this issue has allowed me to make the case more strongly and I have a developer working on injecting my error handlers and tidying up the code. It will take a month or three.

Having proper error trapping everywhere would not have helped in this case as the problem was discovered to be a memory leak in an unrelated 3rd party control that was included 2+ years ago. FarPoint Spread 7.00.43 which appears to have a memory leak causing this issue. Once patched to 7.00.47 the problem was resolved.