This is not a bug, this is made in by Conceptor, story.

>I have called Maximizer support, every bugs they can find after the
>software is realled is not a bug, this is made in the software.

Just because the software behaves in a way you don't like does not make it a bug.

>Ex: On max 9, once you have created a recuring appointment, the
>recuring can't be modified enymore.

If that's the way they designed it, then it isn't a bug. You can argue that it is a poor design decision, but calling it a "bug" is incorrect. Furthermore, AFAIK the behaviour of recurring appointments has not changed from v8 to v9, so this is not a v9 "bug".

>Suppport told me to send a email at suggestion@maximizer.com
>So to have it fixed I would have to go on version 10, maby it will be
>fixed.

They may decide to change the behaviour if they have evidence that enough people want the change. It's just common sense to evaluate feature requests that way.

>Their way to work, is to place bugs here and there into a new version,
>by placing also new untested features. So they can write on their nex
>report to actionner: most of users buyed the newer version. Everyone
>want his software to work properly and to have the next version bugs
>fixed but they place new one.

If you are alleging that purposely introduce bugs into their product to make people upgrade, then you are wrong.

Good news if they fix it, but what about a software 10 years old that still have until last version that bug. Just hope it get fixed.

>but what about a software 10 years old that still have until last
>version that bug

I say again: It is not a bug. It is behaving the way the designers decided it should.

So it is decided to be like that so to buy next version thinking it will be fixed.

Whoa, Feejo - you're making a pretty strong accusation in a very public forum.

As much as I can get frustrated with Max and their support policies, I have to agree with Gord on the example you've given. In this case, they've designed the product such that you can't modify a recurring task. It may be they didn't think ahead to see that modification would be desirable, it may be that they decided that modification would be undesirable and deliberately decided to disallow it, or it may be that the way they create recurrring tasks makes later modification impossible. I actually saw the last example once with recurring General Ledger journal entry creation in an accounting package, and laughed my a## off at how their implementation of recurring tasks was so incredibly simplistic. Rank stupidity in my opinion. But all of these are design decisions, whether you agree with them or not doesn't make them a bug.

Bottom line is a bug occurs where the software doesn't perform as designed. If it does perform as designed it's not a bug. If may be poor design, but it's not a bug.

And for a software developer to ask you to send in your suggestion and say it may be incorporated into the next release, that's normal.

Sorry, Feejo - there are a lot of places where I think Max could be improved. I also wish they'd test their new versions better before they released them. And I wish their support was better, including proper involvement in MaxTalk. But I don't think they deliberately insert buggy code to get people hooked on paying for upgrades. That's just really risky business. Careless they may be, but Machiavellan they're not.

- R.

I am actively helping them with their product: I send many suggestions. I even place the suggestion email address on that site. I recently receive a thanks email about my suggestions. I think the software can be improved with user feedbacks.

>I think the software can be improved with user feedbacks

It certainly can, and I'm sure that they appreciate your product suggestions. However, I am equally sure that they would NOT appreciate the accusations you have made in this thread.