Prev: check record size before update
Next: Slider math
From: C. Kevin Provance on 19 Feb 2010 20:54
<a(a)b.com> wrote in message
news:v18un5dnv2apsh63otrhcv7f0h8mbh1m20(a)4ax.com...
|
| yes, i want the actual code.
|

Can't be done.

You could copy each line of your code into a string and pass that string to
your error handling routine...but not only would that take forever and bloat
the size of your app, but anyone with a hex editor could view your app's
code.

If you know your app and how your code works, a reference to the line number
should be all you need to debug it.


From: Helmut Meukel on 20 Feb 2010 04:45

<a(a)b.com> schrieb im Newsbeitrag
news:v18un5dnv2apsh63otrhcv7f0h8mbh1m20(a)4ax.com...
>
> yes, i want the actual code.
>
> If I'm on the road or away from my computer and I get a support email
> on my blackberry or something, which lists only the line number, it
> doesn't help me much. If I know the error source, I can perhaps think
> of what might be happening.
>
> looks like i'll have to do it the way i propose...make txt files of
> the .frm's and do local lookup based on the form name and error line
> number. Then send that along.
>
> thanks for the replies.
>

Why this way around? Seeing the actual line of code where the error
occurs may help, but more often you'll need the context, the last 2 or
5 lines before. So I would put the source files with the line numbers
onto an USB-Stick or Memory stick or whatever your "blackberry or
something" supports and then look it up with the text editor of this
device. Or - with a blackberry - download the data from a server.

Helmut.

From: Daryl Muellenberg on 20 Feb 2010 12:43
As others have stated, getting the line number is the best you can do. I
have been using a product called VB Builder from GridLinx. It has functions
to make it easy to add error handling to your procedures which will report
the line number, error description, module and procedure name where the
error occured. The build function will make a copy of your original source
code and add line numbers to the executable lines code and keep it in a
separate 'build' folder. That way you can keep your original source code
clean and free of line numbers and not have to worry about renumbering or
inserting new line numbers when you modify your code.

Just make sure you take a copy of the build source code with the line
numbers for reference.

From: Nobody on 20 Feb 2010 13:53
"Daryl Muellenberg" <dmuellenberg(a)comcast.net> wrote in message
news:A0B6FE1F-534E-42BE-9261-C047521A3D5A(a)microsoft.com...
> As others have stated, getting the line number is the best you can do. I
> have been using a product called VB Builder from GridLinx. It has
> functions to make it easy to add error handling to your procedures which
> will report the line number, error description, module and procedure name
> where the error occured. The build function will make a copy of your
> original source code and add line numbers to the executable lines code and
> keep it in a separate 'build' folder. That way you can keep your original
> source code clean and free of line numbers and not have to worry about
> renumbering or inserting new line numbers when you modify your code.
>
> Just make sure you take a copy of the build source code with the line
> numbers for reference.

I checked the assembly output of how VB6 adds line numbers, and impact on
performance. I found that VB adds something like the following pseudo code:

Some32BitsGlobalVar = 100

Where "100" is the line number, and in assembly, it looks like this:

mov DWORD PTR [12345678], 100

This probably takes one or two CPU clocks, I am not sure. So it doesn't add
much unless you have a tight loop and performance is important.



From: Phill W. on 22 Feb 2010 08:18
On 19/02/2010 23:41, a(a)b.com wrote:

> yes, I want the actual code.

Not unless you write code like

17 sCode = "hFile = FreeFile()"
18 hFile = FreeFile()

19 sCode = "Open sFile for Output as #hFile"
20 Open sFile for Output as #hFile

> If I'm on the road or away from my computer and I get a support email
> on my blackberry or something, which lists only the line number, it
> doesn't help me much. If I know the error source, I can perhaps think
> of what might be happening.

I would suggest that you know your [own] code immensely well.

This is the kind of thing I used to be able to do when I was a
"hobbyist" coder and when the programs were mine and mine alone. Now I
work in a sizeable team of Developers, any number of which could be
working on any particular application, and I just can't maintain that
level of intimacy with "my" codebase any more.

Also, I would argue that the code itself is not enough for any kind of
real diagnosis (unless the code itself is completely rubbish and would
have blown up anyway).

"Bad Code Breaks. Good Code get broken (by Bad Data)."

You need to know /which/ function failed (the line number is a bonus but
by no means essential) and the /data/ with which that function was called.
Then you need to know which /other/ function called the one that failed
and with what data and so on, all the way back up the chain.
Yes; it's a pain having to add all the instrumentation code to keep
track of this, but it makes for far more effective diagnosis.

(Brace yourselves, all; 'N'-word coming...)

..Net goes /some/ way towards addressing this; its Exception class hands
you a Stack Trace of /where/ the problem occurred, but it still utterly
fails to give you the really /useful/ stuff - the scuzzy piece of data
that's taken your program down.

> looks like i'll have to do it the way i propose...make txt files of
> the .frm's and do local lookup based on the form name and error line
> number. Then send that along.

Now hold on a minute. Are you suggesting that you're going to ship
copies of all your source code to your clients, just so that you can
ship a few lines of it back to yourself in the event of an error?
If they've got all of that (and a kosher copy of VB) what do they need
you for, again? :-)

I would suggest that you continue to ship back the file name and line
number (a common enough diagnostic seen in 'C' programs) but keep the
source code with you but then:
How many code files are you going to have to carry around?
How are you going to ensure that you have the /latest/ ones? That
no-one else has made a change and not told you about it?

Just my tuppence-worth. ;-)

HTH,
Phill W.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: check record size before update
Next: Slider math