Best charting package

[Joe]

Is any one charting packing considered to be the "best"? We've used ChartFX
but wasn't too happy about the way data had to be populated along with some
other issues which slip my mind right now and Dundas has bugs and doesn't do
a good enough job displaying axis labels and is very slow to paint large
numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Linda Liu [MSFT]]

Hi Joe,

Thank you for posting here!

I notice that you have posted the same question in our
microsoft.public.dotnet.framework.windowsforms.con trols newsgroup, which I
have already responded. So please check my answer there and if you need any
further assistance on this particular issue, please reply to me in that
thread so I can follow up with you in time.

For your convenience, I have include my reply as follows:

I am not sure which charting packing is considered to the the "best". I
have searched the google and found "Nevron .NET Vision", which is the
ultimate suite for creating unique and powerful data presentation
applications with spectacular data visualization capabilities and wins the
best Charting and Graphing Component for .NET of MSN2D.com 2005 Reade.

For more information on Nevron .NET Vision, please visit the following link.

http://www.nevron.com

Thank you and have a nice day!
Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Fabio]

"Joe" <jb*******@noemail.noemailha scritto nel messaggio
news:%2***************@TK2MSFTNGP04.phx.gbl...

Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Did you see the ZedGraph package?

http://zedgraph.org/wiki/index.php?title=Main_Page

It does not have nevron special effects but it seems well done and it's
free...

--
www.neodatatype.net

[rockclimber90]

You may want to take another look to Chart FX, Chart FX for Visual
Studio 2005 has been completely redesigned making it easier to use.

More info at: http://www.softwarefx.com/sfxNetProducts/cfxVs2005/

Francisco Padron
www.chartfx.com
Joe wrote:

Is any one charting packing considered to be the "best"? We've used ChartFX
but wasn't too happy about the way data had to be populated along with some
other issues which slip my mind right now and Dundas has bugs and doesn't do
a good enough job displaying axis labels and is very slow to paint large
numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[dotNET learner]

Yes, try ZedGraph. It is a free, yet quite powerful .NET control. Works well
in Windows
as well as ASP.NET application.

Have a look at the samples.
http://zedgraph.org/wiki/index.php?title=Sample_Graphs
There is also a good tutorial at:
http://www.codeproject.com/csharp/zedgraph.asp

---

"Fabio" <zn*******@virgilio.itwrote in message
news:eZ**************@TK2MSFTNGP02.phx.gbl...

>
"Joe" <jb*******@noemail.noemailha scritto nel messaggio
news:%2***************@TK2MSFTNGP04.phx.gbl...

>Is any one charting packing considered to be the "best"? We've used
ChartFX but was't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Did you see the ZedGraph package?

http://zedgraph.org/wiki/index.php?title=Main_Page

It does not have nevron special effects but it seems well done and it's
free...

--
www.neodatatype.net

[Robert Dede]

Hello,

Thank you for evaluating ProEssentials. We just released v6 if you hadn't
downloaded it. As for native .NET (managed code) concerns: managed code is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software. You mentioned a few
100% managed tools and found them to contain bugs and render slow. Two
things Gigasoft avoids with a passion. If anyone reading this has specific
concerns on the value of managed code (as a 3rd party tool), I'd love to
hear them. Gigasoft needs to hear real-world concerns before it commits to
100% managed code. Bugs, Speed, and Memory management are not valid
concerns. Bugs and Slowness obviously are not an advantage. As for memory
management, .NET is great for beginners or rare programmers. However,
professionally programmed products should keep track of their own memory,
and can easily do so with 100% accuracy. Leaving memory management up to a
black-box is a shortcut purely designed for beginners and
engineers/scientists who don't regularly program. Native code (unmanaged)
will exist for many years to come. Being an early adopter simply in the name
of being an early adopter is not practical. Gigasoft takes a purely
practical direction, as should everyone. .NET has other advantages related
to beginners and non-regular programmers, mostly related to easy of use.
However, a 3rd party managed/unmanaged tool can coexist with the .NET IDE
and still provide more stability, more speed, and .NET type ease of use.
Thus, providing the best of both worlds and an optimum solution for the
problem; how to achieve the best possible charting functionality; which
should not be confused with the problem; how to most easily get generic
charts into an application. Charting is a huge subject, and using one
charting tool for all scenarios is not practical. Tools are cheap enough to
buy the right tool for the job. When working on a mission critical project
where speed, stability, and rendering intelligence are most important; use
ProEssentials. When you need to quickly add a generic chart holding a few
data points, maybe choose another. More on this subject can be found in my
“Letter from the President” at www.gigasoft.com

Best regards,

Robert Dede

President

Gigasoft, Inc.

ro****@gigasoft.com


"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Jon Skeet [C# MVP]]

Robert Dede wrote:

Thank you for evaluating ProEssentials. We just released v6 if you hadn't
downloaded it. As for native .NET (managed code) concerns: managed code is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software.

Java code is managed code, Java has been around for over 10 years and
is used in many mission critical applications.

<snip>

As for memory management, .NET is great for beginners or rare programmers. However,
professionally programmed products should keep track of their own memory,
and can easily do so with 100% accuracy.

They can do so - but certainly not easily. Do you think programmers
ought to keep track of which of their variables end up in registers,
too?

Personally I find that not having to worry about memory management
(beyond having it as a permanent thing to be aware of, and avoid being
silly about it) is a great productivity benefit - it means I can
concentrate on adding features rather than keeping track of memory.

Give me managed code any day - as a regular, professional programmer.

Jon

[Bruce Wood]

Jon Skeet [C# MVP] wrote:

Robert Dede wrote:

Thank you for evaluating ProEssentials. We just released v6 if you hadn't
downloaded it. As for native .NET (managed code) concerns: managed code is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software.

Java code is managed code, Java has been around for over 10 years and
is used in many mission critical applications.

<snip>

As for memory management, .NET is great for beginners or rare programmers. However,
professionally programmed products should keep track of their own memory,
and can easily do so with 100% accuracy.

They can do so - but certainly not easily. Do you think programmers
ought to keep track of which of their variables end up in registers,
too?

Personally I find that not having to worry about memory management
(beyond having it as a permanent thing to be aware of, and avoid being
silly about it) is a great productivity benefit - it means I can
concentrate on adding features rather than keeping track of memory.

Give me managed code any day - as a regular, professional programmer.

I agree with Jon, and I take issue with Robert Dede's post, but for
other reasons.

Robert is right: it really doesn't matter to the charting functionality
whether the package is written in managed code or unmanaged code. There
are some considerations (see below), but if I'm calling an API to draw
pretty shapes then I don't really care what's happening under the
covers.

However, Robert, if you want to impress C# programmers and sell your
charting package, avoid writing dense screeds on why garbage collection
is for "occasional" programmers and non-professionals. (Not "rare"
programmers. I like to think of myself as "well done," thanks.) I say
this for two reasons: 1) I couldn't care less how much better it is for
you to write in a non-GC language; I care about how your package
interacts with my language of choice. "It was easier for me to write"
is not a selling feature; "It's easier for you to use" is. 2) It tells
me nothing about what your charting package will do for me.

That said, a someone developing in managed code, a package written in
unmanaged code brings up several concerns.

1) I want the package to interact seamlessly with my platform of
choice. If the package has a nice, managed, .NET interface that is well
documented, exposes powerful functionality, integrates nicely with .NET
Framework types, and uses exceptions and return codes to signal errors
in accordance with standard .NET practices, then I'm happy.

If, on the other hand, I have to talk directly to a COM object, and the
only kind of exception I get back is COMException, and the
documentation is written for C++ programmers, then I'm not so happy.

As I said before, in the end I don't care what the package is written
in. I care about what it can do, how stable it is, and how easy it is
to use from C#.

2) Deployment. If I have to install a COM component as part of my
deployment then that's extra work. It's not the end of the world, but
it's an extra step I need to take, and it means that some deployment
scenarios aren't possible.

3) Security. If I'm calling a COM component then I may need additional
privileges granted to my .NET application. That may or may not be a
problem depending upon my deployment / runtime scenario.

Address these three concerns and I won't care whether the package is
written in C#, C++, or Forth.

[Robert Dede]

Hi Jon,

Give me managed code any day - as a regular, professional programmer.

I totally agree, and I didn't make this clear enough, I questioned managed
code as a foundation for mission-critical commercial tools. Not software in
general. The more efficient, fast, and stable the building blocks, the
better the final application. It's generally best to optimize as much as
possible; and using tools which are themselves optimized is an easy way to
bolt-on optimization without any extra work, just the decision to take
advantage of it.

best regards,

Robert Dede

Gigasoft, Inc.



"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:11**********************@q2g2000cwa.googlegro ups.com...

Robert Dede wrote:

>Thank you for evaluating ProEssentials. We just released v6 if you
hadn't
downloaded it. As for native .NET (managed code) concerns: managed code
is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software.

Java code is managed code, Java has been around for over 10 years and
is used in many mission critical applications.

<snip>

>As for memory management, .NET is great for beginners or rare
programmers. However,
professionally programmed products should keep track of their own memory,
and can easily do so with 100% accuracy.

They can do so - but certainly not easily. Do you think programmers
ought to keep track of which of their variables end up in registers,
too?

Personally I find that not having to worry about memory management
(beyond having it as a permanent thing to be aware of, and avoid being
silly about it) is a great productivity benefit - it means I can
concentrate on adding features rather than keeping track of memory.

Give me managed code any day - as a regular, professional programmer.

Jon

[Bob]

Getting back to your original question on chart packages, I looked at
quite a few and thought that Dundas had the richest feature set and
fairly easy to develop with, though I think you are right about the
axis labeling and speed. Please let us know how your eventual
selection goes.

On Jan 23, 4:23 pm, "Robert Dede" <[e-mail]:

Hi Jon,

Give me managed code any day - as a regular, professional programmer.I totally agree, and I didn't make this clear enough, I questioned managed

code as a foundation for mission-critical commercial tools. Not software in
general. The more efficient, fast, and stable the building blocks, the
better the final application. It's generally best to optimize as much as
possible; and using tools which are themselves optimized is an easy way to
bolt-on optimization without any extra work, just the decision to take
advantage of it.

best regards,

Robert Dede

Gigasoft, Inc.

"Jon Skeet [C# MVP]" <[e-mail] in messagenews:11**********************@q2g2000cwa.go oglegroups.com...

Robert Dede wrote:

Thank you for evaluating ProEssentials. We just released v6 if you
hadn't
downloaded it. As for native .NET (managed code) concerns: managed code
is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software.

Java code is managed code, Java has been around for over 10 years and
is used in many mission critical applications.

<snip>

As for memory management, .NET is great for beginners or rare
programmers. However,
professionally programmed products should keep track of their own memory,
and can easily do so with 100% accuracy.

They can do so - but certainly not easily. Do you think programmers
ought to keep track of which of their variables end up in registers,
too?

Personally I find that not having to worry about memory management
(beyond having it as a permanent thing to be aware of, and avoid being
silly about it) is a great productivity benefit - it means I can
concentrate on adding features rather than keeping track of memory.

Give me managed code any day - as a regular, professional programmer.

Jon

[Jon Skeet [C# MVP]]

Robert Dede <ro****@gigasoft.comwrote:

Give me managed code any day - as a regular, professional programmer.

I totally agree, and I didn't make this clear enough, I questioned managed
code as a foundation for mission-critical commercial tools.

For a development company, Eclipse is a pretty mission-critical tool.
The fact that it's free doesn't make it any less important - and it's
almost entirely in Java.

Not software in general. The more efficient, fast, and stable the
building blocks, the better the final application.

I find that "stable" is the most important of those, and it's much
easier to be stable on a managed platform.

It's generally best to optimize as much as possible; and using tools
which are themselves optimized is an easy way to bolt-on optimization
without any extra work, just the decision to take advantage of it.

No, it's *not* generally best to optimise as much as possible. It's
best to optimize in a targeted way, where it makes the biggest
difference. Optimization often works against maintainability, so should
be focused on the usually small amount of code where it will make a big
difference.

Yes, it's good to use tools which are optimised - but I have no
problems with the performance of .NET, and I would rather pay component
developers to build more of the features I want than to build a
*slightly* faster product which takes significantly more development
effort by being written in unmanaged code.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Robert Dede]

Hi Bruce,

Thanks for the feedback. And please let me reiterate so we don't go off in
a million directions. The root of this thread was related to managed code as
a commercial tool, not software development in general.

As I told Jon, I didn't make this clear enough; I only questioned managed
code as a foundation for mission-critical commercial tools. Not software in
general. The more efficient, fast, and stable the building blocks, the
better the final application. It's generally best to optimize as much as
possible; and using tools which are themselves optimized is an easy way to
bolt-on optimization without any extra work, just the decision to take
advantage of it.

All your issues, 1,2 and 3 are based on the assumption we use COM.
ProEssentials' WinForm and WebForm interfaces, and our primary DLL, use no
COM in any way. We do include ActiveX interfaces within our suite of tools
for those who choose this interface or when the need arises. I'm no fan of
COM as a component interface. I remember the days of VBXs where the
component interface was a pure component interface. The entire interface
could be clearly documented in a 60 page manual. With ActiveXs, MS's primary
component interface was made into a subset of the operating system; which
was technically convenient, but overkill given the problem; (how to create a
component interface, and why would a component need to be registered with
the OS?) It's one of MS's worse decisions to base a component interface off
COM, and the root cause of COM's bad rap. And when .NET was initially
released, the feature that got the most cheers was "No Registration
Necessary." As is with ProEssentials, just place your App.Exe,
Gigasoft.ProEssentials.Dll and Pegrp32d.Dll in the same dir and run.

best regards,

Robert Dede
Gigasoft, Inc.

"Bruce Wood" <br*******@canada.comwrote in message
news:11*********************@13g2000cwe.googlegrou ps.com...

>
Jon Skeet [C# MVP] wrote:

>Robert Dede wrote:

Thank you for evaluating ProEssentials. We just released v6 if you
hadn't
downloaded it. As for native .NET (managed code) concerns: managed code
is
now over 3 years old and I'm still not convinced 100% managed code is a
foundation for mission critical commercial software.

Java code is managed code, Java has been around for over 10 years and
is used in many mission critical applications.

<snip>

As for memory management, .NET is great for beginners or rare
programmers. However,
professionally programmed products should keep track of their own
memory,
and can easily do so with 100% accuracy.

They can do so - but certainly not easily. Do you think programmers
ought to keep track of which of their variables end up in registers,
too?

Personally I find that not having to worry about memory management
(beyond having it as a permanent thing to be aware of, and avoid being
silly about it) is a great productivity benefit - it means I can
concentrate on adding features rather than keeping track of memory.

Give me managed code any day - as a regular, professional programmer.

I agree with Jon, and I take issue with Robert Dede's post, but for
other reasons.

Robert is right: it really doesn't matter to the charting functionality
whether the package is written in managed code or unmanaged code. There
are some considerations (see below), but if I'm calling an API to draw
pretty shapes then I don't really care what's happening under the
covers.

However, Robert, if you want to impress C# programmers and sell your
charting package, avoid writing dense screeds on why garbage collection
is for "occasional" programmers and non-professionals. (Not "rare"
programmers. I like to think of myself as "well done," thanks.) I say
this for two reasons: 1) I couldn't care less how much better it is for
you to write in a non-GC language; I care about how your package
interacts with my language of choice. "It was easier for me to write"
is not a selling feature; "It's easier for you to use" is. 2) It tells
me nothing about what your charting package will do for me.

That said, a someone developing in managed code, a package written in
unmanaged code brings up several concerns.

1) I want the package to interact seamlessly with my platform of
choice. If the package has a nice, managed, .NET interface that is well
documented, exposes powerful functionality, integrates nicely with .NET
Framework types, and uses exceptions and return codes to signal errors
in accordance with standard .NET practices, then I'm happy.

If, on the other hand, I have to talk directly to a COM object, and the
only kind of exception I get back is COMException, and the
documentation is written for C++ programmers, then I'm not so happy.

As I said before, in the end I don't care what the package is written
in. I care about what it can do, how stable it is, and how easy it is
to use from C#.

2) Deployment. If I have to install a COM component as part of my
deployment then that's extra work. It's not the end of the world, but
it's an extra step I need to take, and it means that some deployment
scenarios aren't possible.

3) Security. If I'm calling a COM component then I may need additional
privileges granted to my .NET application. That may or may not be a
problem depending upon my deployment / runtime scenario.

Address these three concerns and I won't care whether the package is
written in C#, C++, or Forth.

[Bruce Wood]

On Jan 23, 3:10 pm, "Robert Dede" <[e-mail]:

Hi Bruce,

Thanks for the feedback. And please let me reiterate so we don't go off in
a million directions. The root of this thread was related to managed code as
a commercial tool, not software development in general.

No, the root of this thread was asking for recommendations of charting
packages. It had nothing to do with managed code as a commercial tool
or otherwise.

As I told Jon, I didn't make this clear enough; I only questioned managed
code as a foundation for mission-critical commercial tools. Not software in
general. The more efficient, fast, and stable the building blocks, the
better the final application. It's generally best to optimize as much as
possible; and using tools which are themselves optimized is an easy way to
bolt-on optimization without any extra work, just the decision to take
advantage of it.

All your issues, 1,2 and 3 are based on the assumption we use COM.

You read my examples as being my issues. If I had to sum up everything
I said, it would be this: if I were interested in your charting
package, I would not care whether it was written in managed or
unmanaged code. I would care about secondary issues that can be a
problem with managed code, which are: 1) seamless integration with
..NET; 2) deployment; and 3) security. Rather than telling me that your
package is not managed code and you like it better that way, tell me
that it works seamlessly with .NET (including throwing managed
exceptions where appropriate, using standard .NET enumerations, etc.),
deploys easily (you told me that in your reply), and doesn't cause any
security headaches over and above what a managed application might
cause.

So, in a way I agreed with your original post: who cares how the
package is written, so long as the way it's written doesn't cause
additional problems for me as a developer.

(Just out of interest, if your charting package is written in unmanaged
code, and you don't provide a COM wrapper, how do I interact with it
from .NET? Do you provide managed wrappers for your API?)

[Robert Dede]

Hi Joe / readers,

I want to make some final comments; and this is my original point I wanted
to make. I just initially failed terribly at making it.

My Query:
Joe’s comment that ProEssentials was good but not 100% managed .NET.

My Response:
Should a tool that mathematically processes thousands of data points, via
intensive and iterative multi-pass artificial intelligence (AI) be written
in managed code? The correct answer is No, and ProEssentials falls into
this category. It handles large quantities of data with the most AI,
multiple rendering aspects taking dozens of passes to create a quality image
independent on data, control-shape, control-size, font-size, plotting-type,
and hundreds of additional options. A serious charting tool has to have
some of the most complex logic available within any third party tool
category. ProEssentials builds the most attentive and potentially robust
image magnitudes faster than any other 100% managed charting tool on the
planet; and that’s a fact the competition can not honestly deny. Sure the
competition can do some things ProEssentials can not do, but it does them
slowly, with less AI, so usability is limited to smaller data sets and
static configurations. When you consider the unique amount and type of
intense iterative processing that is involved, ProEssentials should be
native unmanaged code, there is no dependency on COM, and no worries in any
way; based on our twelve year track record. Experience with multiple tools
is the only true way to fully understand the differences ProEssentials has
to offer. Tools are cheap, easy to use, there’s lots of variety (I love the
idea of a flash based charting tool to show 4 to 8 data-points, just don’t
try it with 10,000 data-points). Buy the right tool for the job; don’t beat
a square peg into a round hole.

As for the memory management issue, I’ll make a point with a real-world
exercise. Take one of your highly used classes, add a custom Dispose
method, put a break-point in it, run/debug your app that’s creating many
instances of this object. You’ll find; surprising most; the breakpoint won’t
hit until your app shuts down. Is your managed app continuously using more
and more memory until it is shut down? That’s my point. There are many
scenarios within .NET where Dispose should be explicitly called and it’s not
getting called.

~~~~~ Deep Thoughts~~~~~~ by Robert Dede,
When I go hunting, I don’t drive my Lexus, I drive my truck. I never know
when I’ll cross a rough road or even go off-road. I also drive my truck
around town. If I could only afford one vehicle, it would have to be my
truck, it’s more useful. I can afford both the truck and the Lexus so I’m
lucky to have a choice. Charting is very similar; it’s a large diverse
subject; just as diverse as off-road versus highway driving. If you can
afford multiple tools, it’s best to use the tool that best suits the road.
If you can’t afford multiple tools, I’d hate to take my Lexus off-road. I
wouldn’t do it. I’d have to compromise, stop, turn-around, and limit my
freedom. It’s a good thing there are so many charting choices. Diversity and
variety are good things and should be fostered, not stifled. Utilize
diversity and don’t sweat the little stuff.
www.gigasoft.com


"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Jon Skeet [C# MVP]]

Robert Dede <ro****@gigasoft.comwrote:

<snip>

As for the memory management issue, I=3Fll make a point with a real-world
exercise. Take one of your highly used classes, add a custom Dispose
method, put a break-point in it, run/debug your app that=3Fs creating many
instances of this object. You=3Fll find; surprising most; the breakpoint won=3Ft
hit until your app shuts down. Is your managed app continuously using more
and more memory until it is shut down? That=3Fs my point. There are many
scenarios within .NET where Dispose should be explicitly called and it=3Fs not
getting called.

Dispose is specifically *not* for memory management. It's for unmanaged
resource management. And no, my .NET apps *don't* continuously use more
and more memory until they're shut down - they rise to a plateau, which
is exactly what I'd expect. The CLR/GC knows when more memory is
required than is currently free, and can take appropriate action by
either collecting unused objects or allocating more memory.

Will some objects which are unused be left until the end of the
application? Yes. Does that bother me much? Not so long as they're
claimed if the memory is required. Generational garbage collection has
some pretty well-understood traits, and so long as you're aware of
these, there shouldn't be very many shocks in store.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Joe]

Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range of
data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime, Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a label
for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so much
because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except ChartFX
doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For example
if you scroll a panel to a chart that was out of view, the chart will take
some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval either.
It's very possible I didn't completely understand the documentation on
manually populating it.

As a final note I would like to say to all the charting companies that are
following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come to a
decision. If I was incorrect with any of my evals please let me know. We
have not made a firm decision yet and I do have a little time left to do a
little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Robert Dede]

Thank you Joe,

You are doing the industry a huge service; and a prime example of how
everyone should research before they buy. This level of research will pay
big dividends, it always does, for you and the industry. Kudos!

Cons - Well the unmanaged code causes a slight problem for us. Not so much
because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application

Email me some example screen shots of this, I'm very curious and will
address it. ro****@gigasoft.com

best regards,
Robert Dede
Gigasoft, Inc.


"Joe" <jb*******@noemail.noemailwrote in message
news:eH**************@TK2MSFTNGP04.phx.gbl...

Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range
of data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime,
Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a label
for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so much
because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except ChartFX
doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For
example if you scroll a panel to a chart that was out of view, the chart
will take some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval either.
It's very possible I didn't completely understand the documentation on
manually populating it.

As a final note I would like to say to all the charting companies that are
following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come to
a decision. If I was incorrect with any of my evals please let me know. We
have not made a firm decision yet and I do have a little time left to do a
little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

>Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Dan Reber]

Joe,

Did you test Dundas at all when you did the last set of comparisons? I
did not see it listed. We are about to decide on a component and we found
that Dundas has the best support out there along with great functionality.
I know that you stated that it was buggy and slow, but what version did you
test?

Thanks

Dan

"Joe" <jb*******@noemail.noemailwrote in message
news:eH**************@TK2MSFTNGP04.phx.gbl...

Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range
of data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime,
Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a label
for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so much
because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except ChartFX
doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For
example if you scroll a panel to a chart that was out of view, the chart
will take some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval either.
It's very possible I didn't completely understand the documentation on
manually populating it.

As a final note I would like to say to all the charting companies that are
following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come to
a decision. If I was incorrect with any of my evals please let me know. We
have not made a firm decision yet and I do have a little time left to do a
little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

>Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Robert Dede]

Hi Dan,

Support is another important factor; thanks for bringing it into this
thread. Considering I personally answer many of our tech support questions,
often within minutes, often at odd hours of the day and weekends, and mostly
wrote and documented (www.gigasoft.com/webhelp/peonlref.htm) the entire
ProEssentials product; and I’ve been answering charting questions for over
12 years; I would speculate it's impossible that any other major charting
company offers better support than Gigasoft. If you add that Gigasoft
support is free, along with free version maintenance releases, for life.
Most would agree Gigasoft’s support and customer service can't be beat. Just
pick up the phone or send us an email for a quick response. No hassle, no
matter how old your version.

I occasionally help customers reviving products that are 10 years old using
our ProEssentials v2. We don’t force an upgrade or force
support/maintenance fees. Upgrades should come naturally at the customer’s
pace. We always try to be as helpful as possible, and never hassle, spam,
or pressure our customer-base in any way. We never send mass emails and you’ll
never get spam from Gigasoft.

Once you become a Gigasoft customer, you will want to be a customer for
life. That's our goal, and we achieve it.

best regards,
Robert Dede
Gigasoft, Inc.
ro****@gigasoft.com
817 431 8470
"Dan Reber" <dr****@nospam.comwrote in message
news:Od***************@TK2MSFTNGP03.phx.gbl...

Joe,

Did you test Dundas at all when you did the last set of comparisons? I
did not see it listed. We are about to decide on a component and we found
that Dundas has the best support out there along with great functionality.
I know that you stated that it was buggy and slow, but what version did
you test?

Thanks

Dan

"Joe" <jb*******@noemail.noemailwrote in message
news:eH**************@TK2MSFTNGP04.phx.gbl...

>Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range
of data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime,
Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a
label for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so
much because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except
ChartFX doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For
example if you scroll a panel to a chart that was out of view, the chart
will take some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval
either. It's very possible I didn't completely understand the
documentation on manually populating it.

As a final note I would like to say to all the charting companies that
are following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come
to a decision. If I was incorrect with any of my evals please let me
know. We have not made a firm decision yet and I do have a little time
left to do a little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

>>Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated
along with some other issues which slip my mind right now and Dundas has
bugs and doesn't do a good enough job displaying axis labels and is very
slow to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but
it's not a native .NET package.

Thanks,
Joe

[Robert Dede]

Hi Bob / Chris,

I downloaded Nevron and I'm now prepared to see for myself, but since I
don't know the Nevron product, Bob, please post a small code sample. Porting
the code below to a nevron nChartControl1 that I can paste into a formload
event. Just a simple xy line chart, 6 series, 8000 data points each series,
thin solid lines.

// Prepare images in memory, prevents flicker, simply plays image to memory
and then bitblits to screendc //
Pesgo1.PeConfigure.PrepareImages = true;
// Pass Data //
Pesgo1.PeData.Subsets = 6;
Pesgo1.PeData.Points = 8000;
Int32 s, p;
float fOffset;
for(s = 0; s < 6; s++)
{
fOffset = 1.0F;
for(p = 0; p < 8000; p++)
{
fOffset += (float)((Rand_Num.NextDouble() * 50.0));
Pesgo1.PeData.X[s, p] = fOffset;
Pesgo1.PeData.Y[s, p] = (float)((p + 1) + (Rand_Num.NextDouble() *
3000)) + ((s * 140.0F));
}
Pesgo1.PeLegend.SubsetLineTypes[s] =
Gigasoft.ProEssentials.Enums.LineType.ThinSolid;
}
// Various other common features //
Pesgo1.PePlot.Method = SGraphPlottingMethod.Line;
Pesgo1.PeGrid.LineControl = GridLineControl.Both;
Pesgo1.PeConfigure.RenderEngine = RenderEngine.Hybrid; // This won't port as
unique to ProEssentials, but use what ever means to improve performance as
would be used in the real-world.
Pesgo1.PeConfigure.AntiAliasGraphics = false;
Pesgo1.PeConfigure.AntiAliasText = false;
Pesgo1.Refresh();

If interested in the RenderEngine feature, or any feature, simply go to
www.gigasoft.com/webhelp/peonlref.htm for info. Use search or index to find
what you want fastest.

The above plot renders "instantly", and due to the noisy data, no data
filtering is being invoked, which ProEssentials will also do if the data is
smooth, allowing even more potential performance gains.

Or if Nevron has something similar, this example shows how to pass data
directly, essentially a memcpy, capable of passing a million points
instantly. Performance in passing data is just as important as performance
in rendering.

Int32 s, p, o;
float fOffset;
float[,] pXData = new float[6, 8000];
float[,] pYData = new float[6, 8000];
for(s = 0; s < 6; s++)
{
fOffset = 1.0F;
for(p = 0; p < 8000; p++)
{
fOffset += (float)((Rand_Num.NextDouble() * 50.0));
pXData[s, p] = fOffset;
pYData[s, p] = (float)((p + 1) + (Rand_Num.NextDouble() * 3000)) + ((s
* 140.0F));
}
Pesgo1.PeLegend.SubsetLineTypes[s] =
Gigasoft.ProEssentials.Enums.LineType.ThinSolid;
}
Gigasoft.ProEssentials.Api.PEvsetW(Pesgo1.PeSpecia l.HObject,
Gigasoft.ProEssentials.DllProperties.XData, pXData, 48000);
Gigasoft.ProEssentials.Api.PEvsetW(Pesgo1.PeSpecia l.HObject,
Gigasoft.ProEssentials.DllProperties.YData, pYData, 48000);

I'm looking forward to your post.

best regards,

Robert Dede
Gigasoft, Inc.

"Joe" <jb*******@noemail.noemailwrote in message
news:eH**************@TK2MSFTNGP04.phx.gbl...

Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range
of data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime,
Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a label
for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so much
because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except ChartFX
doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For
example if you scroll a panel to a chart that was out of view, the chart
will take some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval either.
It's very possible I didn't completely understand the documentation on
manually populating it.

As a final note I would like to say to all the charting companies that are
following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come to
a decision. If I was incorrect with any of my evals please let me know. We
have not made a firm decision yet and I do have a little time left to do a
little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

>Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated along
with some other issues which slip my mind right now and Dundas has bugs
and doesn't do a good enough job displaying axis labels and is very slow
to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but it's
not a native .NET package.

Thanks,
Joe

[Robert Dede]

Hi,

I wanted to add; if anyone is to try the below example, a few more lines of
code will simplify the task...

At the top of the file add a using statement...
using Gigasoft.ProEssentials.Enums;

Within the formload event, at top of initialization...
Random Rand_Num = new Random(unchecked((int)DateTime.Now.Ticks));

And the example below is actually plotting 96,000 points as DataShadows is
on by default (so fast, I first didn't realize it.) Performance can be
doubled with...
Pesgo1.PePlot.DataShadows = Gigasoft.ProEssentials.Enums.DataShadows.None;

best regards,
Robert Dede
Gigasoft, Inc.
www.gigasoft.com
"Robert Dede" <ro****@gigasoft.comwrote in message
news:zs******************************@giganews.com ...

Hi Bob / Chris,

I downloaded Nevron and I'm now prepared to see for myself, but since I
don't know the Nevron product, Bob, please post a small code sample.
Porting the code below to a nevron nChartControl1 that I can paste into a
formload event. Just a simple xy line chart, 6 series, 8000 data points
each series, thin solid lines.

// Prepare images in memory, prevents flicker, simply plays image to
memory and then bitblits to screendc //
Pesgo1.PeConfigure.PrepareImages = true;
// Pass Data //
Pesgo1.PeData.Subsets = 6;
Pesgo1.PeData.Points = 8000;
Int32 s, p;
float fOffset;
for(s = 0; s < 6; s++)
{
fOffset = 1.0F;
for(p = 0; p < 8000; p++)
{
fOffset += (float)((Rand_Num.NextDouble() * 50.0));
Pesgo1.PeData.X[s, p] = fOffset;
Pesgo1.PeData.Y[s, p] = (float)((p + 1) + (Rand_Num.NextDouble() *
3000)) + ((s * 140.0F));
}
Pesgo1.PeLegend.SubsetLineTypes[s] =
Gigasoft.ProEssentials.Enums.LineType.ThinSolid;
}
// Various other common features //
Pesgo1.PePlot.Method = SGraphPlottingMethod.Line;
Pesgo1.PeGrid.LineControl = GridLineControl.Both;
Pesgo1.PeConfigure.RenderEngine = RenderEngine.Hybrid; // This won't port
as unique to ProEssentials, but use what ever means to improve performance
as would be used in the real-world.
Pesgo1.PeConfigure.AntiAliasGraphics = false;
Pesgo1.PeConfigure.AntiAliasText = false;
Pesgo1.Refresh();

If interested in the RenderEngine feature, or any feature, simply go to
www.gigasoft.com/webhelp/peonlref.htm for info. Use search or index to
find what you want fastest.

The above plot renders "instantly", and due to the noisy data, no data
filtering is being invoked, which ProEssentials will also do if the data
is smooth, allowing even more potential performance gains.

Or if Nevron has something similar, this example shows how to pass data
directly, essentially a memcpy, capable of passing a million points
instantly. Performance in passing data is just as important as performance
in rendering.

Int32 s, p, o;
float fOffset;
float[,] pXData = new float[6, 8000];
float[,] pYData = new float[6, 8000];
for(s = 0; s < 6; s++)
{
fOffset = 1.0F;
for(p = 0; p < 8000; p++)
{
fOffset += (float)((Rand_Num.NextDouble() * 50.0));
pXData[s, p] = fOffset;
pYData[s, p] = (float)((p + 1) + (Rand_Num.NextDouble() * 3000)) +
((s * 140.0F));
}
Pesgo1.PeLegend.SubsetLineTypes[s] =
Gigasoft.ProEssentials.Enums.LineType.ThinSolid;
}
Gigasoft.ProEssentials.Api.PEvsetW(Pesgo1.PeSpecia l.HObject,
Gigasoft.ProEssentials.DllProperties.XData, pXData, 48000);
Gigasoft.ProEssentials.Api.PEvsetW(Pesgo1.PeSpecia l.HObject,
Gigasoft.ProEssentials.DllProperties.YData, pYData, 48000);

I'm looking forward to your post.

best regards,

Robert Dede
Gigasoft, Inc.

"Joe" <jb*******@noemail.noemailwrote in message
news:eH**************@TK2MSFTNGP04.phx.gbl...

>Thanks to all those who replied. I knew there would be differences in
opinions and I also knew that there would be feed back from the companies
that make some of the chart packages.

As for my decision, I haven't made one just yet. Here's what I've learned
from my different evals. Each chart package was tested with a wide range
of data. The performance was tested with the following data samples:
100 series and 30 data points per series
3370 series and 30 data points per series
870 series and 4 data points per series

We also had different data types on the X-Axis. Int, double, DateTime,
Text

ProEssentials:
Pro - Excellent performance (probably the best)
Pro - Displays labels on the axes rounded correctly. For example if the Y
values ranged from 2.8 - 27.13, the labels display in round numbers and
divided up nicely.
Pro - The DateTime handling is very good.
Pro - Handles all value types on the X-Axis (text requires setting a
label for those that don't know)
Pro - Auto scales values for the Axis labels. For example 5,000,000 will
display as 5m (or similar)
Cons - Well the unmanaged code causes a slight problem for us. Not so
much because of the code itself but the context menus and charting panels
themselves give an old appearance and cannot be made to match my
application
ChartFX:
Pro - There performance is very good
Pro - Looks very nice and has very useful extensions.
Pro - DateTime handling is very good.
Pro - Axes labels scale very well. Similar to ProEssentials except
ChartFX doesn't do the Auto scaling unless we use the log.
Con - There is a delay with the initial painting of the charts. For
example if you scroll a panel to a chart that was out of view, the chart
will take some time to draw with large data.

Nevron:
Pro - Has a lot of "eye candy"
Con - Performance doesn't seem to be a match to ProEssentials or ChartFX
Con - You need to know your series types in advance or creating them. You
cannot toggle using a type or gallery property (correct me if I'm wrong)
Since I hit the 2 Cons above I stopped testing it early.

Infragistics:
This one had it's own set of issues so I didn't continue this eval
either. It's very possible I didn't completely understand the
documentation on manually populating it.

As a final note I would like to say to all the charting companies that
are following this:
I understand all the complexities that go into creating these packages. I
tested some of the features which are most important to us to help come
to a decision. If I was incorrect with any of my evals please let me
know. We have not made a firm decision yet and I do have a little time
left to do a little more testing.

-Joe

"Joe" <jb*******@noemail.noemailwrote in message
news:%2***************@TK2MSFTNGP04.phx.gbl...

>>Is any one charting packing considered to be the "best"? We've used
ChartFX but wasn't too happy about the way data had to be populated
along with some other issues which slip my mind right now and Dundas has
bugs and doesn't do a good enough job displaying axis labels and is very
slow to paint large numbers of series and data points.

We're currently evaluating ProEssentials which we are happy with but
it's not a native .NET package.

Thanks,
Joe