Thread: Not the normal looping question...

I have a situation, I'm hoping someone has seen before...

My program runs fine. (That's a first!--LOL)

The program is essentially a class to handle an inventory file. It has a menu with four options to display data by four distinct items. Each is a member function of the class. The menu is also a member of the class. And they all work fine.

Here's the problem:

In attempting to loop the progam until the exit option is chosen, I have tried looping it in "main" by instantiating the class and calling the menu in a loop... I have also tried just re-calling the menu after the last function called finishes displaying... all to no avail.

What happens is, everything works fine the first time thru, but upon the user changing menu choices to search via a different piece of data... all searches come back "not found."

I initially thought I was losing my indexing arrays, or there was junk in the stream when the user enters search items, but neither is true. I "cout" the arrays and all needed variables within the functions to debug it, but they are all 100% correct.

So... my current "stupid question of the day" is:

Has anyone seen anything like this? I can post code, but it's long and ugly, and is running fine on it's own... only when a user changes menu choices does it choke on me.

Thoughts?

>>My program runs fine.
>>When a user changes menu choices it chokes on me.
When in the future you become a billionaire from your prospering software company, remind me not to buy any of your programs!

How is the choice stored, and how do you do your "search", and are you dynamically allocating/deleting anything, are you setting pointers to NULL (or 0)? Relevant code?

In short: What does the program do, and how does it (try to) do what it does? Help us help you

Okay... I warn you, the code is verbose and not pretty. LOL.

Also, the test file must be present (inventory.dat).


You can search by Inventory Number: 000, 111, 222, etc.

Or, by Inventory Name: ones, twos, threes, etc.

Inventory Codes are: ONE, TWO, THR, etc.

This should be enough to see where I'm screwing up.


I didn't mean to be vague, but, because the code works without any loops... I didn't think it was needed. This version of the program has the looping done by caling the menu at the end of each display function.

Also, it "couts" all the arrays and searchable variables in each function, so you can see what they hold. (this is for my debugging only).

As for your questions:

The indexing arrays are loaded within the constructor. They consist of a sequential number (so I can position the seekg pointer within the binary file.) and the searchable item. These arrays are dynamically allocated.

They are each sorted and searched for user specified record and output from the "target," on (ascending).

The actual DAT file is opened before, and closed after each display. Yes, I reposition the pointer using seekg and my indexing array (location * record size).

If I change the loop, to a "for" or "while" (either unending or incremented) in main (and remove the menu call at the end of each display function)... it does the same thing. Looks to me like the correct data is there, but something is definately wrong. (Aside from my sloppy coding!).

Thanks:: Jazz

Sorry... it wouldn't let me upload a DAT file.

Here it is, renamed TXT.

(It needs to be named "inventory.dat" for the program to run.)

I hope this works... Windows was not happy renaming this file.

I haven't actually checked your code yet since I need to leave right now, but a quick suggestion: Are you just reading until eof() and are you using the same ifstream/fstream object to do the reading each time? If so, you need to call clear() after reading the file through, otherwise the EOF error flag will still be there when you try to open the file again.

Hope this helps!

Originally posted by Hunter2
I haven't actually checked your code yet since I need to leave right now, but a quick suggestion: Are you just reading until eof() and are you using the same ifstream/fstream object to do the reading each time? If so, you need to call clear() after reading the file through, otherwise the EOF error flag will still be there when you try to open the file again.

Hope this helps!

No, it is not until EOF. The indexing array is sorted, searched, and then I print all records (>=) the specified target, if found. (using seekg and the record # * record size--it's a "fixed length" binary file--so it moves around the file as needed.)

Yes it is the same stream, but I thought I adequately positioned the clear(), right after the file is opened. It never makes it to this point, as the file is opened only upon "finding" a match in the indexing arrays. Odd part is, I see what the arrays have, and what the search target is, and they match... I just don't understand how the functions are working on their own, but by attempting to change the search criteria in the loop is throwing it off... especially, when the very same search (when not looped) will find it.

I'm missing something very simple I'm sure, but at this point... I'm blind to the logic as I know what it should be doing... but isn't. LOL.

I already implemented what you have suggested. (Each function shows--outputs--what was passed to it, and the arrays are displayed after being sorted.)

The information contained in them are 100% correct.

Originally posted by Bubba
Hmm...very odd.

Will look into it.

I appreciate everyone having taken the time... it's baffling me still.

(NOT Too mention FRUSTRATING me still! LOL.)

If you "run" the program, and that DAT (test file) doesn't work for you... drop word and I can shoot a good copy via email for anyone interested. When I renamed it... I wasn't sure if it stayed correctly formatted.

::Jazz

Mmm, yummy. I stuck it in MSVC and ran it; the moment it started, I got a debug assertion error. Running throught the debugger, it gets an access violation somewhere in the Inventory constructor (but doesn't crash because MSVC pads arrays (?) when debugging). When Inventory's constructor ends, a function gets called (by MSVC?) to check the memory and see if the padding bytes got changed, which they did I suppose, because that's where it threw an error.

So in short: Take a look at the constructor, make sure you're not overrunning your array bounds as Bubba said.

Hope this helps