[Bug] [Crash] Resources in Series Not Updated on Pane Change After App Open
[Background] I have configured my BHS and my NA28 in a series that I've called "original_languages" so that when I type Matt 1 into my BHS, it switches to my NA28 and opens accordingly. This works flawlessly. I also have multiple resources (e.g., ESV) that are displayed in the same tab via "multiple resources display," which works flawlessly—following wherever the main original language goes. I have also configured this tab with link letter "C" so that I can have another tab follow it (this tab has NET2, NIV, CSB in multiple resources display). [/Background]
[What Happens] In the setup described above, when I am in the English translations tab (with NET2 &c), if I switch testaments in the English tab such that the original language resource on the other tab should also switch, and then I switch to that original language tab (so that the original language resource attempts to locate, e.g., Matt 1 in my BHS), Logos winsomely handles this—usually. However, if I open the application (remembering the layout it closed with, setup as above) and the English translations tab has focus, then when I navigate to a different testament, the original language tab does not follow (see screenshot below). In this case, if I try to change the tab to original language, then the entire Logos Application force closes without any message or error displayed. This is repeatable. [/What happens]
[What I expect to happen] I anticipated that (1) with my setup described in "Background" and (2) with my chain of actions described in "what happens" that my original language tab would (1) evaluate the reference and (2) ensure that any resources in a series are properly switched before (3) attempting to navigate that pane to the current reading location. In other words, I expect the tab change and series switch to work on a fresh open just like they work when I've been using the application for some time. [/What I expect to happen]
[My Debugging Thoughts] I have the impression that upon an open of a saved layout (mine is resources last open) that only visible tabs are loaded/refreshed, and that subsequently "open" tabs are loaded refreshed as they are activated (probably for efficiency, load time, etc). I think this is part of what is causing the crash because the background tab is unloaded, it doesn't switch properly like it would if both were already loaded (or just opened from scratch). It would appear that the program needs, on tab change, to evaluate whether the activating tab is in a loaded or unloaded state, and if unloaded, load it first before checking series, then finally turning to the tab's current reference. This is my best guess at what is happening, without any recourse to the source or operational flow. [/Debugging thoughts]
Hopefully this helps someone isolate the source of the crash. With joy in Christ,
—dc
Comments
-
In this case, if I try to change the tab to original language, then the entire Logos Application force closes without any message or error displayed. This is repeatable
I can reproduce as follows:
- Setup in a Floating Window
- you forgot to mention this
- used SBLGNT/LHB as my "original_language" series
- used that with NABRE as multi-resource
- used ESV with LEB as the multi-resource in the "English translation" tab
- used link letter "B" between tabs
- Main Logos window is named i.e. used a named layout
- Performed testament switches as described
- Entered an OT passage in the "English translation" tab (LHB displayed in the other tab)
- Restarted Logos
- Entered a NT passage in "English translation" tab
- LHB did not switch to SBLGNT
- Logos crashed after I clicked on the other tab
NOTE: With the tabs in the main window there were no issues after a restart.
Dave
===Windows 11 & Android 13
0 -
- Setup in a Floating Window
- you forgot to mention this
NOTE: With the tabs in the main window there were no issues after a restart.
Thanks for confirming Dave! However, I do wish to point out that—on my end—the issue occurs in the main window as well as floating, so I did not forget to mention it, as that variable was irrelevant from my perspective (see below).
0 -
Hi David,
This looks like a crash that was fixed during the 9.15 Beta cycle. So you should get a fix for it soon. This is based on Dave Horton's crash logs, so if your crash is actually a different crash (we would need your logs) then we might need to try to recreate things further. Please let us know if this is fixed when you get 9.15 installed.
0 -
Thanks for confirming Dave! However, I do wish to point out that—on my end—the issue occurs in the main window as well as floating, so I did not forget to mention it, as that variable was irrelevant from my perspective (see below).
It is not irrelevant to those trying to reproduce your issue! We need all the information.
Another point I stated explicitly was that I used a named layout. You said "if I open the application (remembering the layout it closed with, setup as above)" --> so how did you save the layout before closing Logos?
Dave
===Windows 11 & Android 13
0 -
It is not irrelevant to those trying to reproduce your issue! We need all the information.
Another point I stated explicitly was that I used a named layout. You said "if I open the application (remembering the layout it closed with, setup as above)" --> so how did you save the layout before closing Logos?
Brother, I am thankful for you and for your assistance. I meant no disrespect. What I meant to communicate is that I had not specified the window type (floating | primary) because I had experienced the crash in either, so I didn't regard it as a necessary data-point to reproduce the crash (i.e., the crash is not contingent on the window type wherein the error occurs). I agree that I could have mentioned that I knew this.
Thank you also for specifying the naming of layouts. I am not using a named layout (which, alongside your test where you named yours, proves that the crash is not contingent on the naming of the layout). I have the "At Startup Open to" setting configured to "Most Recent Layout - Any." Since I only use the desktop version of Logos on one computer (Win 10; Logos 9.14.0.0026), I functionally remember this setting as "it opens where I left off."
I conducted a new test, and I confirmed a new data-point (the series tab must be backgrounded, or not visible, otherwise it refreshes properly).
Conditions:
- blank layout (unnamed throughout)
- open NA28 in tab (which is in series "original_languages" with BHS)
- open NET2 in a tab over top of the NA28 (which is in multi-resource view with other english translations)
- link NA28 tab to the NET2 with a link letter ("E" this time, the letter itself is not important, but the linking is)
- I navigate to Genesis 1, and the background NA28 switches to BHS properly to load Gen 1.
- With the setting "At Startup Open to" configured to "Most Recent Layout -Any", I close Logos with the NET2 tab on top.
- I reopen Logos, which because of the setting just mentioned, opens those two overlapping tabs with the NET2 still on top.
- I navigate to Matthew 1 in the NET2 tab. NOTE: The BHS tab does not follow.
- I select the BHS tab, and the application crashes.
0 -
-
Please let us know if this is fixed when you get 9.15 installed.
After updating to 9.15 this morning, I have confirmed that the crash is fixed. The new behavior presents in the same way (i.e., the backgrounded tab does not appear to update); however, when that tab is selected it does what I described in my original post—updates the series resource before navigating to the reference, thus avoiding the crash!
Thanks Logos team!
0
