Bug: Vine's Indexes give wrong information

First: A crash

Opened Vine's to G5467 and got a Parallel Resource set (PRS) that included DBL Aramaic, DBL Greek & DBL Hebrew. I clicked on DBL Aramaic and crash!

7673.Logos4VineCrash.zip

Tried this with G2367 and again G5467 but DBL Aram opened to the title page. Next time it crashed on G2367:

7888.Logos4Crash.txt

Why is PRS picking up an Aramaic index from Greek Strong's? H5288 is in the drop-down with G5467/G2367 (?) and when DBL Hebrew is selected in the PRS that's where it goes!

 

Second: Wrong Index Info

After using PRS in DBL Greek to get to Vine's I noticed the following in RHS pane & compared to a copy of Vine's in the LHS.

The Index info on RHS comes from DBL Greek!

This Index Information mix up also occurs in using a PRS to go from Vine's to DBL Greek.

 

Dave
===

Windows 11 & Android 13

Comments

Sort by:
1 - 1 of 11

    I'm not able to reproduce any of these on my system; not the crash, the unexpected resources on the PRS list, or the variant resource information.

    Regarding the second issue, to help me try to reproduce, do you have a user-defined Collection that includes these books with PRS enabled? Are there any advanced prioritization limits configured for Vine's or the DBL resources in Library?

    Dave, I was also able to reproduce the index info and found several other lexicons keyed to DBL Greek included the Theological Dictionary of the New Testament and the Complete Word Study Dictionary New Testament.      

    image

    It seems like DBL Greek uses the Goodrick/Kohlenberger numbering system.  A system that came into use after 1990 and is an improvement  upon Strong's numbering system.  The only difference between DBL Greek and Greek GK is when you have multiple definations under a Greek Word.  As far as I know when you use Parallel Resources the other resources do not jump to the 2nd defination.  So it seems like several lexicons were tagged with both numbering systems.   

    The 3 systems are:

    1.  DBL Greek

    2.  GK Greek- Goodrick/Kohlenberger numbering system

    3.  Strong's Greek       

    It seems like DBL Greek uses the Goodrick/Kohlenberger numbering system.  A system that came into use after 1990 and is an improvement  upon Strong's numbering system.  The only difference between DBL Greek and Greek GK is when you have multiple definations under a Greek Word. 

    I hadn't been aware of the DBL #1, #2 indexing for meaning! But it doesn't seem to be used when keylinking from a resource eg. ESV reverse interlinear

    Dave
    ===

    Windows 11 & Android 13

    Regarding the second issue, to help me try to reproduce, do you have a user-defined Collection that includes these books with PRS enabled?

    Sorry ... I was using my Lexicons collection :-

    image

    The crashes came from selecting DBL Aram in Lexicons.

    Are there any advanced prioritization limits configured for Vine's or the DBL resources in Library?

    image

    Concise Heb & Aram Lexicon of the OT

    Vine's (not restricted)

    Dave
    ===

    Windows 11 & Android 13

    Sorry ... I was using my Lexicons collection

    Thanks, I'm able to reproduce the crash after creating that collection and will submit a bug report.  I don't have any advanced prioritization limits.

    Update:  This crash will be fixed in 4.0d (beta 3). 

    Update:  This crash will be fixed in 4.0d (beta 3). 

    Melissa

    The crash is fixed but the aspect of displaying those resources still exists. Can you confirm that the two bug numbers in the wiki problem report cover both aspects?

    Dave
    ===

    Windows 11 & Android 13

    The crash is fixed but the aspect of displaying those resources still exists. Can you confirm that the two bug numbers in the wiki problem report cover both aspects?

    The first bug case was for the crash, which was fixed. The second bug case was for the wrong indexes in Vine's About resource info, and that was also fixed in 4.0d B3.

    The display of the invalid parallel resources won't be fixed at this time. In order to only show resources that definitely contain the reference, we would have to open all of the resources before showing them, which is unnecessarily slow.

    I will edit the wiki report to reflect that both of those cases were fixed in 4.0d B3.