Color of highlighted line in a report


J

John K

I've got Quicken 2006 running on Windows XP and I find that if I create a
report, like, for example, a cash flow report, and then highlight a line in
the report, the highlight color is dark blue. The blue highlight is so dark
that I can't read the highlited line. Does anyone know how to change the
color of a highlighted line? Thanks in advance for any help you have to
offer.
 
Ad

Advertisements

J

Jerry Boyle

John K said:
I've got Quicken 2006 running on Windows XP and I find that if I create a
report, like, for example, a cash flow report, and then highlight a line
in the report, the highlight color is dark blue. The blue highlight is so
dark that I can't read the highlited line. Does anyone know how to change
the color of a highlighted line? Thanks in advance for any help you have
to offer.
I have Q2006 Premier H&B and XP and I don't get any highlighting in my Cash
Flow report - just an unshaded box around the amount field of the selected
item. However I do get the dark blue shading in other reports, e.g. the
Transaction report. Still other reports, e.g. the Itemized Categories
report, have an unshaded box around the entire line.

The dark blue shading appears to be hard-coded into the Quicken program. It
seems to me to be the same color used to highlight items in Quicken menus.
For selected menu items the color of the menu item text is inverted to
white. That's probably what should be done, but isn't, for selected items in
reports.

I think you should report this as a Quicken bug.

Jerry
 
J

John K

Thanks for your comments. You are right, the blue highlight doesn't occur
on the cash flow report itself. My mistake. However, on the cash flow
report, when I double click on one of the line amounts, I get another report
that details each transaction that makes up the line item from the cash flow
report. It's that report that gets the dark blue highlighting.

As you suggest, I think this must be a bug in Q2006, unless it can be
changed by some sort of configuration parameter, perhaps a Windows XP
parameter, however I can't find it if it is.

Does anyone know if this is the case in Q2007 as well?
 
J

Jerry Boyle

I tried changing the Windows color scheme to no avail. For your reference
right-click on an empty area of your display, select Properties, then the
Appearance tab. In the resulting Display Properties form you can change the
entire Color scheme. Or you can click the Advanced button to change
individual items. The relevant item (in the drop-down list under Item:) is
"Selected Items". Your item is obviously not under Windows control.

I also looked in Quicken under Edit in the top menu: Edit -> Preferences ->
Quicken Program then click Register in the left pane and then the Colors
button in the right pane. As stated in Quicken Help this seems to change
only colors in your registers. The available selection of colors are all
very light anyway, nothing remotely resembling dark blue. Check this out if
you like - you can do some neat stuff here that I didn't know about before.

I also tried Start -> All Programs -> Accessories -> Accessibility ->
Accessibility Wizard, told it I was blind, and selected the High Contrast #1
scheme. This changed almost everything but the report highlighting. Try this
if you haven't had your morning coffee - the garish display will give you a
real jolt :)

There might be a way to change the highlighting color if it's specified in
the Windows registry but I strongly suspect it's hard-coded in Quicken.

Intuit did a lot of overhauling of the Reports area for both Q2005 and Q2006
and the work is probably continuing. Perhaps it's fixed in Q2007. If not
maybe Q2008 if you report the problem.

Thanks for posting any interesting question. Sorry I couldn't find a fix.

Jerry
 
J

John K

Thanks for your input. I, too, tried all that stuff but was not able to
change the highlight color.

Do you suppose no one else is bothered by the fact that they can't read the
DARK blue highlighted line in a report? Seems that this would be SO EASY to
fix. I did report this as a bug to Quicken 6 tech support.
 
J

John K

Hey, I just got a reply from a support guy at Quicken. He says that there
is no way to change the color of a highlighted line and that is true for
both Quicken 2006 and 2007. He says that he agrees that the dark blue
highlight makes the line difficult to read and will pass a suggestion along
to the development group to change the color to be more transparent. I'll
be sitting on the edge of my chair waiting for the update. :)
 
Ad

Advertisements

J

John Pollard

John K said:
Hey, I just got a reply from a support guy at Quicken. He
says that there is no way to change the color of a highlighted
line and that is true for both Quicken 2006 and 2007. He says
that he agrees that the dark blue highlight makes the line
difficult to read and will pass a suggestion along to the
development group to change the color to be more transparent.
I'll be sitting on the edge of my chair waiting for the
update. :)
If you want an even better chance of having this acted on, why
not report it at the Quicken forums in the Product Feedback
forum. If it is as easy as it sounds, I would guess there's a
reasonably good chance that it would get fixed in Q2007, for
which there will almost certainly be another release (and for
Q2006, if there is ever a reason for Intuit to issue another
release of it ... I don't think this issue alone would be cause
for a new Q2006 release).
 
J

John Pollard

John Pollard said:
If you want an even better chance of having this acted on, why
not report it at the Quicken forums in the Product Feedback
forum. If it is as easy as it sounds, I would guess there's a
reasonably good chance that it would get fixed in Q2007, for
which there will almost certainly be another release (and for
Q2006, if there is ever a reason for Intuit to issue another
release of it ... I don't think this issue alone would be
cause for a new Q2006 release).
In case you do decide to report it; your results are different
than mine. In my Q2006 Premier, the problem only appears in a
very few of all the reports available in Q2006 ... and the Cash
Flow report is not one of them. I see the problem in the
following reports:

1.) Cash Flow Transactions
2.) Itemized Categories
3.) Itemized Payees
4.) Tax Schedule
5.) Tax Summary
6.) Account Balances

(Account Balances is the oddball as it's the only one where the
problem occurs on lines that are not Quicken "transactions".)

(My workaround is to select the line below the one I want to
view, then treat the blue band as a sort of underline.)
 
J

Jerry Boyle

John Pollard said:
If you want an even better chance of having this acted on, why not report
it at the Quicken forums in the Product Feedback forum. If it is as easy
as it sounds, I would guess there's a reasonably good chance that it would
get fixed in Q2007, for which there will almost certainly be another
release (and for Q2006, if there is ever a reason for Intuit to issue
another release of it ... I don't think this issue alone would be cause
for a new Q2006 release).
For large systems even a simple fix is dangerous because it may expose
latent bugs in unrelated areas of the product. For a product with Quicken's
extensive user community this risk is usually unacceptable unless (a) it
fixes an important operational bug or (b) it causes database corruption.

I'm probably more annoyed than most at the new minor bugs that creep up in
each new Quicken release. Sometimes I even suspect Intuit of deliberately
planting these bugs to get you to buy the next release :) But I still
support Intuit's decision not to fix minor problems before the next product
release. You probably have to be a programmer to appreciate this philosophy.
 
J

Jerry Boyle

John K said:
Do you suppose no one else is bothered by the fact that they can't read
the DARK blue highlighted line in a report?
I just select a different line.

If the highlighting appears in a printed report I try to unselect everything
or select the smallest possible area in the least needed part of the report.
 
J

John K

Jerry Boyle said:
For large systems even a simple fix is dangerous because it may expose
latent bugs in unrelated areas of the product. For a product with
Quicken's
extensive user community this risk is usually unacceptable unless (a) it
fixes an important operational bug or (b) it causes database corruption.

I'm probably more annoyed than most at the new minor bugs that creep up in
each new Quicken release. Sometimes I even suspect Intuit of deliberately
planting these bugs to get you to buy the next release :) But I still
support Intuit's decision not to fix minor problems before the next
product
release. You probably have to be a programmer to appreciate this
philosophy.
Hey, I was a programmer for 35 years before I recently retired. Although I
sympathize with the fear of fixing a minor bug which might cause some other
unrelated failure, it's always been my philosophy to fix these minor bugs
whenever I came across them. It has a real positive impact on the user base
to see little annoying bugs drop by the wayside. They guy making the fix
needs to be more than an idiot when he makes the change to prevent
additional errors. Then, of course, regression testing should be performed
on each release. Competent programmers finding great difficulty fixing
simple bugs without causing unlrelated problems is a reflection of a sick
code base and or bad design. I certainly hope this is not the case with
Quicken, although some times I wonder.
 
Ad

Advertisements

J

John Pollard

Jerry Boyle said:
For large systems even a simple fix is dangerous because it
may expose
latent bugs in unrelated areas of the product. For a product
with Quicken's
extensive user community this risk is usually unacceptable
unless (a) it
fixes an important operational bug or (b) it causes database
corruption.

I'm probably more annoyed than most at the new minor bugs that
creep up in
each new Quicken release. Sometimes I even suspect Intuit of
deliberately
planting these bugs to get you to buy the next release :) But
I still
support Intuit's decision not to fix minor problems before the
next product
release. You probably have to be a programmer to appreciate
this philosophy.
I qualify.
 
J

Jerry Boyle

John Pollard said:
I qualify.
With all the time you spend helping others with their problems it amazes me
that you have any time left to do any progrmming ;-)
 
J

Jerry Boyle

John K said:
Hey, I was a programmer for 35 years before I recently retired. Although
I sympathize with the fear of fixing a minor bug which might cause some
other unrelated failure, it's always been my philosophy to fix these minor
bugs whenever I came across them. It has a real positive impact on the
user base to see little annoying bugs drop by the wayside. They guy
making the fix needs to be more than an idiot when he makes the change to
prevent additional errors. Then, of course, regression testing should be
performed on each release. Competent programmers finding great difficulty
fixing simple bugs without causing unlrelated problems is a reflection of
a sick code base and or bad design. I certainly hope this is not the case
with Quicken, although some times I wonder.
Any fix, no matter how simple or how carefully made, runs the risk of
exposing an uninitialized variable or a program bug that stores a value in
the wrong location, e. g. because of an uninitialized or incorrect address
pointer. The fact that Quicken is a huge legacy system makes the presence of
many such latent bugs almost 100% certain. Sick code base? Bad design? Those
are harsh words but they're true for almost any big system that's been
around as long as Quicken.

Quicken is the steward of many years of financial data for an enormous
number of users. That makes the possible consequences of even the simplest
fix enormous. And I don't know what systems you worked on, but on my systems
it was very expenssive to run full regression testing. Plus they'd have to
retest on every platform that Quicken runs on. Even then you can't repeat
beta testing and prior user experience.

If they screw up my financial data to fix your dark blue line I'm coming
after both you and them with a hatchet :) I'll probably be able to find the
programmer who did it and manager who authorized it standing in an
unemployment line.
 
J

John K

Jerry Boyle said:
Any fix, no matter how simple or how carefully made, runs the risk of
exposing an uninitialized variable or a program bug that stores a value in
the wrong location, e. g. because of an uninitialized or incorrect address
pointer. The fact that Quicken is a huge legacy system makes the presence
of
many such latent bugs almost 100% certain. Sick code base? Bad design?
Those
are harsh words but they're true for almost any big system that's been
around as long as Quicken.

Quicken is the steward of many years of financial data for an enormous
number of users. That makes the possible consequences of even the simplest
fix enormous. And I don't know what systems you worked on, but on my
systems
it was very expenssive to run full regression testing. Plus they'd have to
retest on every platform that Quicken runs on. Even then you can't repeat
beta testing and prior user experience.

If they screw up my financial data to fix your dark blue line I'm coming
after both you and them with a hatchet :) I'll probably be able to find
the
programmer who did it and manager who authorized it standing in an
unemployment line.
Hey, I hear you. I've been there lots of times.

I've been using Quicken since the late 80's and I'm in no hurry to screw
things up.

However, fear shouldn't be an excuse for doing a shoddy job turning out a
product.

Bet I'll bet you a 6-pack of your favorite brew that chnging the color of a
highlighted line in a transaction report isn't rocket science and can be
accomplished, by a competent programmer who knows what he is doing, with
minimal impact to the honorable Quicken program. The key here is a
"competent programmer". There are lots of idiots in the world calling
themselves programmers. Even if the guy isn't an idiot, he has to have a
clear apprecation of how the program works to mess around changing things.
I always figgured that my code should be perfect and perfection was my goal.
My code and designs were pretty good in their day. Lots of my peers argued
that perfection isn't atainable and therefore should not be sought after.
If I guy doesn't shoot for perfection he must be shooting for crap and that
is exactly what he'll get.

Just MHO!

:)
 
J

John Pollard

Jerry Boyle said:
With all the time you spend helping others with their problems
it amazes me that you have any time left to do any programming
;-)
After 39 years, one gets pretty good at utilizing time ... or
one doesn't survive. ;-)
 
Ad

Advertisements

J

Jerry Boyle

John K said:
Hey, I hear you. I've been there lots of times.

I've been using Quicken since the late 80's and I'm in no hurry to screw
things up.

However, fear shouldn't be an excuse for doing a shoddy job turning out a
product.

Bet I'll bet you a 6-pack of your favorite brew that chnging the color of
a highlighted line in a transaction report isn't rocket science and can be
accomplished, by a competent programmer who knows what he is doing, with
minimal impact to the honorable Quicken program. The key here is a
"competent programmer". There are lots of idiots in the world calling
themselves programmers. Even if the guy isn't an idiot, he has to have a
clear apprecation of how the program works to mess around changing things.
I always figgured that my code should be perfect and perfection was my
goal. My code and designs were pretty good in their day. Lots of my peers
argued that perfection isn't atainable and therefore should not be sought
after. If I guy doesn't shoot for perfection he must be shooting for crap
and that is exactly what he'll get.

Just MHO!

:)
As one old retired perfectionist to another I must confess that I snuck
fixes like this in all the time, even though I was fixing others' code in
huge, complicated legacy systems. We agree that all easy-to-fix problems, no
matter how minor, should be fixed. But I still claim that these fixes belong
in the next version or major release, in this case Q2008. If I see
light-blue highlighting in Q2007 I'm comin afta ya John :)
 
R

R. C. White

Hi, John and John and Jerry.

Since we have 3 programmers here, I'd like to digress just a little to ask a
programming question:
Then, of course, regression testing should be performed on each release.
What's "regression testing"?

I have a vague idea from the name of the term and from the way I've seen it
used here and elsewhere. But I haven't done any programming since GeeWhiz
BASIC and I didn't run into that phrase there. I hear the term a lot in the
Vista beta newsgroups, so I assume it just means that the programmers test
to see that their one step forward has not resulted in two or more steps
back. I don't need a complete dissertation (the kind I usually post!), but
a couple of paragraphs should help me (and other readers) to understand this
process.

RC
--
R. C. White, CPA [RC]
San Marcos, TX
(Retired. No longer licensed to practice public accounting.)
(e-mail address removed)
Microsoft Windows MVP
(currently running Windows Mail 7 in Vista x64 Build 5472)
 
J

Jerry Boyle

R. C. White said:
Hi, John and John and Jerry.

Since we have 3 programmers here, I'd like to digress just a little to ask
a programming question:


What's "regression testing"?

I have a vague idea from the name of the term and from the way I've seen
it used here and elsewhere. But I haven't done any programming since
GeeWhiz BASIC and I didn't run into that phrase there. I hear the term a
lot in the Vista beta newsgroups, so I assume it just means that the
programmers test to see that their one step forward has not resulted in
two or more steps back. I don't need a complete dissertation (the kind I
usually post!), but a couple of paragraphs should help me (and other
readers) to understand this process.
Hi RC,

You hit the nail right on the head.

It's a set of tests to ensure that fixes and enhancements don't break
existing features, i.e. it *prevents* regression.

As enhancements are made and as bugs are discovered by system testers, beta
testers and users, new tests are added to the set to ensure that the
enhancements and fixes continue to work.

Jerry (of the 3 J's)
 
Ad

Advertisements

J

John K

Jerry Boyle said:
Hi RC,

You hit the nail right on the head.

It's a set of tests to ensure that fixes and enhancements don't break
existing features, i.e. it *prevents* regression.

As enhancements are made and as bugs are discovered by system testers,
beta
testers and users, new tests are added to the set to ensure that the
enhancements and fixes continue to work.

Jerry (of the 3 J's)
Jerry, and you to, RC, is exactly correct.
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top