BUG: Dragging a Search Command to the Icons Area generates a Null Exception Crash

For 4.0c B1, on Vista, I can get a Null Exception Crash as follows:

In the Command Box, type [ start reading aloud ] and press return (dont type the [ ] )

Result: Command works as expected.

Select the command text from command dropdown, and drag to make a new icon on the toolbar.

Result: A nice shiney new button to make it easy to read aloud. This is the correct usage of this feature!!!

Instead, select the command from the search portion of the dropdown, and drag to make a new icon. This is INCORRECT.

The Logos4 application crashes.

On restart there is a crash log, and a detailed log about Null Exceptions and a traceback of the stack.

On restart there is a new search icon, that opens a blank search window, buts it quite useless, and not the intended result.

This crash also prevents creating search icons for common searches, even assuming that the seach text was saved with the icon. It was this that I was intending to set up, but they crashed as above.

Workaround:

Drag the COMMAND TEXT, not the search portion, to make operational icons of commands, for anything other than searches.

Selected crash log:

Program Version: 4.0c Beta 1 (4.03.3.7605)
Windows Version: 6.0.6002.131072
Time: 2010-03-31 19:16:18
Installed memory: 3,070 MB
...
Error ID: 6892
Error detail: NullReferenceException: Object reference not set to an instance of an object.

System.NullReferenceException: Object reference not set to an instance of an object.
   at LDLS4.Panels.SearchPanel.SearchViewModel.get_SelectedMarkup()
   at LDLS4.Panels.SearchPanel.SearchViewModel.GetSettingsCore(PanelViewSettings settings, PanelViewSettingsPurpose purpose)
   at LDLS4.PanelViewModel.GetSettings(PanelViewSettingsPurpose purpose)
   at LDLS4.PanelViewModel.SavePreferencesCore(PanelViewPreferences prefs)
   at LDLS4.Panels.SearchPanel.SearchViewModel.SavePreferencesCore(PanelViewPreferences prefs)
   at LDLS4.PanelViewModel.SavePreferences()

Find more posts tagged with

Comments

Dave Hooton

Select the command text from command dropdown, and drag to make a new icon on the toolbar.

Result: A nice shiney new button to make it easy to read aloud. This is the correct usage of this feature!!!

Instead, select the command from the search portion of the dropdown, and drag to make a new icon. This is INCORRECT.

The Logos4 application crashes.

On restart there is a crash log, and a detailed log about Null Exceptions and a traceback of the stack.

Confirmed, Jim. But we need the full crash text and logs.

5621.Logos4Shortcut.zip

JimTowler

https://community.logos.com/discussion/comment/112189#Comment_112189

Sorry Dave, but I see little point in uploading 100k or so of logs off my system, from half a world away, on slow and expensive internet feeds, when its so easy to repeat the crash for whomever is going to look at this in due course.

I've decided I'm going to try and report quite specific details on any bugs, in ONE PLACE ONLY, and leave Logos to address it in due course. I'm starting to lose interest in being a beta tester when there is little feedback from Logos staff. So, I'm going to submit it here in the forums and then leave it be. This reply is already too long, so I'm already breaking my own rule.

It is my plan to spend more time USING v4 than reporting bugs on it.

I.E. I wish to study my bible and learn useful things. I already know more than I care about computers.

Thanks for confirming the bug.

(Also, I consider the contents of my logs to continue more than I wish to post in a public place. I editied it down on purpose, and with intent.)

Rosie Perera

https://community.logos.com/discussion/comment/112193#Comment_112193

Sorry Dave, but I see little point in uploading 100k or so of logs off my system, from half a world away, on slow and expensive internet feeds, when its so easy to repeat the crash for whomever is going to look at this in due course.

Since it has turned out to be easy for someone else to reproduce, you are correct that it's not necessary for you to upload your log file. However sometimes bugs are unique to one's configuration and prove to be very difficult to reproduce elsewhere, in which case logs might be helpful or even crucial. However you're free to wait and see if Logos requests them.

You can zip your log files down considerably in size which saves on the internet bandwidth.

Also, if you start up Logos fresh and just do the one thing that causes the crash, your log file will be much shorter. No need to upload logs that contain everything you were doing for the past half hour before Logos crashed. I can understand your privacy concerns.

I'm starting to lose interest in being a beta tester when there is little feedback from Logos staff.

I can understand your frustration. Do know that the time you've taken to report these bugs is appreciated, and hopefully you'll see some comments from Logos employees who have confirmed them at their end before long. The fact that you're prefixing your subject lines with "Bug:" is good. That makes it easier for Logos to find such posts. But in my experience, the comments from Melissa and George acknowledging my bug reports come in waves, several days apart. I suspect they have other roles in their jobs at Logos besides perusing the forums for bug reports from beta testers, so they can only come back here and catch up every few days.

I too get frustrated by the lack of response sometimes, but because I want to see Logos continue to improve for my benefit, I have maintained my commitment to attempt to report every bug I come across that I think hasn't been reported yet. (I'm behind on reporting them, though; I have a list of quick notes to myself to remind myself of what bugs I want to report; but writing up a good bug report with a description of the steps to reproduce the problem takes time, which I don't always have.)

JimTowler

https://community.logos.com/discussion/comment/112195#Comment_112195

Rosie,

Again, thanks for your detailed and considered reply.

In each case, for feedback I have posted to the Logos forums, I have spent a lot of time testing, attempting to repeat it, check if there appears to be a known report of fix already etc.

I guess my hope is that I could submit it to a single location. And from there ... a few things might happen.

1) Someone explains my misunderstanding, and it solved. Done deal. Closed.

2) Someone else reports a known fix, and all comes good. Closed.

3) Someone confirms that it fails for them too, Logos creates an Incident number and posts it back for tracking. In due course, its reported as resolved in build 12345, and as soon as I have that build, its fixed. Closed. Clearly, if its only a single person that has the issue, lots more details and logs may be required.

4) Its one of those things. No fix expected, or not any time soon, but there is still a number assigned if its actually something broken or a bug.

Clearly, there may well be a lot of talk about what was attempted, how to repeat it, logs required etc, depending on what the matter is.

Rosie Perera

https://community.logos.com/discussion/comment/112200#Comment_112200

Jim, I've just discovered something that I think you'll be very happy about. They do have bug numbers from their internal bug tracking database that they assign to confirmed bugs, and we can see what those bug numbers are! At least I'm guessing that's what this is all about:

This screenshot is from a bug I reported on the wiki way back in version 4.0 (Dec 15). The bug number field only shows up in Edit mode, as it's in a comment field (they don't want us mucking with it; as it's a private field for them alone to edit). This bug was confirmed by Logos developer Bradley Grainger two days after I reported it (I can tell who confirmed it by looking at the page's History), but it still hasn't been fixed. However, because it's in the database and I have a way of tracking it, I'm not worried it's going to slip through the cracks. I assume it is just low priority for them to fix, or it's really hard to fix and will require some massive re-architecting to do which they didn't want to schedule at a sensitive time in the release cycle.

I reported the steps to reproduce the bug and its outcome in a single location (the Forum), but the wiki is a way to create a traceable link to that bug report. It's nice to have the forum thread too, not just report the bug on the wiki, because then others can see your post and add further comments if they have other scenarios that reproduce the same bug, or if they have come up with suggested workarounds, etc.

So...bottom line: I guess this doesn't eliminate having to post the bug in two places, but the amount of info you have to post on the wiki is minimal: just the version number and your name and a link to the forum thread where you fully describe the bug. I usually wait a few days before transferring my bug reports over to the wiki, in case someone else reports that this is a duplicate (already reported), by design, due to "user error," or a fix is already in the pipeline for the next beta.

I also confess that I have gotten way behind on logging my bug reports from the Forum over to the wiki. The Search functionality on the Forum is pretty minimal, so it's very difficult to find all the bugs I've reported. I use Google for searching, since it's got more functionality. Putting "Bug:" in the title helps, but even then I can't narrow down the results to just bugs I've reported. It will find all bugs that I've commented on. And I can't sort them by date of original post, so I can't easily look just for new bugs that I've reported since the last time I got caught up on posting my bugs over to the wiki bug database. I'm beginning to think I need to add a new unique tag in my bug reports on the forum which will help me find them later. Yeah, that's what I'll do! My bugs will all be tagged rlpbug.

This discovery of the bug numbers in the wiki database has raised my confidence quite a bit. There is still the problem of lingering bugs that are still "pending" from several versions ago that haven't been confirmed by the Logos team yet. And there still is often a long time between bugs being confirmed and fixed. But I trust that as Development gets through their backlog of features that were already in L3 and haven't been implemented yet in the new architecture of L4 (the notorious "missing features" list), we will see they'll have more time to spend on catching up with the bugs we've reported.

Thanks again for taking the time to test, reproduce the bugs, look for known reports/fix, and write up the descriptions. You are a very good beta tester.

JimTowler

https://community.logos.com/discussion/comment/112203#Comment_112203

Rosie,

Thanks yet again for a long and detailed response.

You have just came to an idea I had already decided for myself: Its common for both a Customer (you and me) and a vendor (Logos) to have assigned tracking numbers for issues or Incidents.

I'm going to create a simple Access Database, paper notebook or small Excel spreadsheet, and assign my own tracking numbers to bugs or issues, where I care about the answer. E.G. Mine will be JT0001 to JT9999, and I intend to include it in emails, phone calls or forum postings about it. If at some point, there is a forum id, and/or official Logos ID assigned, I will add that to my copy of my fault database (list).

Then, a simple search should turn up some hits and direct me to it.

As Bob has told us at times, Logos is a commercial company selling a product. And I am one of his customers that sometimes seeks a solution for something. I am going to track my Incident requests, and expect responses - in proportion to the urgency, impact, kind of request etc.

I will also track any suggestions etc that I might submit, if only so I can use search tools and expect hits back from the site or external search tools (e.g. Google).

Please dont misunderstand. I'm not grumpy at the company in any way. Its just that I'm going to take ownership of my support needs, and elapsed times. If I believe something needs follow-up, I can send an email with full details, links, logs, whatever I need.

Its NOT my plan to seek "my" solutions ahead of more important ones, or attempt to presure the company to doing it my way. I will just be expecting a professional response to my support needs.

In the case of the initial fault reported in this thread, its NOT a big concern to me. I logged it so it would get fixed. Who knows what else its impacting. User data and UI interaction should not crash an application. Ideally, it will fail gracefully, give an error message, beep, log something etc ... NOT crash.

I have spent MANY HOURS most days, for the last few weeks, deep in the Logos 4 application, reading the various resources, and buying more than maybe I can afford. Taking advantage of the March sale, and some of the Zondervan/Pradis updates. I think I have more than I can ever read in my lifetime, but its about being able to search, cross-ref, link, compair etc, that I could never do with 1000 paper books.

John wrote: "Jesus did many other things as well. If every one of them were written down, I suppose that even the whole world would not have room for the books that would be written."

What have I learnt so far? Well, maybe just how much I dont yet know ...

Praise God!

Rosie Perera

https://community.logos.com/discussion/comment/112219#Comment_112219

I'm going to create a simple Access Database, paper notebook or small Excel spreadsheet, and assign my own tracking numbers to bugs or issues, where I care about the answer. E.G. Mine will be JT0001 to JT9999, and I intend to include it in emails, phone calls or forum postings about it. If at some point, there is a forum id, and/or official Logos ID assigned, I will add that to my copy of my fault database (list).

Great idea!

One of the things I have really grown to appreciate about this forum is the sense of community that develops here over time. People helping each other out, growing to understand each other and forgive each other, etc.

Please dont misunderstand. I'm not grumpy at the company in any way. Its just that I'm going to take ownership of my support needs, and elapsed times. If I believe something needs follow-up, I can send an email with full details, links, logs, whatever I need.

You actually sound significantly less grumpy now than when I first started reading posts from you. [:)] Frustration often leads to creative solutions. You have landed on one that will make you feel back in control, and that is terrific!

I have spent MANY HOURS most days, for the last few weeks, deep in the Logos 4 application, reading the various resources, and buying more than maybe I can afford. Taking advantage of the March sale.... I think I have more than I can ever read in my lifetime

Ditto!

Praise God!

Indeed! He is very good.

Bradley Grainger (Logos)

Select the command text from command dropdown, and drag to make a new icon on the toolbar.

Result: A nice shiney new button to make it easy to read aloud. This is the correct usage of this feature!!!

Instead, select the command from the search portion of the dropdown, and drag to make a new icon. This is INCORRECT.

The Logos4 application crashes.

On restart there is a crash log, and a detailed log about Null Exceptions and a traceback of the stack.

Thanks for the excellent instructions on how to reproduce this bug; I have confirmed it and filed a bug report.

JimTowler

https://community.logos.com/discussion/comment/112311#Comment_112311

Bradley,

Many thanks for the feedback.

Once we know you know of an issue, from somewhere, its easy to sit back and let your team address it in due course.

Thanks.