View Issue Details

IDProjectCategoryView StatusLast Update
0034819PackagesTAChartpublic2019-02-07 01:45
ReporterMarcin WiazowskiAssigned Towp 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2.0RC3Product Build 
Target Version2.0.2Fixed in Version 
Summary0034819: Series marks are sometimes invisible
DescriptionSeries marks are sometimes fully or partially invisible - the problem depends on:
- MarkPositions setting of the series,
- Range settings of the assigned Y axis.


Please take a look at the attached animation and the sample application. Two charts are visible, that have identical settings, with one exception - the left chart doesn't use Range.Min for Y axis, the right one uses Range.Min = -1. By using a "Move Up" button multiple times, the problem can be seen: series marks should be fully visible in all cases - but they are not.


The problem can be defined as (Lazarus 2.0.0 RC3):
- Left chart: Range.Min is not used, so the mark (description) for the first series point is fully visible for Y in range (-INF, 0> (this is OK) and fully invisible for Y in range (0, +INF) (this is NOT OK)
- Right chart: Range.Min is -1, so the mark (description) for the first series point is fully invisible for Y in range (-INF, -1) (this is OK), fully visible for Y in range <-1, 0> (this is OK), and partially invisible for Y in range (0, some positive value) (this is NOT OK)


When compiled with Lazarus 1.8.4, left chart works fully properly, and the right one works improperly (but behavior is different than in 2.0.0 RC3).


Note 1: Similar problem occurs also when setting MarkPositions of both series to lmpInside or lmpInsideCenter.


Note 2: Same problem will probably occur also when using RangeMax and MarkPositions = lmpPositive (instead of RangeMin and MarkPositions = lmpNegative as it is now).


Note 3: This bug can be used to limit height of a multiline mark's text (by using the case when the mark is partially invisible) - please see the attached "ThisBugCanBeUseful.png" image. Such a functionality is very useful - very long text doesn't occupy too much chart space, but still can bee seen when needed (by zooming in). I'm afraid that this (unintended) functionality will disappear after patching the bug - so maybe this functionality could be officially added (by adding some property to the series or marks)? This would be wonderful.


Kind regards
TagsNo tags attached.
Fixed in Revision
LazTarget2.0.2
WidgetsetWin32/Win64
Attached Files

Relationships

related to 0034861 closedwp Lazarus Incorrect placement of series labels for stacked series in case of non-linear axis transformations 
related to 0034862 closedwp Lazarus Incorrect horizontal placement of series labels for non-stacked bar series 
related to 0034863 closedwp Lazarus Logarithmic bar series does not display values < 1 
related to 0034857 closedwp Lazarus Improper axis range calculation 
related to 0034896 closedwp Lazarus TAChart: improper calculations in TAxisCoeffHelper.CalcScale 

Activities

Marcin Wiazowski

2019-01-05 18:19

reporter  

Animation.gif (37,485 bytes)
Animation.gif (37,485 bytes)

Marcin Wiazowski

2019-01-05 18:19

reporter  

Reproduce.zip (3,539 bytes)

Marcin Wiazowski

2019-01-05 18:20

reporter  

ThisBugCanBeUseful.png (5,320 bytes)
ThisBugCanBeUseful.png (5,320 bytes)

wp

2019-01-06 23:58

developer   ~0113228

Began to redo the mark positioning routine and committed a preliminary version which has some improvement, but still some issues, in particular with rotated series.

Uploaded my test program which covers a variety of cases like rotated and stacked line, bar and area series.

I don't fully understand your idea in note 3. Do you want to display marks only partially? I don't like this, looks like an error. If your chart is too crowded you should display hint popups by means of the chart tools.

Maybe you should turn off the series' Marks.AutoMargin and provide ample space for margins. Then your series marks will be truncated at the border.

Marcin Wiazowski

2019-01-07 03:26

reporter   ~0113230

Please ignore my Note 3. I'm still not an expert in TAChart and I just wasn't aware of series' Marks.AutoMargins property. Thanks for your advice.

Regards

wp

2019-01-07 23:07

developer  

MarkPositions.zip (4,371 bytes)

wp

2019-01-07 23:12

developer   ~0113243

r60027 should handle the rotated series correctly now, and seems to work correctly for all cases.

Still have to look at the case of your right chart where one end of the axis is "fixed" by means of the Range parameters.

wp

2019-01-08 15:30

developer   ~0113268

Last edited: 2019-01-08 15:33

View 3 revisions

I think the right chart of your demo works correctly (at least in the present state). The Range of the axis is only one piece of the contributions merged to the final axis range: When the y values of all data points are larger than the LeftAxis.Range.Min then the axis minimum is defined by Range.Min. When y values are smaller than Range.Min then the axis is extended to show the full data range. If you really want to truncate the axis to the Range.Min you must set Chart.Extent.YMin.

I am resolving now (merging to Laz 2.0-fixes is requested). Please close the report to remove it from the usual bugtracker screens. Or reopen if something is still wrong.

Marcin Wiazowski

2019-01-10 19:22

reporter   ~0113310

I tested the last trunk version and - as far as I understand - there are still some problems for MarkPositions = lmpInsideCenter - please see the attached InsideCenterX.png images, and the Reproduce2 project.


Note 1: Documentation says: "lmpInsideCenter -- between data point and zero level" - but all the marks, on all the InsideCenterX.png images, are located between data point and +INF.


Note 2: On InsideCenterA.png: second data point on Chart 1 has a visible link to the mark (mark is invisible), while on Chart 2 link is not visible.


Note 3: On InsideCenterA.png: some marks are partially invisible.


Note 4: On InsideCenterB.png: one more mark is partially invisible.


Note 5: On InsideCenterC.png: on Chart 3, labels on Y axis disappeared.


Note 6: On InsideCenterD.png: on Chart 1, labels on Y axis also disappeared.


Note 7: Merging to Laz 2.0-fixes failed due to conflicts.


Regards

Marcin Wiazowski

2019-01-10 19:23

reporter  

InsideCenterA.png (11,374 bytes)
InsideCenterA.png (11,374 bytes)

Marcin Wiazowski

2019-01-10 19:23

reporter  

InsideCenterB.png (11,674 bytes)
InsideCenterB.png (11,674 bytes)

Marcin Wiazowski

2019-01-10 19:24

reporter  

InsideCenterC.png (11,395 bytes)
InsideCenterC.png (11,395 bytes)

Marcin Wiazowski

2019-01-10 19:24

reporter  

InsideCenterD.png (11,098 bytes)
InsideCenterD.png (11,098 bytes)

Marcin Wiazowski

2019-01-10 19:25

reporter  

Reproduce2.zip (3,757 bytes)

wp

2019-01-11 00:23

developer   ~0113318

> Note 7: Merging to Laz 2.0-fixes failed due to conflicts.

Merged manually.

Marcin Wiazowski

2019-01-12 00:14

reporter   ~0113342

I found two bugs in TBasicPointSeries.DrawLabels, and one possible improvement:



Note 8:
        if not Stacked then
          g := GetGraphPoint(i, 0, si)

y VARIABLE IS NOT INITIALIZED HERE !!!!!!!!!!!!

        else
        if si = 0 then
          y := Source[i]^.y - GetZeroLevel
        else begin
          y := Source[i]^.YList[si-1];
          if IsRotated then
            g.X += AxisToGraphY(y)
          else
            g.Y += AxisToGraphY(y);
        end;
        gl := g;
        if FMarkPositions = lmpInsideCenter then begin

BUT IS USED HERE !!!!!!!!!!!!

          if IsRotated then
            gl.X -= AxisToGraphX(y)/2
          else
            gl.Y -= AxisToGraphY(y)/2;
        end;



Note 9:

There is:
            (Marks.YIndex = MARKS_YINDEX_ALL) or (Marks.YIndex = si) and

but brackets should be added:
            ((Marks.YIndex = MARKS_YINDEX_ALL) or (Marks.YIndex = si)) and



Note 10:

There is:
    for i := 0 to Count - 1 do begin

but this can be changed to:
    for i := FLoBound to FUpBound do begin

so drawing will be much, much faster for large data sets; the same loop constraints (i.e. FLoBound and FUpBound) are already used in TBasicPointSeries.DrawPointers; in fact, it seems that - after introducing FLoBound / FUpBound functionality - it has been used in all places, but TBasicPointSeries.DrawLabels has been omitted, so it is still very slow.


Regards

wp

2019-01-12 01:21

developer   ~0113344

Last edited: 2019-01-12 01:25

View 2 revisions

Fixed Note 8 in r60058. Thanks for reporting, this fixed the issue with the inside-centered line series labels not being between data point and zero level. This centering mode, however, is thought to be used for "filled" series, such as TBarSeries and TAreaSeries, and thus does not affect TLineSeries.

wp

2019-01-12 07:32

developer   ~0113347

Fixed Note 10 in r60059. How did you notice that speed issue? I would not use series marks for large data sets because all labels would overlap. Which application case do you have in mind where this would have been an issue in practice?

wp

2019-01-12 07:47

developer   ~0113348

Fixed Note 9 in r60060.

wp

2019-01-12 08:24

developer   ~0113349

Remark on Notes 2-6:
The option lmpInsideCenter is primarily thought to be used with bar or area series. It does not make much sense to use it with a line series where the ZeroLevel has no visual effect and the mark links do not point to the data points. I added some clarifying statements to the documentation in http://wiki.lazarus.freepascal.org/TAChart_documentation#Mark_positions_and_attachment.

Notes 2-4:
Related to a bug with lmpInsideCenter which I could not find so far: If the label is attached to the "center" (i.e. half-distance between data point and zero level), sometimes the upper end of a mark is ignored when calculating the upper margin which results in partially visible marks.

Notes 5-6:
The disappearing labels are related to the way how automatic label positioning was implemented: If labels extend the range covered by the data the margin of the chart is increased such that it can be used by the label. Since the height of the chart itself remains constant the part available for the data becomes smaller. The axis label finding algorithm, however, is determined by the this data part of the axis. It is the same as if you shrink the height of a normal chart more and more. You will observe that there will be less and less axis labels because the lower limit of the label distance becomes comparable to or even exceeds the chart height.

I am not saying that this cannot be fixed, but I fear this can't be done without completely rewriting the series and/or axis labeling routines, and I won't do this by no means. Moreover, I think the issue does not have much practical importance: when the space occupied by the labels takes too much away from the data area then labels should not be used at all because the structure of the data distribution will be leveled out.

Resolving again. Let's see if automatic merging to fixes works this time. Please test and close if ok, or re-open if you find something else related.

Thanks for your efforts, by the way.

Marcin Wiazowski

2019-01-12 20:08

reporter   ~0113360

> Fixed Note 10 in r60059. How did you notice that speed issue? I would not use series marks for large data sets because all labels would overlap. Which application case do you have in mind where this would have been an issue in practice?

Please note that you can have 100000 points in series, but you can limit X axis range by using Axis.Range.Min/Max - so you effectively need to display only few points (and their marks don't overlap in this case).

In my specific case, I'm creating an application that displays some event log, similarly to "ThisBugCanBeUseful.png" image (that is attached to this bug report). X axis range is set to 1 day or 1 week, and the user can navigate by using dedicated MovePrevPeriod / ModeNextPeriod buttons. There may be few events per day (so few points/marks to display), but thousands in the whole data set (events may be collected by years, and there is about 20 event kinds). I just realized, that drawing 3 marks takes as much time as painting 100000 marks, due to the "for i := 0 to Count - 1 do" statement.

Marcin Wiazowski

2019-01-12 21:37

reporter   ~0113364

I'm afraid that there are still some problems...


Note 11: First I must ask some question - please see the "Comparison.png" that I attached. In lmpInside mode, all marks are directed towards zero - and this is as designed and OK.

As far as I understand, the only intentional change for lmpInsideCenter mode (when comparing to lmpInside mode) was to change the marks' starting points - from "y" to "y/2". But also other change has been introduced - all marks are directed towards +INF. This doesn't seem to be consistent with lmpInside mode, and "xxx" mark is truncated on the "Comparison.png" image (the mark is probably used in margin calculation as if it were directed towards zero - similarly to lmpInside mode).

If the intention was really to direct all marks arbitrarily to +INF, I think that lmpInsideCenter should be renamed to something like lmpInsideCenterPositive, and also accompanying lmpInsideCenterNegative mode should be added.

But if the intention was to retain same marks direction as for lmpInside, then - in TBasicPointSeries.GetLabelDirection method - "lmpInsideCenter: isNeg := false;" should be changed to "lmpInsideCenter: isNeg := AValue >= ref;"



Note 12: Launch the attached Reproduce3 application - it uses TBarSeries this time, and all MarkPositions are set to lmpPositive. Initially, Chart 2 in not painted at all (this is definitely a bug) - but after you minimize and maximize the application's window (i.e. force chart redrawing), Chart 2 is finally painted - but in an extremely strange way. Interestingly, this behavior depends somehow on series' source - after editing ListChartSource12 by changing -21 value to -20, the problem doesn't occur.


Note 13: Launch the Reproduce3 application and press the "Move Up/Down" button multiple times. Chart 2's behavior is extremely unexpected and strange.


Regards

Marcin Wiazowski

2019-01-12 21:37

reporter  

Comparison.png (12,172 bytes)
Comparison.png (12,172 bytes)

Marcin Wiazowski

2019-01-12 21:38

reporter  

Reproduce3.zip (3,527 bytes)

wp

2019-01-13 10:39

developer   ~0113373

Last edited: 2019-01-13 10:51

View 2 revisions

Reverted all major changes and merge with fixes due to 0034857. Obviously TBasicPointSeries.UpdateMargins is very critical since it interacts with axis labeling in an iterative process. Not clear at the moment whether this report can be fixed at all.

Note 9: Reimplemented in r60069.
Note 10: Remimplemented in r60070.
Note 8: Will not be implemented again this way because there are other issues in that routine.

Please check the current state after r60070 and report which notes are still valid.

I am reporting related issues which I saw on the way: 0034861, 0034862, 0034863.

wp

2019-01-13 16:23

developer   ~0113380

Note 8 avoided by new code in r60071

wp

2019-01-14 01:02

developer   ~0113388

Last edited: 2019-01-14 01:04

View 2 revisions

Fixed the original issue in r60077 by reverting the changes introduced by r56492 for the lmpInsideCenter option for label positioning (in TBasicChartSeries.UpdateMargins). The drawback is that the margins are no longer adjusted when they reach out of the bar. But when somebody chooses the option lmpInsideCenter he/she usually wants the label to be centered within a bar of a BarSeries, and would set Marks.Distance to 0 and Marks.Attachment to maCenter (as is recommended in the wiki documentation).

I do not fully understand the behavior of the right chart in which one end of the y axis is locked. As I noted above there are several factors which contribute to the behavior whether the axis is extended or not. But I think if the user locks the axes he does not expect the series labels to be displayed fully. If the current behavior is critical for your application you can also use the Extent of the chart to fix the axes which has the highest priority and does not allow the axis range to grow any more.

So far I did not check for the other "notes" - I think these bugs are a consequence of the first commit for this subject.

Please test carefully and close if ok.

Marcin Wiazowski

2019-01-14 17:44

reporter   ~0113406

> The drawback is that the margins are no longer adjusted when they reach out of the bar.

Note 14: I'm afraid this creates a huge problem, which can be easily seen for multiline marks (and probably also for single lines, having their font big enough). Please launch the attached Reproduce4 application and press the button eight times: Chart 1 and Chart 3 start to show nothing, Chart 2 and Chart 4 no longer display any marks.

Marcin Wiazowski

2019-01-14 17:45

reporter  

Reproduce4.png (8,896 bytes)
Reproduce4.png (8,896 bytes)

Marcin Wiazowski

2019-01-14 17:45

reporter  

Reproduce4.zip (3,612 bytes)

wp

2019-01-14 23:05

developer   ~0113413

I fear you are constructing here use cases which are not relevant in practice. TAChart is not a "super-intelligent" library which can handle every oddity automatically. If you push the component into a corner case for which it was not designed it may work in an unexpected way.

The issues that you mention occur when all the area available for the data has been consumed by the labels - I had explained above that the space occupied by the highest and lowest label is added to the margins of the chart and reduces the size in which data can be plotted. In fact, it can be seen in your screenshot that the y axis even becomes inverted (negative values growing upward) - this demonstrates that the chart can handle this erroneous situation without crashing.

The solution for the application is that the chart must be sufficiently large to allow for the highest label, or you must truncate the label at the maximum height that you can afford depending on the size of the chart. You could also display a short label only and keep a longer text for a popup hint which comes up when you move the mouse over the data point - this requires a DatapointHintTool. Or you could put the extended message texts into a grid component next to the chart and use another DatapointTool to scroll the grid to the row which contains the message of the data point underneath the mouse.

Or you could consider using a completely different component for displaying the log messages of your application - I know of the planner components of TvPlanIt or the timeline components in JVCL, and probably there are some others.

Marcin Wiazowski

2019-01-15 00:10

reporter   ~0113416

Well, I'm aware that there are always some limitations - and being defined as a bug or as a limitation may be just a matter of making a decision by the developer.

I also don't think that the case described in Note 14 is a problem in practice; I just reported it to be sure, that it isn't something unexpected (since I'm not an expert in TAChart internals, I can't settle).

I'll perform more detailed tests tomorrow and let you know.

Regards

wp

2019-01-15 13:05

developer   ~0113425

Last edited: 2019-01-15 13:10

View 2 revisions

Note 11:
I removed the option lmpInsideCenter from MarkPositions and introduced a new property MarkPositionCentered (r60088) which is published only for bar and area series. Therefore, it is no longer possible to apply this feature to line series & co, and the direction of the label from the center point can be adjusted by using the remaining options in MarkPositions.

The meaning of lmpOutside and lmpInside was changed: the label no longer points away from / towards the zero level but from the average value of the data point y values. Zero level is used only for bar and area series where it makes sense.

Marcin Wiazowski

2019-01-16 01:11

reporter   ~0113434

> I removed the option lmpInsideCenter from MarkPositions and introduced a new property MarkPositionCentered

Quite a good idea.

I've been testing all the day. I need a bit more time. Stay tuned.

Marcin Wiazowski

2019-01-18 21:16

reporter   ~0113462

> y axis even becomes inverted (negative values growing upward)

By writing these words, you effectively found two bugs! To avoid mess here, I described them in 0034896.

Regards

Marcin Wiazowski

2019-01-18 21:56

reporter   ~0113463

To avoid mess here, I described some problems in 0034897 and 0034898.

Marcin Wiazowski

2019-02-05 01:44

reporter   ~0113857

Note 15: Please take a look at Animation5 and Reproduce5 application. I understand direction of marks for bar series, but I'm not sure about line series.

Documentation in http://wiki.lazarus.freepascal.org/TAChart_documentation#Mark_positions_and_attachment says about "zero level", but I couldn't find what the zero level is.

For bar series, it is just 0 on the Y axis.

But for line series, is this an average between the highest and the lowest point? And is this as designed? If so, maybe it would be good to add some explanation to the documentation.

P.S. The documentation still says about "lmpInsideCenter".

Marcin Wiazowski

2019-02-05 01:44

reporter  

Animation5.gif (19,580 bytes)
Animation5.gif (19,580 bytes)

Marcin Wiazowski

2019-02-05 01:45

reporter  

Reproduce5.zip (3,730 bytes)

wp

2019-02-05 10:41

developer   ~0113859

I thought I had changed that... (did not save?). Anyway, should be fixed now.

> For bar series, it is just 0 on the Y axis.

Not necessarily. The bar series is freely configurable as a property. It divides the values in two groups: the bars for larger values are drawn upward, those for smaller values are drawn downward.

Marcin Wiazowski

2019-02-06 00:47

reporter   ~0113878

I performed thorough tests, as you asked:



Original problem: FIXED.

In Reproduce.zip, left chart works ideally. Right chart's behavior is: when first data point is in the requested Y range, i.e. in <-1, +INF), then it is taken into account in margin calculation. Since first point's mark has 3 lines of text (second's has 1 line of text - i.e. less), a margin for 3 lines of text is added below -1, so first mark is fully visible.

When first data point is BELOW the requested Y range, i.e. is below -1, then it is NO LONGER taken into account in margin calculation. So only the second data point is used in margin calculation, thus a margin for only 1 line of text is added below -1. As a consequence, first mark becomes partially invisible.

As long as aditional margin for marks is applied unconditionally - i.e. is applied even when without it all marks would be still visible - this cannot be done better. So: fixed.



Original problem (Note 1): FIXED.

For MarkPositions = lmpInside, bevavior is still similar as described above. The behavior on the right chart is: when first point is in <-1, +INF), it is used in margin calculation, so a margin for 3 lines of text is added ABOVE the chart. When first point is below -1, it is NO LONGER used in margin calculation - since the second point doesn't have its mark ABOVE it, a margin for 0 lines of text is added above the chart - i.e. nothing is in fact added.

The lmpInsideCenter is no longer available, but changing line series to bar series and setting MarkPositionCentered to True doesn't change anything (except marks' origins, of course).

As long as aditional margin for marks is applied unconditionally - i.e. is applied even when without it all marks would be still visible - this cannot be done better. So: fixed.



Original problem (Note 2): FIXED.

Same as in the "Original problem" above - only vertically flipped.



Original problem (Note 3): TO IGNORE.

This was my mistake.



Note 1-4: FIXED.

The lmpInsideCenter is no longer available, but:
- after changing lmpInsideCenter to lmpPositive, everything works properly,
- after changing lmpInsideCenter to lmpNegative, everything works properly,
- after changing lmpInsideCenter to lmpInside, everything works properly,
- after changing line series to bar series and setting MarkPositionCentered to True, everything works properly.



Note 5-6: FIXED.

In all tested cases, axis marks don't disappear anymore.



Note 7: FIXED.

This was just a merging problem in the repository.



Note 8: FIXED.

"y" variable is properly initialized now.



Note 9: FIXED.

The boolean expression is as it should be now.



Note 10: FIXED.

FLoBound and FUpBound are used now.



Note 11: FIXED.

The lmpInsideCenter mode has been removed. Current TBasicPointSeries.GetLabelDirection() implementation works properly.



Note 12: FIXED.

Chart painting works properly now.



Note 13: FIXED.

Chart works properly now.



Note 14: FIXED.

Multiline marks are handled properly now - in EnsureGuaranteedSpace() etc.



Note 15: NOTHING TO FIX - WORKS AS DESIGNED.





All other problems described above have been moved to separate bug reports.

Marcin Wiazowski

2019-02-06 00:47

reporter   ~0113879

According to above, this topic can be closed, at last.

Please close if you have no objections.

wp

2019-02-06 09:51

developer   ~0113894

Some of the patches are contained in Laz 2.0.0, the rest will be backported to 2.0.2.

Marcin Wiazowski

2019-02-06 20:36

reporter   ~0113907

So can we close this report? If so, please feel free to do this.

wp

2019-02-06 23:16

developer   ~0113910

Didn't I resolve it? Anyway, it is resolved now. Please close it to remove it from the usual lists.

Issue History

Date Modified Username Field Change
2019-01-05 18:19 Marcin Wiazowski New Issue
2019-01-05 18:19 Marcin Wiazowski Status new => assigned
2019-01-05 18:19 Marcin Wiazowski Assigned To => Alexander S. Klenin
2019-01-05 18:19 Marcin Wiazowski File Added: Animation.gif
2019-01-05 18:19 Marcin Wiazowski File Added: Reproduce.zip
2019-01-05 18:20 Marcin Wiazowski File Added: ThisBugCanBeUseful.png
2019-01-05 18:43 wp Assigned To Alexander S. Klenin => wp
2019-01-06 23:43 wp File Added: MarkPositions.zip
2019-01-06 23:58 wp Note Added: 0113228
2019-01-07 03:26 Marcin Wiazowski Note Added: 0113230
2019-01-07 23:07 wp File Deleted: MarkPositions.zip
2019-01-07 23:07 wp File Added: MarkPositions.zip
2019-01-07 23:12 wp Note Added: 0113243
2019-01-08 15:30 wp Note Added: 0113268
2019-01-08 15:31 wp Note Edited: 0113268 View Revisions
2019-01-08 15:33 wp Note Edited: 0113268 View Revisions
2019-01-08 15:33 wp Fixed in Revision => 60021, 60027
2019-01-08 15:33 wp LazTarget => 2.0
2019-01-08 15:33 wp Status assigned => resolved
2019-01-08 15:33 wp Resolution open => fixed
2019-01-08 15:33 wp Target Version => 2.0
2019-01-10 19:22 Marcin Wiazowski Note Added: 0113310
2019-01-10 19:22 Marcin Wiazowski Status resolved => assigned
2019-01-10 19:22 Marcin Wiazowski Resolution fixed => reopened
2019-01-10 19:23 Marcin Wiazowski File Added: InsideCenterA.png
2019-01-10 19:23 Marcin Wiazowski File Added: InsideCenterB.png
2019-01-10 19:24 Marcin Wiazowski File Added: InsideCenterC.png
2019-01-10 19:24 Marcin Wiazowski File Added: InsideCenterD.png
2019-01-10 19:25 Marcin Wiazowski File Added: Reproduce2.zip
2019-01-11 00:23 wp Note Added: 0113318
2019-01-12 00:14 Marcin Wiazowski Note Added: 0113342
2019-01-12 01:21 wp Note Added: 0113344
2019-01-12 01:25 wp Note Edited: 0113344 View Revisions
2019-01-12 07:32 wp Note Added: 0113347
2019-01-12 07:47 wp Note Added: 0113348
2019-01-12 08:24 wp Fixed in Revision 60021, 60027 => 60021, 60027, 60057-60060
2019-01-12 08:24 wp Note Added: 0113349
2019-01-12 08:24 wp Status assigned => resolved
2019-01-12 08:24 wp Resolution reopened => fixed
2019-01-12 20:08 Marcin Wiazowski Note Added: 0113360
2019-01-12 21:37 Marcin Wiazowski Note Added: 0113364
2019-01-12 21:37 Marcin Wiazowski Status resolved => assigned
2019-01-12 21:37 Marcin Wiazowski Resolution fixed => reopened
2019-01-12 21:37 Marcin Wiazowski File Added: Comparison.png
2019-01-12 21:38 Marcin Wiazowski File Added: Reproduce3.zip
2019-01-13 01:00 wp LazTarget 2.0 => -
2019-01-13 01:00 wp Status assigned => resolved
2019-01-13 01:00 wp Resolution reopened => open
2019-01-13 01:00 wp Target Version 2.0 =>
2019-01-13 01:01 wp Status resolved => assigned
2019-01-13 01:01 wp Resolution open => reopened
2019-01-13 01:02 wp Relationship added related to 0034857
2019-01-13 10:39 wp Note Added: 0113373
2019-01-13 10:51 wp Note Edited: 0113373 View Revisions
2019-01-13 10:51 wp Relationship added related to 0034861
2019-01-13 10:52 wp Relationship added related to 0034862
2019-01-13 10:52 wp Relationship added related to 0034863
2019-01-13 16:23 wp Note Added: 0113380
2019-01-14 01:02 wp Fixed in Revision 60021, 60027, 60057-60060 => 60077
2019-01-14 01:02 wp LazTarget - => 2.0
2019-01-14 01:02 wp Note Added: 0113388
2019-01-14 01:02 wp Status assigned => resolved
2019-01-14 01:02 wp Resolution reopened => fixed
2019-01-14 01:02 wp Target Version => 2.0
2019-01-14 01:04 wp Note Edited: 0113388 View Revisions
2019-01-14 17:44 Marcin Wiazowski Note Added: 0113406
2019-01-14 17:44 Marcin Wiazowski Status resolved => assigned
2019-01-14 17:44 Marcin Wiazowski Resolution fixed => reopened
2019-01-14 17:45 Marcin Wiazowski File Added: Reproduce4.png
2019-01-14 17:45 Marcin Wiazowski File Added: Reproduce4.zip
2019-01-14 23:05 wp Note Added: 0113413
2019-01-14 23:05 wp Status assigned => resolved
2019-01-14 23:05 wp Resolution reopened => fixed
2019-01-15 00:10 Marcin Wiazowski Note Added: 0113416
2019-01-15 13:05 wp Note Added: 0113425
2019-01-15 13:05 wp Status resolved => assigned
2019-01-15 13:05 wp Resolution fixed => reopened
2019-01-15 13:10 wp Note Edited: 0113425 View Revisions
2019-01-15 13:11 wp Fixed in Revision 60077 => 60077, 60088
2019-01-15 13:11 wp Status assigned => resolved
2019-01-15 13:11 wp Resolution reopened => fixed
2019-01-16 01:11 Marcin Wiazowski Note Added: 0113434
2019-01-18 21:16 Marcin Wiazowski Note Added: 0113462
2019-01-18 21:56 Marcin Wiazowski Note Added: 0113463
2019-01-21 00:44 wp Relationship added related to 0034896
2019-02-05 01:44 Marcin Wiazowski Note Added: 0113857
2019-02-05 01:44 Marcin Wiazowski Status resolved => assigned
2019-02-05 01:44 Marcin Wiazowski Resolution fixed => reopened
2019-02-05 01:44 Marcin Wiazowski File Added: Animation5.gif
2019-02-05 01:45 Marcin Wiazowski File Added: Reproduce5.zip
2019-02-05 10:41 wp Note Added: 0113859
2019-02-05 10:41 wp Status assigned => resolved
2019-02-05 10:41 wp Resolution reopened => fixed
2019-02-06 00:47 Marcin Wiazowski Note Added: 0113878
2019-02-06 00:47 Marcin Wiazowski Status resolved => assigned
2019-02-06 00:47 Marcin Wiazowski Resolution fixed => reopened
2019-02-06 00:47 Marcin Wiazowski Note Added: 0113879
2019-02-06 09:51 wp Fixed in Revision 60077, 60088 =>
2019-02-06 09:51 wp LazTarget 2.0 => 2.0.2
2019-02-06 09:51 wp Note Added: 0113894
2019-02-06 09:51 wp Status assigned => resolved
2019-02-06 09:51 wp Resolution reopened => fixed
2019-02-06 09:51 wp Target Version 2.0 => 2.0.2
2019-02-06 20:36 Marcin Wiazowski Note Added: 0113907
2019-02-06 20:36 Marcin Wiazowski Status resolved => assigned
2019-02-06 20:36 Marcin Wiazowski Resolution fixed => reopened
2019-02-06 23:16 wp Note Added: 0113910
2019-02-06 23:16 wp Status assigned => resolved
2019-02-06 23:16 wp Resolution reopened => fixed
2019-02-07 01:45 Marcin Wiazowski Status resolved => closed