On 02/18/2013 08:58 PM, Jesus Reyes wrote:
Hi Giuliano,
As you may know, the patch was merged to fixes but, a problem was detected, it
introduced a regression, please see http://bugs.freepascal.org/view.php?id=23901
Jesus Reyes A.
I made further tests both under Linux and under Windows. The behavior
turns out to be the same.
What happens is that my patch (i.e. setting Band name from the BandView)
doesn't affect Preview at design time, doesn't affect any method for
displaying a Report (PrepareReport, etc.) but it causes an error if you
attempt to design a report in runtime (something I had not tested,
because I didn't use it) .
In that condition (and only in that condition) whenever the name of an
object is set, it verifies if the name is duplicated. As we have the
same name for BandView and Band, when we set the name of the Band it
triggers the error.
It's unclear to me while this test is made only in this condition,
because there should be no difference if you design a report at design
time, or at run time, but that's how it's made.
I've tested a different approach, i.e. not *setting* the Band name, but
just *getting* Band name from BandView, (a Name property in TfrBand
which just returns the name of the corresponding Bandview, i.e.
View.Name). It doesn't produce side effects, because when the BandView
name is set the corresponding Band object doesn't yet exist.
There are two solutions:
1) I send you the new patch.
2) We leave things as they are, but the examples and the documentation
are modified to make it clear that TfrBand.Name is always empty, and
that one must use TfrBand.View.Name to obtain a meaningful information.
You're the boss, so it's up to you to decide.
Giuliano
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
