Charting component/subsystem

Hi there,

  I wonder if anyone is using a charting component to plot functions
and graphics in dolphin applications.

  Is not critical to me right now, but I'm starting to evaluate options
to choose the more convenient when appropiate. The options I've found
until now are:

http://www.steema.com/
http://www.infosoftglobal.com/FusionCharts/LiveDemos.asp?gMenuItemId=4
http://www.xceedsoft.com/products/ChartNET/?gclid=CN32z--r1IcCFQshHgod2QKUpQ
http://www.digitalcandle.com/software.htm?cmd=1&productid=1997
http://www.dundas.com/Gallery/Chart/NET/index.aspx
http://www.anychart.com/products/anychart/index.shtml
http://www.dotnetcharting.com/overview.aspx
...others suggestions are welcome...

 I didn't found open source. The prices and features vary. The kind of
royalty free licenses for developers also vary. I offcourse want the
more beauty graphic capable, featured, well documented and designed,
cheaper, easily embedable, non OS conflictive, better supported and
easily dolphin wrappeable of all them.

  Anyone here could have interest in share efforts to make and elegant
framework wich facilitates at least basic use of one of this systems in
dolphin in the near future? In such case wich one it should be your
choice?

  cheers,

Sebastian

Hi Sebastián:
Sebastián escribió:
You're missing a good one, Steema's TeeChart ActiveX
<http://www.steema.com/>, it can be wrapped easily.

I'm attaching you a screenshot of a simple two series chart, working in
a smalltalk app, of course :-).

Plus, they can give you support in spanish language.

Regards,

--
Esteban.

You might also consider Component One Studio Enterprise which has
Component One Chart for ActiveX which does both 2D and 3D charting.
Unfortunately this is no longer available seperately, you have to buy
the whole bundle including .NET components but we've been using
Component One chart with VSE Smalltalk for years.

http://www.componentone.com/products.aspx?TabTypeID=1&PanelIndex=1&ItemType=1&ItemID=66&SubCategoryTypeID=0&TabMapID=8&tabid=2

The Brave Sir Robin.

On 5 Oct 2006 11:51:54 -0700, "Sebastián" <[hidden email]>
wrote:

Sebastián,

>  I didn't found open source. The prices and features vary. The kind of
> royalty free licenses for developers also vary. I offcourse want the
> more beauty graphic capable, featured, well documented and designed,
> cheaper, easily embedable, non OS conflictive, better supported and
> easily dolphin wrappeable of all them.

You might look at MathMorphs from Squeak.  It would be a fair amount of
work to convert, but it might be worth the effort.

Ideally, one should have a DLL with some functions that handle loops
over large numbers of elements, but somehow not force that, or least
make it easy to adapt arbitrary Smalltalk objects and collections
thereof to things that the DLL understands.

This is not at all easy, but will make you lots of friends (and probably
not much money) if you get it right :)

You will be happiest (and discover LOTS of new friends<g>) if you plan
ahead for different canvas (device context) resolutions, and allow for
bitmap, view, and printer output.


>   Anyone here could have interest in share efforts to make and elegant
> framework wich facilitates at least basic use of one of this systems in
> dolphin in the near future? In such case wich one it should be your
> choice?

Let me know what you plan to do; I might take an interest, and if I do,
I would certainly participate to some extent (I have to be careful how
much I promise to do, at least until my clone returns from vacation).
My preference for the binary part would be for something that is
C-callable vs. COM based.  That is in part because I have had _really_
bad luck with COMponents as a general class (with some glowing
exceptions), and because this really _should_ be a DLL problem rather
than a COM problem.

Ok, that last statement is not entirely true, but the spirit of it is
true.  I would change tune rapidly if the COM interfaces were well
designed (most are not), and the component does not need to be visually
hosted; it's fine for it to be optionally visual.  If one can instatiate
lots of little components (traces, legends, etc.), assemble them and get
them to dump graphical output given an HDC, I would be potentially quite
interested in using it.  If the graphs appear on "the control", I will
look elsewhere, and would advise you to do the same.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

I don't know about the others but the ComponentOne Chart ActiveX controls
come with a dll interface which can be used instead of ActiveX. This is
what we use with VSE Smalltalk and have done successfully for several
years. Dolphin does generate the COM wrappers for the ActiveX versions but
I haven't really tried actually doing anything with them yet.

The unfortunate thing with the ComponentOne solution is that they sem to
have jumped on the .NET bandwagon and don't seem to develop the ActiveX and
DLL versions of their controls any more other than minor bug fixes.

The Brave Sir Robin.


On Thu, 05 Oct 2006 16:24:50 -0500, Bill Schwab <[hidden email]>
wrote:

>Ideally, one should have a DLL with some functions that handle loops
>over large numbers of elements, but somehow not force that, or least
>make it easy to adapt arbitrary Smalltalk objects and collections
>thereof to things that the DLL understands.
>
RUN AWAY !!!

"Bill Schwab"  wrote...

> My preference for the binary part would be for something that is
> C-callable vs. COM based.  That is in part because I have had _really_ bad
> luck with COMponents as a general class (with some glowing exceptions),
> and because this really _should_ be a DLL problem rather than a COM
> problem.

Slightly off-topic, but raised by this and by a question I posed yesterday -
if you have an external component as a DLL, is there any way of generating
the interfaces to Dolphin automatically, like the Active-X wizard for COM -
or is it all obvious when you know how?

Thanks

Peter Kenny

Peter,

> Slightly off-topic, but raised by this and by a question I posed yesterday -
> if you have an external component as a DLL, is there any way of generating
> the interfaces to Dolphin automatically, like the Active-X wizard for COM -
> or is it all obvious when you know how?

Obvious and non-tedious are two different things ;)  There are a couple
of ways to automate it, though I am not aware of anything that "just
works".  The most direct approach is to wrap the function definitions
into IDL, run MIDL to get a type library (note that MIDL's error
messages are less than helpful), and then generate wrappers from it.
See Ian's archives and/or the wiki for details.

You might also look at Win32HelpParserCodeGeneratorContext in my
goodies.  It is far from perfect; note that you are on your own if the
results zap your image, so don't generate and then run code without
making backups.  My focus has shifted from an IDE extension to parsing
entire documents and/or header files.  The idea is to set up class
methods that generate "everything" and present the results in a code
generator shell for selective inclusion in the image.  It is not
something that would be directly useful to others.  If at some point I
can hook it up to a real parser (e.g. swig), I will try to separate and
release a kernel, but there is no particular time table on that.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab"  wrote...

> Peter,
>> or is it all obvious when you know how?
>
> Obvious and non-tedious are two different things ;)  There are a couple of
> ways to automate it, though I am not aware of anything that "just works".

Bill

Many thanks. I realised that I had filed away a discussion by Steve Waring
and Blair on the MIDL approach - filed away so carefully that I had
forgotten it! Hopefully when I need to do it for real I shall now be able to
find it :-)

Peter

Reading about Microsoft's plans for its Windows Vista, the 200 million
users they predict in two years and its consecuences for the developers
comunity, sooner or later, is hard not to end using .Net framework in
some way.

That should not be intrinsecally of our concern. Microsoft is investing
into the integration of the developers comunity. Who can deny the
posibility of them archieving that? At least everybody knows they
aren't in a lack of resources to archieve that. So, to especulate about
that, perhaps in 5 years from now, one can find a decent ST running on
a Microsoft's platform (.Net+ or whatever name they choose to it's next
generation of vm or platform).

By the way, OA team you should be prepared for that ! you'll still
having the responsibility to deliver us the friendliest (in several
respects) Smalltalk in the market regardeless the mechanism that makes
an image of Dolphin Smalltalk to run on a computer.

So, returning to the subject and regardeless to the component efficient
design convenience, I thought about a ocx because it's automagically
wrapped by Dolphin. Then, one can make a framework (should not be a
whale, for instance it could start as a little dolphin and be
extensible enough to scale to a whale) to use this component's features
in a ST convenient way.

By the way, sorry my dear Bill, but I agree about running away of dll
used that way. Who wants to gain such a object-persistent impedance
increase when one can choose not to have it at all?

cheers,

Sebastian

The Brave Sir Robin escreveu:

Sebastián,

> Reading about Microsoft's plans for its Windows Vista, the 200 million
> users they predict in two years and its consecuences for the developers
> comunity, sooner or later, is hard not to end using .Net framework in
> some way.
>
> That should not be intrinsecally of our concern. Microsoft is investing
> into the integration of the developers comunity. Who can deny the
> posibility of them archieving that? At least everybody knows they
> aren't in a lack of resources to archieve that.

Have a look at this:

http://www.regdeveloper.co.uk/2006/09/27/windows_vista_visual_studio_2005/

.NET has been around for (roughly) five years, so if they are not
lacking personnel, they appear to be lacking something.


 > So, to especulate about
> that, perhaps in 5 years from now, one can find a decent ST running on
> a Microsoft's platform (.Net+ or whatever name they choose to it's next
> generation of vm or platform).

Five years from now will be roughly ten years from the launch of .NET.
At some point, one has to wonder whether the market wants it.



> So, returning to the subject and regardeless to the component efficient
> design convenience, I thought about a ocx because it's automagically
> wrapped by Dolphin. Then, one can make a framework (should not be a
> whale, for instance it could start as a little dolphin and be
> extensible enough to scale to a whale) to use this component's features
> in a ST convenient way.

Don't underestimate the flexibility you will want when dealing with
multiple small collections (e.g. presentation graphics), nor the
efficiency you will need for sampled audio, etc.


> By the way, sorry my dear Bill, but I agree about running away of dll
> used that way. Who wants to gain such a object-persistent impedance
> increase when one can choose not to have it at all?

I suspect you will find that RUN AWAY!!! was Robin's usual close, not a
comment.  That aside, I am proposing nothing all that different from the
very primitives that have been with Smalltalk since it first became
practical (and that made it so).

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Peter Kenny wrote:
> Slightly off-topic, but raised by this and by a question I posed yesterday -
> if you have an external component as a DLL, is there any way of generating
> the interfaces to Dolphin automatically, like the Active-X wizard for COM -
> or is it all obvious when you know how?

There's SWIG for Smalltalk (http://commonsmalltalk.wikispaces.com),
which will generate a C DLL that wraps a C/C++ library.  Then, you can
use it to generate wrapper classes in Smalltalk.

-- Aaron