Is the TColorBandTool broken in TeeChart Pro 2014?

[jens.mertelmeyer]

I'm really sorry if I'm cluttering up the forum. This is most probably clearly stuff for the bug tracker.

I reported it as #758:

• Place a chart on a TFrame
• Add a series
• Goto Tools -> Add -> Axis -> Color Band
• Add the frame on a form

Does the application crash on startup?

TeeChart creates a TColorLineTool that has no name. Therefore, a TColorBandTool gets written to the DFM like this:

Code: Select all

object Chart1: TChart
	[...]
	object ChartTool1: TColorBandTool <-- It has a name. All is well.
	  Color = 8388863
	  EndValue = 8.000000000000000000
	  ResizeEnd = True
	  ResizeStart = True
	  StartValue = 6.000000000000000000
	  Transparency = 12
	  AxisID = 0
	  object TColorLineTool  <-- THIS IS BAD
		DragRepaint = True
		Value = 6.000000000000000000
		AxisID = 0
		object TAnnotationTool <-- THIS IS BAD
		  Shape.Alignment = taCenter
		  Shape.Shadow.Visible = False
		  Shape.TextAlignment = taCenter
		  TextAlignment = taCenter
		end
	  end
	  object TColorLineTool <-- THIS IS BAD
		DragRepaint = True
		Value = 8.000000000000000000
		AxisID = 0
		object TAnnotationTool
		  Shape.Alignment = taCenter
		  Shape.Shadow.Visible = False
		  Shape.TextAlignment = taCenter
		  TextAlignment = taCenter
		end
      end
	end
end

As a side effect, the form designer refuses to place frames that have a chart with a TColorBandTool. However, if a chart is placed directly on a form, you're only going to find with an access violation in VCLTee.TeEngine.pas at runtime!

My question is: Am I doing something terribly wrong or can you folks reproduce the bug report #758?

Many thanks for your time.

[Yeray]

Hello,

I've reproduced this with XE6 so I've confirmed the bug ticket and added an attachment to easily reproduce the problem.

[jens.mertelmeyer]

Thank you very much for your quick response.

Theworkaround you posted (adding the frame with the corrupted DFM at runtime) does not seem to work, however. It still bails out with an access violation when "trying to read axisID of TColorLineTool". I have added the callstack to the bug report.

It should be noted that I tried it on XE5. I'll try it on XE6 later this day.

[jens.mertelmeyer]

Hi there.

I know that there are probably a lot of "criticals" or "show stoppers" out there. Can you give a rough estimate about the priority of this report (758)? Do you have any hints how one could work around it or even fix it?

I tried understanding the sources but I have great trouble understanding the DFM serialisation which is a completely new topic to me.

Best regards and many thanks in advance.

[Yeray]

Hello,

Excuse us for the delay here.
We've been investigating it and I'm afraid we haven't found a definitive way to fix the problem, but it seems that if we put a Name then we start getting problems in simpler situations than having the chart in a frame. So I'm afraid at the moment we can't fully support the ColorBand when the chart is in a Frame.

The workaround you posted (adding the frame with the corrupted DFM at runtime) does not seem to work, however. It still bails out with an access violation when "trying to read axisID of TColorLineTool". I have added the callstack to the bug report.

It seems it only crashes if you change some property in any of the ColorBand's ColorLines (ie the StarLine pen color) at design time.
Could you please try if leaving the Start and End ColorLines in the ColorBand as per default at design time and modifying them (if you wish to do so) only at runtime works as a workaround for you? Ie:

Code: Select all

procedure TForm1.FormCreate(Sender: TObject);
var f : TFrame2;
begin
  f:=TFrame2.Create(Self);
  f.Align:=alClient;
  f.Parent:=Self;

  f.ChartTool1.StartLine.Pen.Color:=clYellow;
end;

[jens.mertelmeyer]

Thank you for your reply.

Steema being aware of it means a lot.

I have upgraded from 2014.11.140425 BETA to 2014.11.140512 and it now seems to work flawlessly when creating and adding the TFrame at runtime. I think with a bit of additional work, I'll be able to temporarily work around the issue.

The TeeChart upgrade has, however, changed the Exceptions I'm getting:
Let's say I gave the first inner TColorLineTool of my TColorBandTool the name 'myColorLineTool1'. At runtime, the application will crash with 'Ancestor for 'myColorLineTool1' cannot be found'.

I have never seen DFM files with components that have no names. Is this really valid?


However, thanks for your time so far!

[jens.mertelmeyer]

I have a related question: Since I'm making heavy use of frames, I still don't dare to migrate from TeeChart2013 to TeeChart2014. Are there other possibilities of components without names? I somehow remember the TScrollPagerTool also creating anonymous components in the dfm.

I'm very afraid because the program will still compile fine, and you will only find out at runtime that something went terribly wrong. Do you think I'll be safe when I just try to create all forms at once and see if the application can start up?

[Narcís]

Hello jens,

Many apologies for the delayed reply.

It's not possible to know which objects are being created without a name. Probably ColorLine/Band are the only ones being used at ScrollPager and some other places. Those tools are being created internally and are not being given a name so they are neither reflected at the Object Inspector nor as form childs as they are 2nd level childs, tool internal. Giving them a name could create a duplicate name conflict if creating many tools in many different charts in the same form/frame. The error you get is because you are giving a name to the tools when you shouldn't. Somehow it is a forbidden practice.

Also, the last bugzilla attachment works fine with XE6.

[jens.mertelmeyer]

Thank you for the elaborate reply.

I am confused by your observation: The only attachment to Bug #758 is attachment #199: Please note that the attachment is a workaround. Since you cannot add the (corrupted?) frame at designtime, you have to create and add it at runtime. This is what the attachment does.

XE 6.1
The posted workaround executes and runs fine. You can, however, still not drop the Frame on the Form. Well, you can, but upon executing the program, it will crash with an "EReadError: 'Parent of '' not found". With XE6 Update 1, I 'm not getting a "List index out of bounds". Just the "Parent not found". Maybe it was different with stock XE6.