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). I say "acceptable" because we will still run into some of the odd rendering problems that can currently be seen in VFP when an ActiveX control is contained within a VFP control (bleed through for instance). However, it will be wholly useable as these bugs have not stopped VFP devs from working with ole controls and containership, so it will not stop VFP devs from making good use of the client window canvas.

In the end, most of the rendering difficulties and bugs have to do with VFP's use of off-screen bitmaps and the rendering of controls that are not real windows (merely rendered on to the off-screen bitmap that is then bitblt to the VFP form's surface. All of these rendering techniques that VFP utilizes are a hold over from the days when Fox was multi-platform. We've experimented with some ideas of getting access to these off-screen (in memory) buffers and drawing directly to them before VFP renders the content to the form, but even in searching through the memory of a VFP process and all of the GDI handles that VFP produces as it runs we have not yet been successful finding the exact pieces that we need or a solution that works (so close and yet so far). The GDIPlusX library's rendering capabilities and performance will keep improving as we try and discover new techniques. The client window canvas is just the next evolution in this process of improvement. It will also play a part in some of the other ideas we've been exploring such as simulating new base class controls for VFP.

So many ideas, so little time to implement them all. :) Hopefully the VFP community participation in VFPX will continue to grow as we move forward with the various projects that are out there and the new projects that will be added in the coming years. There are some serious possibilities and VFPX projects such as GDIPlusX are a clear indication that VFP can be significantly enhanced using the extensibility provided in VFP.


>Hi Bo,
>
>I realised myself that drawing directly on the form is unmanageable.
>
>If I understood idea, ImageCanvas is sort of bound to the underlying memory bitmap simillar to ordinary form textbox being bound to a variable or a field and then all refreshing is done automatically.
>
>What is the idea with that ClientWindow ?
>
>By now I found my perfect scenario with ImageCanvas placed within scrollableContainer by CarlosA/MalcolmG.
>Don't tell me that I will have to rewrite my stuff again because this one will be like 10 times faster :0)
>
>VFPX rocks :)