Application crashes after compilation

[Haakon Birkeland]

I'm not seeing this related to / caused by FF, but this is where I feel at home anyway.

I've got to computers I use for a little project, and they are running the exact same copy of Windows XP x64 (yeah I know I should have had two licenses). The FF and includes folder are duplicates from the good behaving computer, but there are still issues on one the other one.

The big difference between them are that one is running on Intel and the other is AMD.

During my work on the project yesterday, I had to run the executable manually as it always crashed when using compile and run from within FF. earlier I've experienced occational crashes, but today it's worse.

If I compile on the good computer, even using compile and run, it's all jolly good. While running the same executable on the bad computer, now fails even if executed manually â€" every time. If I compile on the bad computer, it runs fine on the other computer.

What's up with these issues on the Intel computer?!

Any (even wild) ideas I can pursue?!

[Haakon Birkeland]

My own suggestion, after reading about others crash issues;

#TOOLS ON
TRACE NEW "debug_trace.txt"

Now I have a clue where it seem to collapse for me, and that makes
somewhat sense so far as running the executable on a w7 machine
yields an empty ComboBox which is supposed to be filled from that
part of the application ...

[Haakon Birkeland]

Didn't find time to process it completely before I had to leave the office,
but it's narrowed down to a probable line of code where I'm parsing
through an array created with Line Input.

Although it still puzzles me why it totally works fine on one computer ...

[Paul Squires]

Sounds like some sort of array out of bounds error or null pointer.... maybe one processor is less forgiving than the other and triggering the GPF?

[Haakon Birkeland]

But in the other end of what I expected.

I traversed the array based on the assumption that it was 0 based â€" since I've not asked for arrays not to be,
but without further checking it seems that arrays created by Line Input is 1 based. Guess that's my lesson for
starting to use LBound and not only uBound when working with arrays ...

The finding actually explains the occasional oddity in the first item inserted into the ComboBox.

[David Kenny]

Keep looking for the real problem.

it seems that arrays created by Line Input is 1 based

You must be really frustrated, because you've been around much too long to believe what you just wrote (I've been there too  ).  Line Input, 1) does not create arrays, 2) isn't anything-based.  It is a just a function that expects a variable, or list of variables, to stuff data into. If the programmer provides an array variable for Line Input, then he must also provide the index.

There is no way that Line Input changed the array dimensions.  And the array must be dimensioned before you can put anything into it (or access it at all for that matter).

Can you provide a code snippet to look at?  We would be much better equipped to help if you did.

[Haakon Birkeland]

I was running only on my recollection of the first parts of the project, that didn't act up on me until now, thus have not been touched or visited since scrambled together. I only remembered creating an array and then using "Records to LineCount" to decide the dimension. Leaving the thought process at that, it's proven easy to "remember" that one never decided on the lower bounds. Guess that's another bump caused by being spoiled by VB/ASP and it's collections.

Checking it now I see you're absolutely right about me not following through with proper logic thinking. The lower bound is off course set at 1, I just didn't recall making that decision as I'm used to work with 0 based arrays. I can only assume it ended up like that cause some of the code was based on samples in the documentation.

Anyway, as indicated I located the offending line earlier today and got rid of the crashes and occasional misbehavior while filling the combo with data from the array.