Hi Craig,

>The idea behind the client window canvas is that we will create a window within the VFP form and render to that newly created window directly. This will be a real window (has an HWND) and we'll draw to that window directly. This is similar to throwing a picturebox ActiveX control on a VFP form in the sense that it has an HWND and receives its own windows messages from the queue. When using a VFP Image or Container as the canvas we have an added layer of abstraction that degrades performance. When drawing to VFP's forms directly the performance is better, but it is nearly impossible to simulate zorder (containership) correctly as Bo already intimated. So, the basic idea is to get the performance of rendering directly to a window and still be able to have acceptable respect for zorder (there are some other really neat things that can be accomplished once a developer has a canvas with an HWND too, I might add).

You bet ;)
That wld be really great!

So people could theoretically create all bunch of new controls which
will be pure fox (with Gdi+x) without having to register them as Dll/activeX ?

One apeal from my side;
I am right now doing my own class libraries for reporting purposes which are based on GDI+x examples. So I took ImageCanvas as my major drawing surface.
All drawing code (samples) were applied (by rule?) in its 'BeforeDraw' method. Now my not very humble 'request' is to be able to draw stuff from everywhere and to various canvases/devices. Be that form various methods, odd function, datadriven from my prg based classes etc.

My quest last couple of weeks was to create such classes which would alow me to switch drawing surface without much of hassle while still using the same drawing class/instances of mine. While I got Cesar.S and Christof.W to save my day by providing me with some crucial tips, I was just thinkering that this transparency of drawing surface could be somehow helped/supported within GdiPlusX architecture.

I achieved that somehow by parsing/piercing .HWND/oGfx references back and fourth, so my own procedures can draw seamlessly on screen or printer for instance, but that in fact drive-arround rather then (high)way to go :) Since you people (whole Gdi+x crew) are now paving the new ways with GdiPlusX, having couple of flash-lit signs, roadmaps and few watter wells digged up along that still narow path, would be of great help to turn it into major highway :)

For instance; One of those 'watter wells' would be support to seamlessly switch drawings canvases. Plain example is from screen to printer, or from ImageCanvas to _screen etc. Imho, especially important thing would be printing support. Few well designed classes wrapping printing related API calls, (and maybe some other plumbings that I am not even aware of as of just yet) to support/control printing process would make world of usability differerence here!

I can find such things (code samples/libraries that provide full control over printing process) in almost every major forum (C++,VB,NET etc) except VFP who craves for control / reliable printing the most.
Not every VFP developer knows C++, API structures etc. If there was not
for GdiPlusX which is pure fox I would'nt be able to do anything with myriad of Gdi+ API calls. But now this is all available to ordinary
VFP developers via GdiPlusX and other VFPX projects. So why not having
it all by extending GdiPlusX to printing aspects of whole story.
I collected samples here and there (CesarS,SergeyB etc) to do what I want, but imagine if versatille printer control library was readily available to people to do their odd printing jobs/tasks having GdiPlusX drawing power at their fingertips already! (Be that separate VFPX project or part of GdiPlusX :)) )

Possible real life instance/application;
I can for instance draw vessel/cargo containers on the screen, drag them left and right, or create vessel rotation paths on the underlying seamaps etc, get it all ready&willing to be printed in A3 format, but can I reliably control printer device context to switch into A3>Landscape, taking papper from upper tray while printer is mostly printing A4 (portrait)?

Scattered examples doing this or that are NOT the answer here, while having
reliable class/library that deals with this kind of things, would bring
whole thing to all new level.

Another thing;
Aldough GdiPlusX has been greatly supported by blogs and CodePlex discussions I could not seem to locate some comprehensive white papper on GdiPlusX overall architecture/implementations and plumbings.
Is there such thing already somewhere ?
I found Gdi+x samples very well presented and usefull, (that is what I use
solely to implement my own drawings) but having some general architecture/implementation guidelines would be very nice.

Thank You for your insightfull post &
Keep rockin' that VFP(X) boat please :)

Sergio