This can happen if our extras menu item is selected when the window is already open but not at the front. Previously, it would come to the front but the highlighting would not update to make it look active.
This seems like a reasonable trade-off between speed of retrieving one page and number of pages needed to see lots of results. Many specific searches will return fewer results than this anyway.
This resulted from indexing off a pointer with signed int index values, which in some cases causes ORCA/C to generate code that only works within 32k bytes of the pointer base. The fix is to use unsigned index values, which results in indexing working correctly up to 64k bytes.
We have to wait through two cycles of the Finder's event loop before asking for it to be opened. Doing it earlier may cause the Finder to crash, presumably because it hasn't registered that a new disk has been inserted and updated its internal data structures accordingly.
This provides a less flickery display, and arguably cleaner code. The outlines should perfectly match the look of the stock "default" buttons, although obviously this wouldn't work right if their design was ever changed.
This should give more consistent results if queried multiple times (which will be useful once we allow loading more results), and cause multi-disk series to appear together. It should also make the keyboard binding for the list control work more sensibly.
This could cause Marinetti to return more data than it should, starting with valid data but then including corrupt data.
The workaround I'm using is to have Marinetti return a new handle and then copy the data out of it, using the size of the handle as the true size of the data that was read. Because of details of how Marinetti works, that size is correct.
This should work around an issue (possible Marinetti bug?) where a portion of the beginning of the response could be erroneously repeated at the end of it.
