ZhEnglish has a bug when acquiring the keys

BT bug is closed, so I assume there was some sort of misunderstanding and there was no bug. Correct?

Re-open and give more details if necessary.

We circumvented the bug with brute force. The whole module is ignored with this code:

if ( name() == QString("ZhEnglish")) { qWarning("Module ZhEnglish is buggy and will not be loaded."); return m_entryList; }

This has been there for some time, it checked if the module version was 0.5, but the module is now 1.0 and the bug is still there so Martin closed it by removing the version number check.

Here is some more text from our bug tracker:

"Testing this module with GnomeSword reveals that it creates a loop when
acquiring the keys. Nothing we can do about it, I think, because we have
our own way of handling the keys. GnomeSword is still usable but only by
editing the key directly, not by using the list (which is created nine
items at a time if I can interpret the UI right)."

The loop will be noticed in GnomeSword if you go to the last item in the popup list many times. At some point (quite soon) it starts from the beginning again.

We have basically this code:

do {
qDebug() << "add entry:" << my_module->KeyText();
m_entryList->append(QString::fromUtf8(my_module->KeyText()));
(*my_module)++;
} while ( !my_module->Error() );

This will be looping forever, giving output:

(BibleTime 2.0.beta2) Debug: add entry: 1
(BibleTime 2.0.beta2) Debug: add entry: 1
(BibleTime 2.0.beta2) Debug: add entry: 1

(Debug is printed by qDebug())

I spent a while looking into this and can't find a good solution. I suspect an API bug exists. For some reason, the sort order when writing the module differs from the sort order when reading. (I.e., our string comparison function(s) is/are behaving differently.)

Re-importing does not solve the problem because the keys themselves are somehow not being sorted in the same way.