Bug:Search Stock w/Subsequent Serch Doesn't return 1st found

Make comments, ask questions, or just complain about the software on this site. Or comment on any educational software.
Please note that by clicking on links that may appear in these posts that you may be leaving the Dale Harris Educational Software website and that the content of those sites is the sole resposibility of the authors of those sites.

Moderators:daleadmin, Dale Harris, Alan, Andrew

User avatar
Forum Regular
Joined:Mon Mar 06, 2006 11:19 pm
Location:Broward County, Floriduhh
Bug:Search Stock w/Subsequent Serch Doesn't return 1st found

Post by brucef2112 » Thu Mar 06, 2014 12:16 pm

Version 7.1g with stock table enabled.

I was doing some house keeping in the stock table and came across a quirky feature of the Search tool.

If you use the [F1] Search to find a partial match, then end the search (hitting [ESC]) to return to the stock table, and do the same search again ([F1] Search), it will not take you to the original first found. It instead takes you to the second match. And each time you repeat a fresh search, it will continue to find the Nth found relative to the number of times you repeat.
The only way to get the Search to find the first instance is to return to the main menu and go back into the stock table and then do the search.

Example: My stock table contains items with descriptions of 'SUNFLOWER SEEDS', 'SUN DRESS', 'SUNNY D JUICE' in this order and scattered throughout the stock table.
Do a search for 'SUN'. [F1] Search > 2.Description > type SUN > hit [ENTER].
The search will move to the row containing 'SUNFLOWER SEEDS' (the first match in the table).

Now hit [ESC] to exit the search and return to the stock table at the 'SUNFLOWER SEEDS' row.
(I made my updates to 'SUNFLOWER SEEDS' and now I manually browsed the table. I remind myself of another change I want to make to 'SUNFLOWER SEEDS' so I do the search again expecting to return back to the first 'sun' which should be 'SUNFLOWER SEEDS'.)

Now hit [F1] Search > 2.Description > type SUN > hit [ENTER].
Instead of going to the first 'sun' it now returns the second 'sun' which is 'SUN DRESS', not the first in the table which is 'SUNFLOWER SEEDS'.

To test this, I found each repetitive search done in this fashion, will continue to find the Nth found, relative to the number of times the search is executed, or until it reaches the end of the table and wraps back around to the top of the table again.

It seems that the SEARCH's 'last row found' location is cached even after exiting the SEARCH TOOL and it continues to use the 'last row found' as if the 9. Repeat Search feature was used while doing the Search by while still in the Search mode.

In my example above, where I hit [ESC] to exit the SEARCH TOOL, I'd expect that when returning to the SEARCH TOOL that the search would be a 'fresh' search from row 1 and not a cache search row number of the 'last row found' to start the search.

This is demonstrated by the following;
Do the 'sun' search as above. THEN try to search for 'junkxxx'(not in my table) and then return again to do the 'sun' search. (example search 'sun',get 1st, [esc] and now search 'junkxxx', get nothing, [esc] and now search again for 'sun', get 2nd.)

I ALSO TESTED BY ADDING SEVERAL ITEMS AS 'JUNKXXX number ONE' AND 'JUNKXXX number TWO', in this order but scattered into the table. ('Junkxxx number ONE' is serveral rows above ''SUNFLOWER SEEDS', the second somewhere near bottom)
Then again tested using the steps above. The result is it finds ''SUNFLOWER SEEDS' then finds 'JUNKXXX NUMBER TWO' and then ''SUN DRESS'. WHAT HAPPEN TO FINDING 'JUNKXXX number ONE'?!?!?!

All other attempts continue to have the same outcome as outlined above.

The only way to get a fresh search to start from row 1 is to exit the stock table, return to the stock table and then search again.
This clears the search's 'last row found' and it begins again at the top of the table.

Everyone, feel free to test and report back.


They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Benjamin Franklin - Historical Review of Pennsylvania, 1759

Post Reply

Who is online

Users browsing this forum: No registered users and 11 guests