I hadn't thought of that...

"Why does the pairings window have that long break between the last pairing and the first pairing?"
The long answer is actually pretty involved. The scrolling system is based off of a previous program which was used in the upper midwest until this year. I built the RTools system initially in the same way as that other program.

If you visualize the scrolling window as a physical window, the scrolling system could be seen as a long sheet of paper behind that window. Every time it moves, the sheet of paper is just moving up until all the information is displayed. Then, the paper is reset to the top and scrolls down again.


So, why doesn't it do it? Because I haven't thought of it, and nobody ever brought it up! Sounds like a good idea, and after doing some implementation to see how this looks, it is most likely a much better setup.

The adjustment that needs to be made is to (using that analogy again) tape the top of the paper to the bottom, and turning it into a looping piece of paper. 2.1.28 has made the adjustments made to add this feature. (2.1.27 also had it, but the implementation was faulty)

Update (09/18/10)
2.1.29 is out to fix a couple bugs brought in with earlier alphas. There is a capitalization function in the program for names that was getting some new text strings sent to it, and those new strings were causing problems in standings by pods printout. Also fixed is an issue that came about with some of the EPIC refactoring, which caused byes to show up again in printed pairing functions. (the byes were checking for a specific signal value in the DCI number as a trigger for not showing, and those values were being overwritten by the new code that ensures DCI numbers will always be on printed result slips)