compiled VB proj exhibits run time error, but not in IDE/debug 
Author Message
 compiled VB proj exhibits run time error, but not in IDE/debug

I have a rather large application that I still maintain in VB5.  It's a very
complex app, but I have only one problem:

There is an error the crops up in the compiled stand along version, but not
in the same project when I run it inside VB and try to find the error with
the de{*filter*} tools.  (It's "compiled"  not all the way native machine code,
but "compiled" to exe with Make command, still using the VB runtime -- it
has lots of complex form redraws and such, so this was the way to go.)

Anyway, I have found before that there are sometimes minor differences in a
"Make-ed" version, compared to the behavior in the development environment.
I've had problems before with a fully tested and debugged project, that
works differently (with a bug) after it was make-d.  Little things, that
crop up when pushing the code real hard.

Anyway, can anyone give me any suggestions as to how to proceed?  Have other
people had this kind of thing happen?

I know that's pretty vague question without specifics, but does anyone have
any comments?

many thanks



Sun, 05 Sep 2004 00:37:26 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

released on Tue, 19 Mar 2002 09:37:26 -0700 bearing the
following fruit:

Quote:
>I have a rather large application that I still maintain in VB5.  It's a very
>complex app, but I have only one problem:

>There is an error the crops up in the compiled stand along version, but not
>in the same project when I run it inside VB and try to find the error with
>the de{*filter*} tools.  (It's "compiled"  not all the way native machine code,
>but "compiled" to exe with Make command, still using the VB runtime -- it
>has lots of complex form redraws and such, so this was the way to go.)

>Anyway, I have found before that there are sometimes minor differences in a
>"Make-ed" version, compared to the behavior in the development environment.
>I've had problems before with a fully tested and debugged project, that
>works differently (with a bug) after it was make-d.  Little things, that
>crop up when pushing the code real hard.

>Anyway, can anyone give me any suggestions as to how to proceed?  Have other
>people had this kind of thing happen?

>I know that's pretty vague question without specifics, but does anyone have
>any comments?

>many thanks

Do you have these problems on the same machine on which you
compiled the app?

If it's on another machine did you install it using a setup
program?



Sun, 05 Sep 2004 00:54:40 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Hi Jan,
Yes and yes.  Same problem on all machines, with and without the development
environment, and I do use a setup program... which follows all the rules,
self-registering this and that dll, all in the right directories.

In addition, I was very attentive to trying to design good error trapping
and handling throughout the application.  It all works great, except for one
little sequence of operations --- that yields an error in the stand-along
version, but not in the same code running in the IDE.

The app is very stable.  My error occurs when I am sending out data to an
excel sheet object, via com automation.  This of course was mildly tricky
code, getting the excel object model right and so on, but it works
flawlessly except for an untrapped error that crops up ("runtime error '5'
invalid procedure call" is what I get in a dialog box), then my app closes
down.

The dialog box was not mine, it comes from the system somewhere.

The whole scenario generally  has to do with my code that traps duplicate
worksheet names (sheet names must be unique within a given workbook) if the
user is trying to add sheets or change names so that this duplicate
condition occurs .... my code runs interference between the user, testing
sheet names and otherwise validating data before making calls to excel
objects to change properties or add sheets or workbooks to an excel
instance.

But something has slipped through, and as I mentioned, I cannot find it
(yet) by using debugging tools because it never crops up when running the
code in the IDE.

any ideas?
thanks
David

Quote:


>released on Tue, 19 Mar 2002 09:37:26 -0700 bearing the
>following fruit:

>>I have a rather large application that I still maintain in VB5.  It's a
very
>>complex app, but I have only one problem:

>>There is an error the crops up in the compiled stand along version, but
not
>>in the same project when I run it inside VB and try to find the error with
>>the de{*filter*} tools.  (It's "compiled"  not all the way native machine
code,
>>but "compiled" to exe with Make command, still using the VB runtime -- it
>>has lots of complex form redraws and such, so this was the way to go.)

>>Anyway, I have found before that there are sometimes minor differences in
a
>>"Make-ed" version, compared to the behavior in the development
environment.
>>I've had problems before with a fully tested and debugged project, that
>>works differently (with a bug) after it was make-d.  Little things, that
>>crop up when pushing the code real hard.

>>Anyway, can anyone give me any suggestions as to how to proceed?  Have
other
>>people had this kind of thing happen?

>>I know that's pretty vague question without specifics, but does anyone
have
>>any comments?

>>many thanks

>Do you have these problems on the same machine on which you
>compiled the app?

>If it's on another machine did you install it using a setup
>program?



Sun, 05 Sep 2004 01:06:52 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

released on Tue, 19 Mar 2002 10:06:52 -0700 bearing the
following fruit:

Quote:
>Hi Jan,
>Yes and yes.  Same problem on all machines, with and without the development
>environment, and I do use a setup program... which follows all the rules,
>self-registering this and that dll, all in the right directories.

>In addition, I was very attentive to trying to design good error trapping
>and handling throughout the application.  It all works great, except for one
>little sequence of operations --- that yields an error in the stand-along
>version, but not in the same code running in the IDE.

>The app is very stable.  My error occurs when I am sending out data to an
>excel sheet object, via com automation.  This of course was mildly tricky
>code, getting the excel object model right and so on, but it works
>flawlessly except for an untrapped error that crops up ("runtime error '5'
>invalid procedure call" is what I get in a dialog box), then my app closes
>down.

>The dialog box was not mine, it comes from the system somewhere.

>The whole scenario generally  has to do with my code that traps duplicate
>worksheet names (sheet names must be unique within a given workbook) if the
>user is trying to add sheets or change names so that this duplicate
>condition occurs .... my code runs interference between the user, testing
>sheet names and otherwise validating data before making calls to excel
>objects to change properties or add sheets or workbooks to an excel
>instance.

>But something has slipped through, and as I mentioned, I cannot find it
>(yet) by using debugging tools because it never crops up when running the
>code in the IDE.

>any ieas?

Not much I can add really, in this case I would probably
make a copy of the project, and start sticking in error
logging code all over the place so I could see what is going
on in the compiled app.  Another possibility is to examine
the error code itself, since an error in the error code
could cause a crash.

J

- Show quoted text -

Quote:
>thanks
>David


>>released on Tue, 19 Mar 2002 09:37:26 -0700 bearing the
>>following fruit:

>>>I have a rather large application that I still maintain in VB5.  It's a
>very
>>>complex app, but I have only one problem:

>>>There is an error the crops up in the compiled stand along version, but
>not
>>>in the same project when I run it inside VB and try to find the error with
>>>the de{*filter*} tools.  (It's "compiled"  not all the way native machine
>code,
>>>but "compiled" to exe with Make command, still using the VB runtime -- it
>>>has lots of complex form redraws and such, so this was the way to go.)

>>>Anyway, I have found before that there are sometimes minor differences in
>a
>>>"Make-ed" version, compared to the behavior in the development
>environment.
>>>I've had problems before with a fully tested and debugged project, that
>>>works differently (with a bug) after it was make-d.  Little things, that
>>>crop up when pushing the code real hard.

>>>Anyway, can anyone give me any suggestions as to how to proceed?  Have
>other
>>>people had this kind of thing happen?

>>>I know that's pretty vague question without specifics, but does anyone
>have
>>>any comments?

>>>many thanks

>>Do you have these problems on the same machine on which you
>>compiled the app?

>>If it's on another machine did you install it using a setup
>>program?



Sun, 05 Sep 2004 01:25:10 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Jan,

Thanks for your thoughts.  I guess that's the only route left for me at this
point.

I appreciate your reply...
have a good day,
D. Marx

Quote:

>Not much I can add really, in this case I would probably
>make a copy of the project, and start sticking in error
>logging code all over the place so I could see what is going
>on in the compiled app.  Another possibility is to examine
>the error code itself, since an error in the error code
>could cause a crash.

>J



Sun, 05 Sep 2004 01:33:33 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
David,

        I have found that you can often find these tricky errors by changing
the break mode to break on all errors in the IDE.  It is painful as you get
a break even on handled errors but it will often show up errors which
somehow the IDE gobbles up.

Matt


Quote:
> Jan,

> Thanks for your thoughts.  I guess that's the only route left for me at
this
> point.

> I appreciate your reply...
> have a good day,
> D. Marx


> >Not much I can add really, in this case I would probably
> >make a copy of the project, and start sticking in error
> >logging code all over the place so I could see what is going
> >on in the compiled app.  Another possibility is to examine
> >the error code itself, since an error in the error code
> >could cause a crash.

> >J



Sun, 05 Sep 2004 09:35:10 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Thanks for the reply, Matt.  I've been experimenting with just that approach
and hope to get lucky.

cheers,
D. Marx

Quote:

>David,

>        I have found that you can often find these tricky errors by
changing
>the break mode to break on all errors in the IDE.  It is painful as you get
>a break even on handled errors but it will often show up errors which
>somehow the IDE gobbles up.

>Matt



Sun, 05 Sep 2004 20:03:21 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Don't know if this applies but 'ive found that if you
instanciate an object in the Form_Activate the IDE will
not create extra copies(no idea why) but when runing
an .exe of the same code every time the form activates a
new instance of the object is created.
Drove me crazy until I figured it out

mike Wilson



Mon, 06 Sep 2004 02:38:37 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Mike,

That's really interesting.  I work with a lot of object variables in my app,
maybe something like that is going on.  If it happens in form_activate,
maybe it happens also in some other special circumstances.  I am passing
recordset variable around, making calls to COM to instantiate Excel object
types and subtypes...

Thanks!


Quote:
>Don't know if this applies but 'ive found that if you
>instanciate an object in the Form_Activate the IDE will
>not create extra copies(no idea why) but when runing
>an .exe of the same code every time the form activates a
>new instance of the object is created.
>Drove me crazy until I figured it out

>mike Wilson



Mon, 06 Sep 2004 18:54:36 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Hello all together,

Ive read just a few things from this thread, but I would highly recommend
NOT to use error handling for normal program execution (e.g. test
explicitely for contitions that you want to handle and use error handling
for things your code can not handle) and use an automated insert of standard
error handling code. We are using a self developed vb plugin to insert error
handling thike this :

----------------------------------------------------------------------------
--------
Public Sub AdvFTSearchPage(oHtmlSendString As String, iSessionID As String)
On Error GoTo AdvFTSearchPage_ERROR '//~AUTO~// OnErrorStatement

' ///////////// place Your code HERE /////////////

Exit Sub                                                    '//~AUTO~//
ErrorHandler
AdvFTSearchPage_ERROR:
'//~AUTO~// ErrorHandler
   Select Case OnError(Err.Number, Err.Description, Erl, Err.LastDllError,
Err.Source, constComponentName, "AdvFTSearchPage")    '//~AUTO~//
ErrorHandler
       Case 0: Resume                                          '//~AUTO~//
ErrorHandler
       Case 1: Resume Next                                 '//~AUTO~//
ErrorHandler
       Case 2: Exit Sub                                         '//~AUTO~//
ErrorHandler
       Case 3: RaiseEvent PleaseTerminate            '//~AUTO~//
ErrorHandler
   End Select                                                  '//~AUTO~//
ErrorHandler
End Sub
----------------------------------------------------------------------------
--------

OnError is implemented in a global module and will display a user friendly
dialog box describing what kind of error and where it occures. It will ask
the user what to do next - retry, continue with the next step, leave the
procedure or end the application.

The undocumented function "Erl" returns the line number (we also insert line
numbers automatically for all code) which throws the exception.
constComponentName is a module level string constant that contains the
module name (e.g. clsMyClass).

This way we can (even when running in compiled code) tell what error was
caused by which line of code.

Many messages in this newsgroup are just telling "having an error I don't
know where" and than asking for advice. It would be much easier if You try
to implement a similar strategy to trap errors in Your programs. Then You
can avoid many hours of searching, implementing tracking functions of
writing log files just to find out what object cannot be created or where
the error happens.

Tell me if You need the component.

CU,

Sven



Tue, 07 Sep 2004 17:07:39 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug
Yeah Sven,
        I'm always ready to try something that might make life easier.
        Do you have a URL for this or can you e-mail it to me.

    Thank in advance

                    Matt



Quote:
> Hello all together,

> Ive read just a few things from this thread, but I would highly recommend
> NOT to use error handling for normal program execution (e.g. test
> explicitely for contitions that you want to handle and use error handling
> for things your code can not handle) and use an automated insert of
standard
> error handling code. We are using a self developed vb plugin to insert
error
> handling thike this :

> --------------------------------------------------------------------------
--
> --------
> Public Sub AdvFTSearchPage(oHtmlSendString As String, iSessionID As
String)
> On Error GoTo AdvFTSearchPage_ERROR '//~AUTO~// OnErrorStatement

> ' ///////////// place Your code HERE /////////////

> Exit Sub                                                    '//~AUTO~//
> ErrorHandler
> AdvFTSearchPage_ERROR:
> '//~AUTO~// ErrorHandler
>    Select Case OnError(Err.Number, Err.Description, Erl, Err.LastDllError,
> Err.Source, constComponentName, "AdvFTSearchPage")    '//~AUTO~//
> ErrorHandler
>        Case 0: Resume                                          '//~AUTO~//
> ErrorHandler
>        Case 1: Resume Next                                 '//~AUTO~//
> ErrorHandler
>        Case 2: Exit Sub
'//~AUTO~//
> ErrorHandler
>        Case 3: RaiseEvent PleaseTerminate            '//~AUTO~//
> ErrorHandler
>    End Select                                                  '//~AUTO~//
> ErrorHandler
> End Sub
> --------------------------------------------------------------------------
--
> --------

> OnError is implemented in a global module and will display a user friendly
> dialog box describing what kind of error and where it occures. It will ask
> the user what to do next - retry, continue with the next step, leave the
> procedure or end the application.

> The undocumented function "Erl" returns the line number (we also insert
line
> numbers automatically for all code) which throws the exception.
> constComponentName is a module level string constant that contains the
> module name (e.g. clsMyClass).

> This way we can (even when running in compiled code) tell what error was
> caused by which line of code.

> Many messages in this newsgroup are just telling "having an error I don't
> know where" and than asking for advice. It would be much easier if You try
> to implement a similar strategy to trap errors in Your programs. Then You
> can avoid many hours of searching, implementing tracking functions of
> writing log files just to find out what object cannot be created or where
> the error happens.

> Tell me if You need the component.

> CU,

> Sven



Tue, 07 Sep 2004 22:27:11 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

Quote:

> I have a rather large application that I still maintain in VB5.  It's a very
> complex app, but I have only one problem:

> There is an error the crops up in the compiled stand along version, but not
> in the same project when I run it inside VB and try to find the error with
> the de{*filter*} tools.  (It's "compiled"  not all the way native machine code,
> but "compiled" to exe with Make command, still using the VB runtime -- it
> has lots of complex form redraws and such, so this was the way to go.)

> Anyway, I have found before that there are sometimes minor differences in a
> "Make-ed" version, compared to the behavior in the development environment.
> I've had problems before with a fully tested and debugged project, that
> works differently (with a bug) after it was make-d.  Little things, that
> crop up when pushing the code real hard.

> Anyway, can anyone give me any suggestions as to how to proceed?  Have other
> people had this kind of thing happen?

> I know that's pretty vague question without specifics, but does anyone have
> any comments?

This may or may not have anything to do with your specific problem, but
one time I encountered a situation where optimization when the program
got built changed its behavior.  I had a compound statement in an "if"
and depended on side-effects in one piece of it, but the statement got
optimized away, so that effectively it was behaving like a C++
conditional with shortcut evaluation.

Debugging an executable sucks, but really the only effective way to do
it is by throwing up a bunch of MsgBox calls.  I've had to do that
before to debug problems related to the destination environment (my
development environment worked fine but there was some sort of issue
with getting the program set up right).



Wed, 08 Sep 2004 03:42:26 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

Thanks, Craig. It is a chore putting in the msgbox s, but we get stuck with
it.

I long for the old days in Turbo Pascal when a true executable could raise
and error that you could reload into the compiler, along with the source
code, and actually find the source line.

Course those programs didn't have much to do, the os was primitive... no
wonder it was easy.

cheers,
David



Fri, 10 Sep 2004 23:30:59 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

Quote:

> Thanks, Craig. It is a chore putting in the msgbox s, but we get stuck with
> it.

> I long for the old days in Turbo Pascal when a true executable could raise
> and error that you could reload into the compiler, along with the source
> code, and actually find the source line.

Here's a thought.  I haven't tried doing this, but supposedly it works.
Set the flag in VB to generate symbolic debug info.  This will generate
a pdb file.  Then, you should be able to do a symbolic debug on your
exe file using either WinDbg or the VC++ de{*filter*}.

The Microsoft debug tools should be a free download, but I don't have
a link to them.

Since this will involve debugging optimized code, it may be
interesting, and I'm guessing that watches on non-basic types would be
heavily restricted.



Sat, 11 Sep 2004 04:38:41 GMT  
 compiled VB proj exhibits run time error, but not in IDE/debug

Quote:


> > Thanks, Craig. It is a chore putting in the msgbox s, but we get stuck with
> > it.

> > I long for the old days in Turbo Pascal when a true executable could raise
> > and error that you could reload into the compiler, along with the source
> > code, and actually find the source line.

> Here's a thought.  I haven't tried doing this, but supposedly it works.
> Set the flag in VB to generate symbolic debug info.  This will generate
> a pdb file.  Then, you should be able to do a symbolic debug on your
> exe file using either WinDbg or the VC++ de{*filter*}.

> The Microsoft debug tools should be a free download, but I don't have
> a link to them.

> Since this will involve debugging optimized code, it may be
> interesting, and I'm guessing that watches on non-basic types would be
> heavily restricted.

Having just tried doing this with WinDbg, I can confirm the following:
- It works.  I was able to step through my VB code in the de{*filter*}.
- It's clunky.  I had a lot of trouble breaking into VB (rather than
  system) code.
- It's heavily restricted.  No GUI control of setting the next
  statement.  Only primitive numeric types work correctly, although
  strings are at least mostly manageable.  Forget object variables,
  though.

I may try in the VC++ de{*filter*}, which I would hope would be a bit
friendlier.



Sat, 11 Sep 2004 05:21:18 GMT  
 
 [ 16 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Run-time error 429 in exe not in IDE

2. IIS app runs compiled, but not from IDE

3. IIS app runs compiled, but not from IDE

4. Run time error only when compiled runs

5. Error in Compiled Program but not in IDE...

6. VB5 - error in compiled EXE does not happen in DevStudio debug mode

7. Multilanguage Debugging in VC IDE and VB IDE

8. Multilanguage Debugging in VC IDE and VB IDE

9. add new item to a proj at run time

10. VB form size in IDE run-time different from compiled EXE run-time...Why?

11. No Debug option on Run-Time Errors?

12. VB 6.0 run-time error 48 - File not found: Kernel

 

 
Powered by phpBB® Forum Software