Our problem is this:
We want to be able to pass a TCanvas into a DLL and then modifiy various
properties of the canvas (ie. the font, brush, etc properties) from within
the DLL.
Our attempts thus far have procedure an "EAccessViolation" exception.  I
guess the question is - is it possible to do, and if not, are there any
alterniatives?

Thanx,
Tim.

PS : Could you please reply to cade...@cadesystems.com.au as well as to the
news group.

On Tue, 15 Dec 1998 14:12:51 +1100, "Len Dalziel"

It's not really possible. The reason is that there is a set of
resource managers that cache GDI objects (pens, brushes and fonts).
When you use a DLL, it has its own copies of the three resource
managers. The problem occurs when you pass a canvas back and forth,
because the resource managers understandably get confused about what
objects the canvas is currently holding.

An alternative (I'm pretty sure it will work, although I haven't tried
it) would be to pass just the canvas handle to the DLL. In the DLL,
you'd do this:

 MyCanvas := TCanvas.Create;
 try
   MyCanvas.Handle := HandlePassedFromTheCaller;
   try
     // use the canvas here
   finally
     MyCanvas.Handle := 0;
   end;
 finally
   MyCanvas.Free;
 end;

-Steve

hmmm...

I don't quite know what to say to that, but I sure want to say
something!!!
Seems like runtime packages (and the like) would break if this is true.

Alternative: Lock the canvas down and somehow pass the canvas handle
and the GDI object handles and somehow reset them via API calls.

Joe
--
Joe C. Hecht
http://home1.gte.net/joehecht/index.htm

On Tue, 15 Dec 1998 02:20:52 -0600, "Joe C. Hecht" <joehe...@gte.net>
wrote:

Nope. Packages are "smarter" than ordinary DLLs. Unlike what happens
with ordinary DLLs, when you use packages, there's only one copy of
the Application global object, one copy of the Graphics unit global
objects (including the resource managers), etc.

-Steve

On Tue, 15 Dec 1998 02:20:52 -0600, "Joe C. Hecht" <joehe...@gte.net>
wrote:

Not really. Packages are designed to handle objects. DLLs, OTOH, use a
separate copy of the VCL for each DLL. Passing an object to or from a
package is easy. Passing an object to or from a DLL isn't.

---
Yorai Aminov (TeamB)
http://ourworld.compuserve.com/homepages/yaminov
(TeamB cannot answer questions received via email.
To contact me for any other reason remove nospam from my address)

Your programm and your DLL should use the vcl runtime package.

I have several applications that pass the TCanvas.Handle to a DLL (wriiten
in C), where I use good old Windows calls to manipulate the pens, fonts,
etc.  I don't know if these changes in the DLL are manifested back in the
Delphi parts of the application, though, cause I never had need for that.
The TCanvas.Handle is the Device Context Handle of classic Windows (HDC).

Why not take a look at the VCL code to see what happens when you release
and assign and canvas handles?

FWIW, you can always use the windows GetObject() functions to retrieve
the pen, brush, and font info from the handle upon return from the the
dll, and create pens, brushes and fonts to assign to the Canvas object.

Joe
--
Joe C. Hecht
http://home1.gte.net/joehecht/index.htm

Steve,

I believe that what you're saying is absolutely right.  I now have two
applications that pass a canvas' handle to Dlls written for me by our C
programming team.

Their have been some odd things occuring sometimes but I can't work out the
exact cause.  The second app though,  works 100% without any problems
what-so-ever and ALL drawing to the canvas is performed from within the Dll.

For your information,  I the canvas belongs to a TPaintBox component.

Regards

Stan Stern
JETCAM International Holdings Ltd.

try Using Canvas.Refresh before and after sending the DC to the DLL
(before only if you DON'T want to pass the Pen/Brush/Font settings to the
DLL)