Doesn't matter which translation is up (in fact if i have multiple translations up, they all revert back to verse one of the chapter.

The way I usually highlight by selecting the verse, right click, select highlight, choose color, and bam! I am back to verse 1.

pastor-steve

06-11-2004, 12:44 AM

I'm pretty sure this is another manifestation of Bibleworks forgetting a verse range. When you ask to see a chapter in multi-version mode, Bibleworks asks as thought you have typed in verse 1-999 (last verse of the chapter). Then when you do anything like add a display version, highlight a verse, or go back in the history, it forgets everythign but the first verse. In my mind, this is the only truly annoying feature of Bibleworks. It's really nonintuitive. Hopefully, they'll fix it.

The solution, as long as you're only displaying one version at a time, is to use browse mode. (Click the little feet in the toolbar.)

Steve

pastor-steve

06-11-2004, 02:56 AM

I should have reviewed Philippians 2:14 ("Do everything without complaining or arguing") before I posted that last message. It looks like the BibleWorks development team has this one licked in the latest update. The history part isn't fixed yet, but you can change all kinds of things (display versions, highlighting, browse/multi-version mode) and it remembers the verse ranges! I'm sooooo happy! :D

Thanks, guys!

Steve

Tyrone Brumwell

06-11-2004, 12:12 PM

I appreciate the feedback and assistance.
I have switched to "browse" mode, attempted highlighting, and was successful.

Someday (over the rainbow), I hope they get a chance to adjust this bug.

Thanks,

Tyrone Brumwell

Tyrone Brumwell

06-16-2004, 09:24 PM

I have been notified by BibleWorks that this bug is/will be fixed via a patch.

Thanks BibleWorks.

TS Brumwell

pastor-steve

08-05-2004, 02:09 AM

Hi, all!

Anyone know if the problem in this thread has been fixed again. It's getting harder to run 6.0.1.010e (the version with the mostly-working, first-cut verse range remembering fix). I understand that the quick fix caused problems and had to be removed. Just curious as to whether it's been re-fixed yet.

Thanks,

Steve

pastor-steve

11-06-2004, 03:16 AM

I'm still running the ancient 6.0.1.010e that had a fix for BibleWorks forgetting the verse range you type in if you do anything else (including going back and forward). See the rest of this thread for details.

The quick fix caused a new problem and had to be backed out, but it was supposed to be fixed again "soon." That was 7 months ago.

Any word? Is it still broken in the latest? If I upgrade I won't be able to go back, and that particular problem is really annoying to me the way I use BibleWorks.

Thanks,

Steve

Philip Brown

11-06-2004, 08:19 PM

Hi, Steve,

The BW team really works hard to allow users the flexibility they desire. That said, BW is not designed to browse in multi-version mode. That's not a bug; it's a design feature.

The parallel version dialog is the best option currently available for browsing through parallel features.

Philip Brown

pastor-steve

11-06-2004, 10:40 PM

Hi, Philip.

You're right that the BibleWorks team works very hard. It's just that they told us customers that they planned to fix this "feature" that has been called a bug by at least a dozen users. BibleWorks doesn't work they way users expect it to. (or the way any other program with a "back" and "forward" button does.

My problem isn't browsing. It's that I type in a range of verses, say, "Genesis 28:18-22," then I go to something else and try to come back with the back button. It only shows me Genesis 28:18. If I add a display version, it drops the verse range I typed and goes back to Genesis 28:18. I then have to remind BW that I types Gen 28:18-22 by retyping it in the command line.

I'm not "browsing," I'm trying to use BibleWorks for what it's advertised for. I want to look at English, Greek, and Hebrew at the same time. The literature says it can do this so it's hard for me to see the awkward way this works as a "feature." I've studied user interface design, and this is a user interface design bug. It's inconsistent behavior and the program state isn't persistent even though there's a "back" button.

That said, when they put in a fix and then took it back out, they said they would be fixing it soon. I'm a paying customer (three times so far) waiting for what has been promised to me. Onece you promise it, you don't get to change your mind and redefine it as a feature.

I know that it's more fun to add new feratures than to fix bugs. I used to develop software for a living, but in the end, what's most important is that your software does what it does well. (Well, customer support is tremendously important too.)

Just my two cents. Clearly the BW team doesn't agree.

Steve

MBushell

11-08-2004, 10:24 AM

I'm still running the ancient 6.0.1.010e that had a fix for BibleWorks forgetting the verse range you type in if you do anything else (including going back and forward). See the rest of this thread for details.
Steve

Hi Steve,

The problem is that often a user will ask for a particular feature and if it looks at first glance to be something that we can do quickly we will interupt what we are doing and add it. Most of the time this works fine. But occasionally a change interacts with the program in unexpected ways and we have to back off. Making changes like this on the fly is always risky because they don't normally get subjected to a round of beta testing. In such case we have to weigh the potential gain against the risks. We want to serve our users but we cannot always meet their expectations. It just happens occasionally that we make quick changes that generate unexpected problems that are impossible to fix without major code surgery, which in turn simply cannot be released without extensive beta testing. I would just remind you that very few companies are not willing to even attempt feature tweaks between major releases, for this very reason. For us there are really only two options: (1) stop adding feature enhancements between releases or (2) do it where possible with the caveat that these changes may or may not work, and may or may not be kept. We chose the latter as being the most help to the most people, though at the risk of irritating a few.

There are limits to what we can do with limited staff. We could very easily increase our programming staff and try to satisfy every request (we get hundreds) but the price of the program would have to go way up. As it is BibleWorks is way underpriced considering the work that goes into it and the amount of data in it. But we have tried very hard to keep the program affordable, while still providing a professionally programmed and packaged product, as the content deserves. These two goals are very hard to fit together. To do it we have to pick and choose what we work on and which requests we can satisfy and which we can't.

I will look again at the code behind the change in quetsion. My recollection is that it required modes changes in a single subroutine. But unfortunately it is a subroutine that is called from literally hundreds of other places in the code. The quick fix just turned out to be unworkable. If I can find a way to make it work that is not risky, I will do it, but I cannot promise that. Failing that I will do my best to get the feature into the next release so that it can go through a proper testing process. In the mean time we just ask for patience. We are doing the best job we can for our users.

God bless,

Mike Bushell
BibleWorks,LLC

vr8ce

11-08-2004, 12:38 PM

Hi Steve,

I will look again at the code behind the change in quetsion. My recollection is that it required modes changes in a single subroutine. But unfortunately it is a subroutine that is called from literally hundreds of other places in the code. The quick fix just turned out to be unworkable. If I can find a way to make it work that is not risky, I will do it, but I cannot promise that. Failing that I will do my best to get the feature into the next release so that it can go through a proper testing process. In the mean time we just ask for patience. We are doing the best job we can for our users.

Hear, hear. As a frequent "let's do this!" poster, let me agree with Mike completely on this one. I am one of the ones that would DEARLY love to see this functionality, and I had a love/hate relationship with it for the short time it was in. The love was I loved it remembering the ranges; the hate was that it remembered the ranges when it shouldn't. So, I understood completely when Mike took it back out, and have assumed it wouldn't show up again until the next upgrade (if then, but I was hoping).

This one's important, so getting it right is far more important than getting it early. If it's the next upgrade before we see it again, great.

Vince

pastor-steve

11-17-2004, 02:57 PM

Thanks for helping me undertsand Mike. I do appreciate your efforts, and BibleWorks certainly helps me to be a more effective preacher and teacher than I could be without it.

God bless you,

Steve

The problem is that often a user will ask for a particular feature and if it looks at first glance to be something that we can do quickly we will interupt what we are doing and add it. Most of the time this works fine. But occasionally a change interacts with the program in unexpected ways and we have to back off. Making changes like this on the fly is always risky because they don't normally get subjected to a round of beta testing. In such case we have to weigh the potential gain against the risks. We want to serve our users but we cannot always meet their expectations. It just happens occasionally that we make quick changes that generate unexpected problems that are impossible to fix without major code surgery, which in turn simply cannot be released without extensive beta testing. I would just remind you that very few companies are not willing to even attempt feature tweaks between major releases, for this very reason. For us there are really only two options: (1) stop adding feature enhancements between releases or (2) do it where possible with the caveat that these changes may or may not work, and may or may not be kept. We chose the latter as being the most help to the most people, though at the risk of irritating a few.