>I pretty much agree with you on all counts. GDI+ for the Report has already opened up a world of possiblities that a few have just started to explore, and given the same for the Screen/Forms would allow for some pretty awesome data presentation, not to mention the ability to update the look and feel of certain interface elements. It'd be powerful, and also shore up some of the deficiencies that VFP has had where graphics/drawing are concerned.
>
>I suspect the VFPT is looking for suggestions that are more geared toward "interop" with VS and SQL Server, at least I see Ken mention it in about every other post he makes now. <g> But it is one of the things I'd like to see in Sedna anyways. Reason... because it's powerful and it would be super simple for the VFPT to do. There is already an HDC somewhere in there for that off-screen bitmap, all they have to do is expose it to us. It would be nice if they gave us a beforepaint event that had that HDC as a parameter, too. But for right now I'd settle for the HDC and use bindevents to do the rest.
>

Agree, but the issue it is:
How we can control the drawing's Zorder, respect to the Form's members objects ?
This is not easy to do.

>>Hi Craig,
>>Well, I am much more interested using GDI/GDI+ for reporting purposes then drawing graphics on the screen/form, but if drawing/writing on a form was made easy, then whole bunch of interesting things could be done by ourselves instead of 'nagging' all the time to M$ for this or that :)
>>
>>Perhaps we would hv all bunch of custom controls available in downloads here for little or no cost.
>>
>>Can u imagine, if programmaticaly composing report output was made easy 8-9
>>years ago, while people were still struggling to convert their (free) DOS
>>reporting into VFP, how meny people wld opt for writing their own reporting
>>objects/engines instead of having to 'push frx beyond limits'.
>>
>>Aldough FRX is very versatile/easy reporting tool for most of common
>>reports, having possibility to do 'freehand' report writing would overcome
>>all it's limits long time before VFP9, and moreover things like XFRX/PDFL
>>came along.
>>
>>Rgds++
>>Sergio
>>
>>>Exactly what I'm saying. Not VIA the VFP9 report, but like the VFP9 Report GDI+ access works now... only this time make it so we can do the same way for the user interface (a.k.a Forms/Screen). This could be as simple as giving us access to the HDC of the off-screen bitmap just prior to VFP repainting it to the screen. Using GDI+ we can EASILY do the rest. I stress easily, as the basic concept is possible now, but it takes some pretty intense code to make it work effectively, and in the end there are certain things you simply can't do because we can't access that off-screen bitmap that VFP uses.
>>>
>>>>>Agreed. What I'm hoping the VFP Team can do is give us a GDI+ layer for UI just like in VFP report.
>>>>
>>>>Hi Craig,
>>>>Why just like VFP9 report ? (and only via VFP9 report)
>>>>Why not programmatic, freehand drawing for screens, bitmap files and
>>>>most defenetely direct writing to printers ?
>>>>
>>>>Idea is old and simple, it is called FREEDOM :)
>>>>
>>>>Rgds++
>>>>Sergio