>
> On thing is: there are some users for whom the monetary cost of the
software
> is important (often paying for it out of pocket) and other users where
cost
> is not an issue (often because the employer pays for it automatically).
> Those in the first group seem to raise the most issues about the
> cost-vs-benefit of this upgrade, and those in the latter group (including
> me) seem to be the most satisfied about the cool new features and fixes.
>
> -slj-
>
I'm am my employer. So, I'm in both groups. It's not unreasonable to
expect a very high quality product for the high quality dollars that we've
invested in the solution offered from Code Warrior. (Sarcasm: What, you
mean the money I payed didn't spend well?)
Likewise, it's not unreasonable for them to address the bugs in their
software. I don't have problems paying for feature upgrades, but bug fixes
are a different story. There is a reasonable expectation that the product
will work.
For example, months ago I reported that when using mathlib, do stuff like
this:
x = cos(z) + sin(y) + tan(c);
resulted in CW overallocating, or allocating stack space for a temporary
variable for each of the trig functions, that went UNUSED in subsequent
calculations, for example, the next line in my code:
a = sqrt(x) + cos(y);
Would result in even more stack space allocation, basically resulting in
code that wouldn't run on older palms because of stack overflows. The end
result is you have to munge up your code to get it to work when compiled by
CW where GCC doesn't have this problem AT ALL.
For example, to make it work "better" in CW, I was instructed to do
something like this:
double tmp;
x = (tmp=cos(z)) + sin(y) + tan(c);
a = (tmp=sqrt(x)) + cos(y);
while this works for one of the trig functions and for each statement, the
others have to have even more temporary local variables declared to reduce
the amount of temp space allocated on the stack. The end result is code
that LOOKS horrible and is difficult to follow, all to work around a
compiler problem.
Another option was to use the: #pragma stack_cleanup compiler option. Using
both of these, and a few other techniques, I have been able to keep my
programs working on older palm platforms.
I expect this sort of stuff to get high priority and fixed, especially if
it's going to cost me $190.
And another thing, this time with Constructor.
How many of you are using a resolution like 1280x1024 on a 19" monitor? I
do, and you see that tiny, microscopic window that I have to use for fine
placement of my controls. VFDIDE, a $35 product, doesn't have this
limitation AT ALL. I ended up sticking another monitor on my computer (I'm
using Windows 2k so I can have multiple video cards installed), 15 inch
monitor, running 640x480, so that I can even make constructor useable.
These are areas that should take top priority from CW. Microsoft tools
don't have these problems, other 3rd party tools don't have these problems,
so it's not unreasonable to expect for CW to also not have these problems,
IMHO.
Now I don't want all of you to think I'm just ranting... I appreciate the
hard work that is gone into the CW product, and I appreciate the presense
that CW has on this list. I bring these points up, again, so that people
working on CodeWarrior will understand that they are indeed important
issues.
It would be nice if CW maintained a publicly viewable list of
limitations/problems that are identified and a priority list of when they'll
be fixed so that users don't have to repeat over and over the same things.
Ed
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
