ChartTools questions
lazarus / 55-TAChart

----------------------------------------------------------------------
wp · 2012-09-19 16:22

When playing with ChartTools in relation with another forum discussion
I came across some questions/ideas:
 Datapoint drag tool: Is there a way to restrict dragging to the
horizontal or vertical axis? It does not always make sense to change
both coordinates. This is particularly annoying with a bar series when
the bar width changes because x has been changed.
 Crosshair tool: It would be nice if the additions to TDistanceTool
would be available also for the crosshair tool. I mean the possibility
to express the point coordinates (Position) in various units. In
contrast to the distance tool it is clear which series is involved and
how to apply the transformations correctly.
 Crosshair tool: It is a bit disturbing that the cross hair appears
only after a short mouse move, even if the mouse is sufficiently close
to a data point. Is there a special reason why the code called in
MouseMove is not used also at MouseDown?

----------------------------------------------------------------------
Ask · 2012-09-20 14:29

QuoteDatapoint drag tool: Is there a way to restrict dragging to the
horizontal or vertical axis?Since r38765, you can handle OnDrag event
as follows:
Code: [Select]procedure TForm1.ChartToolset1DataPointDragTool1Drag(
  ASender: TDataPointDragTool; var APoint: TPoint);
begin
  APoint.X := ASender.Origin.X;
end;
This also helps the user from the neighbor thread.

QuoteCrosshair tool: ... the possibility to express the point
coordinates (Position) in various units. Yes, this was the idea. I
want, however, to refactor the interface using TPointRef type, so it
will take some time.

QuoteCrosshair tool: ... why the code called in MouseMove is not used
also at MouseDown?Just an oversight, I have used only keyboard shifts
to toggle crosshair in my projects.
Fixed in r38757.

----------------------------------------------------------------------
wp · 2012-09-20 23:00

Thank you for the fixes, but the solution for the DatapointDragTool
does not always work correctly. Please run the attached demo and drag
the first bar before doing anything else. And when you restart and
drag the second bar, the third bar moves a little bit to the right.

Quoteit will take some time.No problem

----------------------------------------------------------------------
wp · 2012-09-21 07:30

Datapoint drag tool with bar series: When running the demo of the
previous posting you'll notice that dragging only works at the center
of the bars - that's where the "true" x value sits. This is clear from
the way how the drag tool operates, but may be confusing to a user who
does not know this background. So, ideally it should be possible to
drag the bar starting at any location at the upper edge of the bar,
not only in the vicinity of the coordinate value.

Datapoint drag tool with pie series: I've never used PieSeries
productively so far. But I wonder how the drag tool would be used with
that since there are no clear x,y directions.

----------------------------------------------------------------------
Ask · 2012-09-21 12:51

QuoteDatapointDragTool does not always work correctlyThis was rather
fundamental issue related to the rounding:
while moving data point to the "same" image position might actually
change graph position.
Should be fixed in r38781 -- note that I had to change OnDrag
definition.

Quoteit should be possible to drag the bar starting at any location at
the upper edge of the barSet GrabRadius to approximate width of the
bar?

----------------------------------------------------------------------
wp · 2012-09-21 13:59

Thank you for the fix, works well now.

QuoteSet GrabRadius to approximate width of the bar?Yes, but then the
y accuracy will change also. I think BarSeries  should use an
"anisotropic" grab tolerance internally, like

Code: [Select]var
  grabTolerance : TDoublePoint;
//...
  grabTolerance.X := Max(GrabRadius, BarWidth);
  grabTolerance.Y := GrabRadius;

i.e, the GetNearestPoint function for BarSeries should not use the
circular PointDist function, but treat x and y separately.

BTW, what is the easiest way to get the BarWidth? And what if the
BarWidth changes along the axis? Looks like it's getting complicated
again...

----------------------------------------------------------------------
Ask · 2012-09-21 15:55

QuoteI think BarSeries  should use an "anisotropic" grab
toleranceWhile that is certainly possible, I am not sure it should be
the default.
For example, I think it is quite conceivable that a user might want to
declare that the bar should be grabbed by the "center line", which is
the opposite "anisotropy direction".

Also, consider "offset", stacked, rotated and 3-d bars.

As a compromise, I have added OnDragStart event in r38786.
You can achieve "anisotropic" tolerance as follows:
Code: [Select]procedure
TForm1.ChartToolset1DataPointDragTool1DragStart(
  ASender: TDataPointDragTool; var AGraphPoint: TDoublePoint);
begin
  if Abs(Chart1.YGraphToImage(ASender.Origin.Y) -
Chart1.YGraphToImage(AGraphPoint.Y)) > 2 then
    ASender.Handled;
end;

I can consider adding either specialized TBarSeriesDragTool with bar-
specific properties,
or some properties to TBarSeries which control the behavior of
GetNearestPoint.
However, I have a feeling that the use case is too narrow.

Additionally, I do agree that something like TSeriesClickTool, which
would take into account geometry of each series type, would be useful.
This is, however, much harder to implement.

Quotewhat is the easiest way to get the BarWidth?Since r38790, use
GetBarWidth function.

See "Bars" page to the "dragdrop" demo since r38791.

Quotepie series ... how the drag tool would be used with
thatCurrently, pie series (as well as polar series) do not implement
GetNearesPoint, so drag tool would ignore it.
You can click on pie slices in "radial" demo to get an idea of what
may be possible in the direction.

----------------------------------------------------------------------
wp · 2012-09-21 21:20

Thank you. Very nice.

QuoteI have a feeling that the use case is too narrow.This may be
right.

Sorry to bombard you with so many requests, but another point comes to
my mind when working with the drag tools: It would be nice if the user
could abort a dragging operation - maybe he picked the wrong data
point, or had selected the drag tool incidentally. I appreciate in
other applications that it is possible to cancel dragging by pressing
ESC. I know that this behavior could be implemented by means of the
key events of the tool, but I feel that this is a rather fundamental
feature which should be in the tool by default.

[Edit] Another idea would be to create a combined CrosshairDragTool to
give the user feedback on which data point is being dragged.

----------------------------------------------------------------------
Ask · 2012-09-27 15:54

Quotecancel dragging by pressing ESCImplemented for all drag-based
tools in r38864-38866.

I have set the default to true for TDataPointDragTool, left it false
for others.
What is your opinion on the default for zooming and panning?
Can you test what Delphi does?

This feature is subject to usual problems with the chart focus.
Since r38867, I have implemented Chart.AutoFocus property,
which hopefully solves the problem. See demo changes in r38869 for an
example.

Please test, especially in complex interfaces where chart coexists
with many other controls on the form.

----------------------------------------------------------------------
wp · 2012-09-28 09:06

Thank you. ESC works fine. I also agree with your choice of default
values, cancel by ESC should be on by default for the
DataPointDragTool since this is destructive, for the others it should
be off by default.

I don't have Delphi here, but I think you cannot abort the dragging at
all. And I think something like the datapoint drag tool is not
included in the standard version of TeeChart. But I'll check that
later.

I cannot reproduce the focus issue any more: when did it happen? In my
test program, I have an edit along with a chart using a crosshair tool
which reacts on CTRL and mouse move (no click). But the crosshair tool
shows up even when the edit control has the focus (Chart.Autofocus
off)

Of course, the edit control loses the focus when the Chart has
AutoFocus set even when no ChartTools are on the form. This will
certainly be annoying. If you type anything in the edit (or a
memo...), move the mouse incidentally into the chart, continue typing,
and no text is entered any more...

----------------------------------------------------------------------
Ask · 2012-09-28 14:23

QuoteAnd I think something like the datapoint drag tool is not
included in the standard version of TeeChart. Yes, my question was
mainly about cancelling drag zoom.

QuoteI cannot reproduce the focus issue any more: when did it
happen?Maybe the chart in your example has TabIndex=0, so it is
focused at the start?
You can look at changes in r38869 to see the cases where manual
SetFocus was required earlier.

QuoteThis will certainly be annoying.Sure, this is why it is off by
default.
Although this drawback is kind of obvious, perhaps some note in the
docs is in order...

----------------------------------------------------------------------
wp · 2012-09-28 15:09

After searching through the forum for the focus issue I do confirm
that DataPointCrosshairTool and DataPointHintTool still are not hidden
at KeyUp if the chart does not have the focus. With AutoFocus=true,
this works fine.

Interestingly, the data point distance tool hides the distance bar (if
not set to option permanant) at KeyUp even if the chart does not have
the focus (AutoFocus=false). If the chart does have the focus, or
AutoFocus=true, the distance tools does not work properly (does not
seem to find the starting point, in XOR mode paints a series of marks
along the track of the mouse). So, this is kind of reverse behavior.

----------------------------------------------------------------------
wp · 2012-09-28 16:48

Delphi XE2's default zooming and panning cannot be canceled by ESC.

BTW: Do you plan to drop the default zooming capability built into
TChart in favor of the zoom tools? I am asking whether I should
advertise this feature in one of the next tutorials on interactive
charing?

----------------------------------------------------------------------
Ask · 2012-09-28 17:16

QuoteDelphi XE2's default zooming and panning cannot be canceled by
ESC. Ok, then I keep it off by default.

QuoteDo you plan to drop the default zooming capability built into
TChart in favor of the zoom tools?Note that default zooming is
implemented as a built-in TZoomDragTool, similar to the built-in
TListChartSource.
I plan to drop reticule tool from built-in set (and remove it
altogether), but keep the zoom tool.

----------------------------------------------------------------------
wp · 2012-09-28 17:37

QuoteNote that default zooming is implemented as a built-in
TZoomDragTool
Didn't know that. Unfortunately there seems to be no access to the
tool, otherwise the built-in zoom would be as flexible as the separate
tool. Moreover, you could add a TPanDragTool in the same way to
enhance Delphi compatibility - in TeeChart you can pan by default
using the right mouse button.

----------------------------------------------------------------------
Ask · 2012-09-28 17:50

QuoteIf the chart does have the focus, or AutoFocus=true, the distance
tools does not work properlyShould be fixed in r38887.

Quote there seems to be no access to the tool, otherwise the built-in
zoom would be as flexible as the separate toolThat's the idea -- you
get simple interface by default or full control for the price of more
complex interface.

Quoteadd a TPanDragTool in the same way to enhance Delphi
compatibilityDone in r38888.

----------------------------------------------------------------------
wp · 2012-09-28 19:51

QuoteAfter searching through the forum for the focus issue I do
confirm that DataPointCrosshairTool and DataPointHintTool still are
not hidden at KeyUp if the chart does not have the focus.
Can you confirm this? If this is true then for Autofocus, the
Chart.SetFocus would better be called in the MouseMove and KeyDown of
these tools instead of the chart's MouseMove: in these procedures, the
tool already has been reckognized, i.e. the user already has begun to
perform a tool operation and he would be less surprised when the
active control loses focus.

Quoteadd a TPanDragTool in the same way to enhance Delphi
compatibilityWow - you are faster than the speed of light... I don't
know into which detail you want to drive Delphi compatibility (to me,
the current TChart is fine, I like your idea of the simple interface
by default), but here are some details on TeeChart user interaction:
 TChart has properties AllowZoom and AllowPan, both true by default In
addition to the right mouse button panning occurs also by the mouse
wheel controled by a property "Panning.MouseWheel" with the options
[pmwNone, pmwNormal, pmwInverted]. There is another boolean property
"Panning.InsideBounds". Zooming is controlled by a number of
additional properties -- I am posting a screen shot.

----------------------------------------------------------------------
Ask · 2012-09-29 01:26

QuoteChart.SetFocus would better be called in the MouseMove and
KeyDown of these tools instead of the chart's MouseMoveThe problem is
that chart must have focus for the KeyDown event to work, so there is
no use to call it from KeyDown.
There may be a room for tri-state TAutoFocus = (afNever, afAlways,
afOnToolActivate) or something like this.

Quoteinto which detail you want to drive Delphi compatibilityThe usual
goal is to be compatible by features, but not necessarily by
interface.
There is a special TAChartTeeChart unit which provides extra
compatibility layer for the applications that need to use both
libraries interchangeably. It may be extended when/if we have a
specific requests from users.

Quoteproperties AllowZoom and AllowPan, both true by defaultAllowZoom
already exists, although it currently disables only zoom drag tools.
It'll think about how useful would be to add AllowPan.

So, while I do not plan to add any tool-specific properties to the
TChart, let's see whether Delphi properties have analogs in
appropriate tools:

Quote"Panning.MouseWheel" with the options [pmwNone, pmwNormal,
pmwInverted]=TPanMouseWheelTool with WheelUpDirection. I wonder which
direction it pans -- vertical or horizontal?

QuotePanning.InsideBounds=TBasicPanTool.LimitToExtent ?

Zoom properties:
TeeChartTAChartAllowEnabledAnimated+AnimatedStepsAnimationInterval+Ani
mationStepsBrushnone (this is for filling the inside of drag zoom
rectangle, right?)Direction+UpLeftZoomsprobably
RestoreExtentOnHistoryTChartExtentHistory? What does this property
do?KeepAspectRatioRatioLimitKeyShift+MouseButtonShiftMinimumPixelsnone
-- what does it do?PenFrame

----------------------------------------------------------------------
wp · 2012-09-29 09:27

QuoteThe problem is that chart must have focus for the KeyDown event
to work, so there is no use to call it from KeyDown.
Then I still must have problems to reproduce this issue. For me the
KeyDown always works, there are only issues at KeyUp.

Quotetri-state TAutoFocus = (afNever, afAlways, afOnToolActivate)
Yes, this sounds good.

QuoteI wonder which direction it pans -- vertical or horizontal?
Vertical only, I did not find a way for horizontal panning with the
mouse wheel.

QuotePanning.InsideBounds=TBasicPanTool.LimitToExtent ?
No, if set (and panning occurs by right mouse button), panning stops
when the mouse leaves the bounds of the chart - I don't like this...

QuoteBrush   none (this is for filling the inside of drag zoom
rectangle, right?)
Yes, looks a bit more "modern" than the standard rectangle (see
attached screenshot), but I can live without it.

QuoteDirection+UpLeftZooms   probably RestoreExtentOn
Did some tests: Direction restricts the zoom to one coordinate only,
like your RatioLimit; it is a nice visual aid that the zoom rectangle
is extended over the entire chart in the direction that is held
constant (BTW: Maybe I a bit confused now, but I get the feeling that
there is no difference in the zoomed result for TAChart whatever
option of RatioLimit is selected)
UpleftZooms does what it says, normally UpLeft means unzoom, if set it
zooms also, this means there is no way to unzoom any longer, you need
code for this (this case is mentioned in their help file).
Something like RestoreExtentOn seems to be unknown to TeeChart, unzoom
is always by dragging upleft (or by code)

QuoteMinimumPixels   none -- what does it do? Seems to be the minimum
distance the mouse has to travel until the zoom operation is
triggered. Their default value of 16 is too large in my impression -
you drag a small zoom rect and nothing happens...

When writing up this comparison I am impressed by the power of TAChart
(although there is a chance that Teechart Professional may have more
features -- I don't have access to it). Maybe I should take the time
to extend this comparison to other features.

----------------------------------------------------------------------
Ask · 2012-09-29 19:35

QuoteFor me the KeyDown always works, there are only issues at
KeyUp.Try the following:
1) Open tools demo
2) Set Chart1.AutoFocus = false
3) Run
4) Move mouse over the chart, then press Ctrl while not touching the
mouse
=>
For me, crosshair does not show unless I move a mouse.

Quote panning stops when the mouse leaves the bounds of the chartI
guess there might be a reason to limit this, but I can not think of it
now,
so I will pass on implementing that.

Quote there is no difference in the zoomed result for TAChart whatever
option of RatioLimit is selectedTry the following:
1) Open "extent" demo
2) Set ChartToolset1ZoomDragTool1.RatioLimit=zrlFixedX
3) Run
4) Drag a small rectangle
=>
The horizontal extent should not change
(If you tested on the tools demo, note that it sets RatioLimit at
runtime).

QuoteQuoteBrush(see attached screenshot)
Yes, not very important, but also not hard to do.
Added Brush property in r38898, 38902, 38907.
Judging by the screenshot, TeeChart draws the rectangle below the
chart, which is a cute trick, but is against the current TAChart
architecture.
Instead, I have added Transparency property in r38900.
Setting some light brush color with Transparency of 150-200 gives
quite a nice effect IMHO. Of course, it is ignored in xor mode.

It is rather easy to add transparency to other tools, but I do not
immediately see a tool which would benefit from it -- perhaps a
measure tool?

Quoteminimum distance the mouse has to travel until the zoom operation
is triggeredAlso easy, but not very useful. Will postpone until the
real need arrives.

Quoteit is a nice visual aid that the zoom rectangle is extended over
the entire chart in the direction that is held constantImplemented
similar effect in r38908. It looks good for zrlFixedX and zrlFixedY,
but perhaps slightly confusion (although correct) for zrlProportional.
Should it be made optional? If so, what should be the default?

Quotethere is a chance that Teechart Professional may have more
featuresIt certainly has. However, it suffers from some suboptimal
design choices -- partially because of a long development history, and
partially for no apparent reason.
For example, documentation seems to indicate that animated zooming is
controlled by Chart.Zoom.AnimatedSteps property, and a global(!)
AnimatedZoomFactor variable, but with no way to control animation
timer interval, etc.

Quoteextend this comparison to other featuresYes, a wiki page with
such comparison would would be useful for two reasons:
1) Provide a help for migration.
2) Identify areas where TAChart can be extended.
However, this is a serious amount of work.

----------------------------------------------------------------------
wp · 2012-09-29 21:13

Quoteunless I move a mouseYes, that must have been my problem. Without
moving the mouse I can confirm your observation.

QuoteThe horizontal extent should not change
Works now. Don't know what I did wrong.

QuoteIt is rather easy to add transparency to other tools, but I do
not immediately see a tool which would benefit from it -- perhaps a
measure tool?
Distance tool, good idea.

Quoteperhaps slightly confusion (although correct) for
zrlProportional.
Should it be made optional? If so, what should be the default?
It is nice that you simultaneously can drag the zoom rect, so you can
correct the start position with the same tool. But what is confusing
to me is that the zoom sometimes is not triggered any more, probably
if the rect is dragged too far off. I'd vote for "optional"; if above
behavior isn't a bug default should be "off", otherwise "on".

----------------------------------------------------------------------
Ask · 2012-09-30 08:19

QuoteDistance tool, good idea.Added in r38916

Quoteyou can correct the start position with the same toolNo, you
can't. Try the following:
1) In "extent" demo, set
ChartToolset1ZoomDragTool1.RatioLimit=zrlProportional
2) Run
3) Start dragging exactly from one of the points
=>
Note that selection rectangle always passes through the starting
point. It is the smallest rectangle including the one drawn by user
with the same aspect ratio as the full extent of the chart.

QuoteI'd vote for "optional"Added AdjustSelection property in r38915.

Quotezoom sometimes is not triggered any moreMake sure you either drag
in the bottom-right direction, or enable other directions in
RestoreExtentOn property.

----------------------------------------------------------------------
wp · 2012-10-01 20:45

QuoteNote that selection rectangle always passes through the starting
point.No. Use extent demo with zrlProportional. Click at the left-top
corner of the center grid rectangle (at about x=-1.8/y=1.8 ), drag to
the opposite point at x=1.8/y=-1.8. While holding the mouse button
down drag along the horizontal gridline (y=-1.8 ) to the left --> the
entire selection rectangle shifts to the left. Or from that opposite
corner drag along the vertical gridline (x=1.8 ) upwards --> the
selection rect moves up.

QuoteMake sure you either drag in the bottom-right direction, or
enable other directions in RestoreExtentOn property
Yes, that is the explanation. When the mouse in the horizontal drag
along the grid line passes the starting point, zooming no longer
occurs. When I leave only the Click in the RestoreExtentOn property I
even can drag beyond the starting point

QuoteAdded in r38916
QuoteAdded AdjustSelection property in r38915.
Work nicely, thank you

----------------------------------------------------------------------
Ask · 2012-10-02 01:10

QuoteWhile holding the mouse button down drag along the horizontal
gridline (y=-1.8 ) to the left --> the entire selection rectangle
shifts to the left. Or from that opposite corner drag along the
vertical gridline (x=1.8 ) upwards --> the selection rect moves up.
That is all true, but the rectangle still does pass through the
starting point
(or, in other words, point still is on the rectangle).

To understand the logic better, try the following:
1) Set DrawingMode=tdmNormal, Frame.Color=clGreen
2) Modify TZoomDragTool.Draw, add two lines:
Code: [Select]  ADrawer.Rectangle(CalculateDrawRect);
  ADrawer.SetPenParams(psDot, clTAColor); // add this
  ADrawer.Rectangle(FSelectionRect); //add this
  ADrawer.SetXor(false);
after
3) Try dragging

----------------------------------------------------------------------
wp · 2012-10-02 10:05

Ah - I did not read carefully enough: Your were writing "the rectangle
still passes through the starting point", but I was expecting the
starting point to stay at the same location.

Anyway, maybe such a feature would be a nice tool: a descendant of
TZoomDragTool which has a second Shift set for panning, i.e. a
"TZoomPanDragTool". It would be initiated by the first Shift (left
mouse button), and when the second Shift (e.g. right mouse button) is
added to the first Shift the tool switches to panning. I tried to
implement this behaviour as an advanced example for the
zooming/panning tutorial, but failed because the relevant quantities
are private.

----------------------------------------------------------------------
Ask · 2012-10-02 10:51

Quotea descendant of TZoomDragTool which has a second Shift set for
panning, i.e. a "TZoomPanDragTool"
How is it different from having two separate tools with corresponding
Shift values?
Or do you want to switch to panning while the mouse button is still
down?
If so, see the sample below. You can, of course, achieve the same
effect by creating descendant tool.

Code: [Select]var
  isPanning: Boolean = false;
  prevPoint: TPoint;

procedure TForm1.ChartToolset1ZoomDragTool1BeforeMouseMove(ATool:
TChartTool;
  APoint: TPoint);
var
  dd: TDoublePoint;
  ext: TDoubleRect;
begin
  if not (ssAlt in ATool.Toolset.DispatchedShiftState) then begin
    isPanning := false;
    exit;
  end;
  if isPanning then begin
    dd := Chart1.ImageToGraph(APoint) -
Chart1.ImageToGraph(prevPoint);
    ext := Chart1.LogicalExtent;
    ext.a += dd;
    ext.b += dd;
    Chart1.LogicalExtent := ext;
  end;
  prevPoint := APoint;
  isPanning := true;
  ATool.Handled;
end;

----------------------------------------------------------------------
wp · 2012-10-02 12:52

QuoteOr do you want to switch to panning while the mouse button is
still down?
Yes. The initial idea was to use the left button for dragging the zoom
rect, keep the button down, press the right button (or any other key)
to fine-adjust the position of the zoom rect. Then release the right
button, maybe drag the left button again for adjusting the zoom rect
size, etc.

Your code is interesting because it shifts the entire chart underneath
the zoom rect, this is a solution also. However, it works only with
keyboard buttons, not with the right mouse button. Pressing the right
button hides the zoom rect, and releasing it restores the original
extent.

QuoteYou can, of course, achieve the same effect by creating
descendant tool.In fact, it was my intention for the tutorial to do it
like you with the tool's events since I think it would a nice
application of the events.

----------------------------------------------------------------------
Ask · 2012-10-02 14:00

Quote use the left button for dragging the zoom rect, keep the button
down, press the right button (or any other key) to fine-adjust the
position of the zoom rectYes, that may require access to
FSelectionRect, but correctly changing it is too much for tutorial.
So instead I have added SelectionRect property with appropriate setter
in r38949.
You can now write this:
Code: [Select]  if isPanning then begin
    with TZoomDragTool(ATool) do begin
      r := SelectionRect;
      r.TopLeft += APoint - prevPoint;
      r.BottomRight += APoint - prevPoint;
      SelectionRect := r;
    end;
  end;

Quoteit works only with keyboard buttons, not with the right mouse
buttonYou have to handle MouseDown/MouseUp events to control mouse
clicks.

----------------------------------------------------------------------
wp · 2012-10-07 16:40

Ask, could you proof-read the new tutorial on chart tools?
http://wiki.lazarus.freepascal.org/TAChart_Tutorial:_Chart_Tools

Unfortunately I had to drop the combined zoom/pan tool of the previous
discussions because the tutorial, again, is quite long...

[EDIT] I forgot to ask a question: In the project in the tutorial I
had to set Chart1.ExtentSizeLimits.YMax=2.05 in order to get
horizontal zooming. In the text, I am writing of a value 2.0 which
should be ok from the data, but when you run the tutorial project with
these changes horizontal zooming (ALT + mousewheel) will stop after a
few mousewheel steps. What's wrong?

----------------------------------------------------------------------
Ask · 2012-10-07 18:12

Quotecould you proof-read the new tutorial on chart tools?Started
proof-reading, will continue tomorrow.
BTW, your last edit reverted part of my changes -- please reinstate
them.

Quotetutorial, again, is quite long...I wonder if some of the "theory"
part should be moved to a documentation,
since you previous tutorials were more "practice-oriented", and I like
that.

Quote I had to set Chart1.ExtentSizeLimits.YMax=2.05 in order to get
horizontal zooming.I did not ran it, but I suspect rounding issues.
Try setting ZoomRatio to a more precise approximation of 1/1.1

A question on the text:
QuoteThe vertical zoom direction is opposite to the direction the
mouse wheel is rotated. You can fix this by setting the
WheelUpDirection of the vertical panning tool to pdDown. I do not
quite understand this. Can you describe a problem more? Maybe it is a
bug?

Also, you use two typecast styles: "TLineSeries(Series)" and "if
Series is TLineSeries then ...".
I suggest to use "Series as TLineSeries" instead, as it is safer than
the first style and shorter than the second.

----------------------------------------------------------------------
wp · 2012-10-07 20:04

QuoteBTW, your last edit reverted part of my changes -- please
reinstate them.Sorry. Undid these changes (I am not sure if the demo
will compile, though), will continue with my own edits until you post
your final "ok" here. I am planning to add some more cross-references,
also to other tutorials.

QuoteI wonder if some of the "theory" part should be moved to a
documentationI'll think about it.

QuoteTry setting ZoomRatio to a more precise approximation of 1/1.1
Correct, works fine with 0.90909090909

QuoteQuoteThe vertical zoom direction is opposite to the direction the
mouse wheel is rotated.
I do not quite understand this. Can you describe a problem more? Maybe
it is a bug?
I mean: I rotate the mouse-wheel down and the chart scrolls up. I
would like to scroll it down also (as with the PanDragTool).
Therefore, I flip the WheelUpDirection. BTW: Which direction of the
mousewheel is "up"? To me it is the same direction as that of the
arrow on the UP key, i.e. I move the scrolling finger away from
mayself.

QuoteI suggest to use "Series as TLineSeries" instead, This is one of
the mysteries that I never understand: if I code
Code: [Select]      with (Series as TLineSeries) do begin
        x := GetXValue(PointIndex);
        y := GetYValue(PointIndex);
        ListSource.SetText(PointIndex, Format('x = %f'#13#10'y = %f',
[x,y]));
      end;
won't I dereference a nil pointer if Series is not a TLineSeries?

Another remark:
Is it a bug that the axis title jumps back and forth during zooming?

----------------------------------------------------------------------
Ask · 2012-10-08 03:28

QuoteI mean: I rotate the mouse-wheel down and the chart scrolls up. I
would like to scroll it down also (as with the PanDragTool).
Therefore, I flip the WheelUpDirection. BTW: Which direction of the
mousewheel is "up"? To me it is the same direction as that of the
arrow on the UP key, i.e. I move the scrolling finger away from
mayself.
Yes, the "up" direction is indeed as you described.
When scrolling "up", the viewport now moves in the direction of the
decreasing Y
image coordinate (which is "up" on screen).
This is the same direction as, for example, in browsers or text
editors.
So it seems to me it is already working -- do you have a case where
the direction is switched?

Quotewon't I dereference a nil pointer if Series is not a
TLineSeries?No, you will cause SErrInvalidTypeCast exception, as
described in the documentation.
So the check for nil should remain.

The point of my advice is that there are two possible error
conditions:
1) Series = nil, which is usual, and indicates that the mouse pointer
is too far from any series point, so should not cause an exception.
2) Series is not a TLineSeries, which is unusual and indicates
programmer's error, so should immediately cause an exception (as
opposed to undefined behavior with the typecast).

QuoteIs it a bug that the axis title jumps back and forth during
zooming?No so much a bug, but a feature with unintended consequences.
(Axis reserves space to fully display first and last mark).
Since r38992, you can set Axis.MarginsForMarks = false to turn it off.

I have now finished proofreading -- you may want to change typecasts
and test/synchronize the code, and the tutorial will be ready for
publication.

----------------------------------------------------------------------
wp · 2012-10-08 13:23

Thank you for reading and your suggestions. The tutorial is online
now.

Another point came to my eye while playing with the tutorial project:
Shouldn't the ZoomMouseWheelTool have a propery LimitToExtent, too,
like the PanMouseWheenTool?

To see my point run the tutorial project, move the mouse to the lower
part of the chart (e.g. minimum of the red curve), zoom in a few
steps, move the mouse to the upper part, zoom out --> regions with
y<-1 become visible. Press the "pan" toolbutton, and do one panning
step --> the chart jumps back into the window defined by
ExtentSizeLimits and LimitToExtent.

Quoteyou can set Axis.MarginsForMarks = false to turn it off.Strange -
I don't see a difference. In either case (true or false), the axis
titles still jump left/right (x title) or up/down (y title) while
rotating the mouse wheel.

----------------------------------------------------------------------
Ask · 2012-10-09 14:57

Quotethe axis titles still jump left/rightIndeed, there were two
separate issues --
should really be fixed since r39026 (behavior is now controlled by
PositionOnMarks property, but it is false by default).

----------------------------------------------------------------------
wp · 2012-10-09 19:22

Thank you. Yes, with Title.PositionOnMarks=false and MarginForMarks =
false the axis titles do not move any more (except for the case that
the y axis labels get longer, i.e. the chart gets narrower, then the x
title jumps a bit to the right -- but that's how it should be).