OnChange not fired by code changes of value. Alternatives?

[BigChimp]

Turbofast,

I have trouble seeing what you mean by this post. Just to be clear: I'm not trying to pick a fight with you. I'm just stating what's the best, most efficient way of reporting bugs and getting them fixed.

I'm also surprised and confused that you confirm the bug report was in error on the bugtracker while you state in this thread that there are bugs....

As for your post: are you really asking this seriously? I'm assuming you do... but I'm going to repeat myself below.

Obviously it's fine to use FPC 2.6.0 to demonstrate a bug in 2.6.0. A test program that works (and demonstrates the bug) on 2.6.0 should work just as well on newer versions (barring FPC changes that break compatibility).
Similar story for Lazarus.

there was no FPC greater then 2.6.0,

Bug reporting has nothing to do with whether there is a newer version available or not - also testing on a newer version with a reliable test program is just a way to see if a problem has been fixed (and if possible/desirable, depending on release strategy, locate the change so it can be backported to a fixes branch)
If there were no newer versions, well, that's the end of the story: you only test against the existing version.

But, AFAIU, that was *not* the problem with your test program.

With test programs there are 2 possibilities for unexpected behaviour:
- there is a bug (in the OS, widgetset, network stack, Lazarus, FPC etc)
or
- the test program itself has a bug.

A test program bug can be caused because it is programmed the wrong way. E.g. the programmer expects that boolean means an integer value or something a bit less stupid, or the programmer has built too much complexity that apparently interferes with the behaviour you're testing for.
A good test program is a test program that has just enough code to demonstrate the problem. Not a line more.

Solution:
- strip down the program
- have it reviewed by yourself (against the LCL/widgetset/compiler specifications & documentation) or, to make sure you're not making programming errors and if documentation etc is lacking, the devs/experienced others who know what the LCL/widgetset/compiler is supposed to produce.

AFAIU, the test program Bart provided was stripped bare and proved there were no problems: the LCL/widgetset/compiler did what they were expected to do.
The program you provided was more complicated and didn't work as you expected, *but* Bart's test program proved that the bug you thought was present was not actually present.

what should I have called this problem.

Myself, I don't particularly mind as long as the description of the bug follows the rules (see the wiki on bug reporting).

High strangeness?

No idea what you're on about, perhaps a language issue.

My mistake was not trying to figure out how to upgrade the compiler to a later version.

Well... no, I wouldn't call that a mistake. If your test program is good, other people can run it and demonstrate what happens on their Lazarus/compiler version etc.

What do you file to demonstrate that the FPC is working wacky if there was no FPC greater then 2.6.0?

A test program. See above.

[Bart]

Just out of curiosity I re-build the original program with Laz 1.1/fpc 2.6.0.
It produced exactly the same results as with 2.6.2RC1 (the one I tested it with in the bugreport).
This, to me, proves that there is no fpc version issue.

Back to the issue.
We don't mind that you post (as a newbie) a bugreport that proves out to be wrong.
What I hope you have learned from this is, that before posting, you try to break down the perceived bug.
You suspected it was the OnChange not working. Well you could have easily tested that hypothesis, and (like me) find out this was not the case.

You can step through the code and inspect variables to see what's going on. Or you can place writeln() at strategical places to see how the program behaves (this is how I generated the output attached to the bugreport).

Keep on stripping any code that may be unrelated to the bug. Then at some point you are left with a minimal test case.

And, as long as you consider yourself a newbie, or are unsure about the issue, it is considered good practice to first ask on the forum or mailinglist (attach sample project).
More experienced users can then confirm the bug, or maybe see it's a bug in your code.

Even more experienced users still use the mailinglist or forum to query others about perceived bugs.

So, to be short: feel free to ask (here or on the mailinglist). Remember: there is no such thing as a stupid question. However, not asking questions when you're in doubt, may be considered foolish 

Happy coding,

Bart