I have created a timage In the DLL, but an error occurs during the call. "cannot assign a tfont to a tfont"

I have created a timage In the DLL, but the error "cannot assign a tfont to a tfont" Delphi/Windows SDK/API appears during the call.
Http://www.delphi2007.net/DelphiAPI/html/delphi_20061118180523201.html
Functions in dll:
Function initimage (TAR: twincontrol, FN );
Oselimg: = timage. Create (NiL );
Oselimg. autosize: = true;
Oselimg. Picture. loadfromfile (FN );
Oselimg. Parent: = tar;
Oselimg. show;

Master Program The image can be successfully displayed on the form during the call, but it will always pop up
"Cannot assign a tfont to a tfont" error, how should we solve it?

Use package instead of DLL.

Do not want to use package

For the deep copy problem, use the package!

It is said that you do not need a package. Just upload an application, but I don't know the details.

Oselimg. parentfont: = false; // do not trigger font. Assign () // Add a look
Oselimg. Parent: = tar;

The Four-Star Cleaners were the first to pay tribute to the cleaners!
However, since the parentfont (derived from tcontrol) of timage does not have public or published, you need to do some work on timage. My tests are as follows:

Type
Tmyimage = Class (timage)
Private
Protected
Public
Published
Property parentfont;
End;

{$ R *. Res}

Procedure initimage (aparent: twincontrol; afilename: string );
VaR
Oselimg: tmyimage;
Begin
Oselimg: = tmyimage. Create (NiL );
Oselimg. autosize: = true;
Oselimg. Picture. loadfromfile (afilename );
Oselimg. parentfont: = false;
Oselimg. Parent: = aparent;
Oselimg. show;
End;

Exports
Initimage;
End.

... Test

VaR
Form1: tform1;
Procedure initimage (aparent: twincontrol; afilename: string); External 'image. dll ';

Implementation

{$ R *. DFM}

Procedure tform1.button1click (Sender: tobject );
Begin
Initimage (self, 'user.bmp ');
End;

Everything is as expected.

PS: I will repost the crux of this issue, hoping to have a clear understanding of similar issues.

The dll will not use the same classes as the main program even when compiled from the same source. objects will look the same, but their classes will not compare equal. that's why assigning a tfont value from the DLL to a tfont property in the main program (or the other way around) doesn' t work: the assign procedure is looking for the main program's tfont class, and never recognizes the DLL's tfont object.

Thank you again for specifying the path for the cleaners.

Let all the idiots look at it. This is the real master !!!


Zswang (with water clear) (expert outpatient cleaners), sanmaotuo (laifeng ):
If you want to contact a private employee in your spare time, please leave your contact information.

The landlord is not honest

There are no so-called masters, no so-called dummies, and people have their own strengths
This is your problem.
Take the time to help you find a solution
Whether it's solved or not, you should be grateful.
Be honest

Thank you for your attention.
Even because it is too generous, people have been cheated for a few K

Lao Feng, I often dive into your replies and tell me your MSN. Can I? My is zhiliposui8@hotmail.com

Ask the last question and paste it immediately.

In DLL, procedure initimage (aparent: twincontrol; afilename: string );
If I change twincontrol to hwnd, for example
Procedure initimage (aparent: hwnd; afilename: string );
How should we implement the same function?
(Caller is also hwnd)

Haha, old Feng is here

Pass

Function findcontrol (handle: hwnd): twincontrol;

No problem.

Note that function findcontrol (handle: hwnd): twincontrol needs to be corrected. Otherwise ......

After aiirii left, zswang (with water clear) (expert outpatient cleaners) became the first cattle in the D version, can you help solve the http://community.csdn.net/Expert/topic/5133/5133079.xml below? In temp =. 3957483?

To: laifeng:
How can I fix it?

Hahahahaha, after a few days, the sharks finally float.
I will paste the entire DLL again and pay attention to the _ findcontrol function in it.

Tmyimage = Class (timage)
Private
Protected
Public
Published
Property parentfont;
End;

VaR
Controlatom: Tatom;
Controlatomstring: string;
Rm_getobjectinstance: DWORD; // registered window message

Procedure _ initcontrols;
Begin
Controlatomstring: = format ('controlofs %. 8x %. 8x', [getmodulehandle (NiL), getcurrentthreadid]);
Controlatom: = globaladdatom (pchar (controlatomstring ));
Rm_getobjectinstance: = registerwindowmessage (pchar (controlatomstring ));
End;

Function _ findcontrol (handle: hwnd): twincontrol;
VaR
Owningprocess: DWORD;
Begin
Result: = nil;
If (handle <> 0) and
(Getwindowthreadprocessid (handle, owningprocess) <> 0) and
(Owningprocess = getcurrentprocessid) then
Begin
If globalfindatom (pchar (controlatomstring) = controlatom then
Result: = pointer (getprop (handle, makeintatom (controlatom )))
Else
Result: = pointer (sendmessage (handle, rm_getobjectinstance, 0, 0 ));
End;
End;

Procedure initimage (aparent: hwnd; afilename: string );
VaR
Oselimg: tmyimage;
Begin
Oselimg: = tmyimage. Create (NiL );
Oselimg. autosize: = true;
Oselimg. Picture. loadfromfile (afilename );
Oselimg. parentfont: = false;
Oselimg. Parent: = _ findcontrol (aparent );
Oselimg. show;
End;

Exports
Initimage;

{$ R *. Res}

Begin
_ Initcontrols;
End.

I have learned why I want to correct the original findcontrol.

I don't know why,
However, it seems that you want to create a message for the DLL to get the current process ID and other information for pointer.

Thank you again!
Friend: topduan@hotmail.com

You're welcome. I have learned a lot through solving problems and technical exchanges. I learned a lot of skills and ideas that books cannot learn from excellent programmers like the Four-Star Cleaners.

There was another problem temporarily,
Why is pchar returned in DLL,
But what we get in the main program is sometimes garbled and sometimes normal:

DLL:
Getbyfield1 (...): pchar; stdcall;
Begin
S: = ado1.fields [0]. asstring;
Result: = pchar (s );


In the main program:
VaR TMP: pchar;

TMP: = getbyfield1 (-1, pchar ('type '));
Showmessage (TMP); // garbled characters are sometimes obtained here.

Why? Solution

Haha. Type is a reserved system word. You cannot directly use pchar ('type '). If you need this string, do the following:
VaR
STR: string;
TMP: pchar;
Begin
_ String: = 'type ';
TMP: = getbyfield1 (-1, pchar (STR ));
Showmessage (TMP );
......
End;

As to why, you can take a closer look at the detailed description of pointers and memory survival in the delphibasis tutorial (developed by Delphi College in the UK ).

Sorry, the above error is correct.

I changed type to another name, but still got garbled characters sometimes...

This may have to be explained by the Four-Star Cleaners.

4-Star Cleaners ~~~~

Mark!

(* Refer to the standard API write interface *)
Common API functions, such as getclassname () and getwindowtext ()...
VaR
Vbuffer: pchar;
Begin
Getmem (vbuffer, 256 );
Getclassname (handle, vbuffer, 256 );
Caption: = vbuffer;
Freememem (vbuffer, 256 );
End;
(* There is a principle in APP and DLL memory usage: who allocates resources and who releases them *)
You must allocate resources before calling them.
Why do system API functions do this? A pchar is not directly returned to you.
Because: Give You A pchar, who will release the memory resources of this pchar?
How does the system know when you have finished using it?

(* The memory management mechanism of string is very complicated *)
The string in Pascal is very easy to use, but behind it is a complicated memory management mechanism.
VaR
S: string;
Begin
S: = '000000 ';
// In fact, the compiler will release s memory space, ASM: Call @ lstrclr
End;

(* After the function is called, local variables will be released *)
I also want to get:
If thousands of function modules do not dynamically allocate memory resources to local variables
How much memory will be wasted

To put it simply:
> Getbyfield1 (...): pchar; stdcall;
> Begin
> S: = ado1.fields [0]. asstring;
> Result: = pchar (s );
If S is a local variable, the resource is released after getbyfield1 is called.

> In the main program:
> Var TMP: pchar;
> TMP: = getbyfield1 (-1, pchar ('type '));
> Showmessage (TMP); // garbled characters are sometimes obtained here.
TMP is actually a junk space that has been released from the resource. If it is reclaimed from other places for use, any content in this space may be available.

Finally, you can modify the interface by referring to the call method such as getclassname.

Now that the experts are here, let's ask:
How to enhance the stability of DLL calling programs?
Currently, the program called dll contains a form,
Sometimes a DLL error occurs, and the error is redirected to the main program, directly causing the main program to crash.CodeAll try... blocks T or finally does not help.
How should we solve similar problems ???

LZ's sexual desire is not high.

// LZ's sexual desire is not high.

Haha, lz is wholesale. More beneficial. Less money and more work, in line with national conditions.

LZ is really not generous.
However, I did not expect Lao Feng to be at a higher level than I imagined.
The hacker's programming logic is indeed highly worthy of being the first man in the D version ~~

No way. I am very poor. I have 5 points left in csdn.
Who needs it? Who can take it?

To: laifeng:
It's really big!
When the main program calls a DLL with a database component (without a form), it sometimes prompts an error "access violation at address 0000000. Read of address 0000000" and sometimes no.
Why can't I find the cause ????

Good guys do it to the end...

It doesn't matter. It's just a joke. Old saying "add sugar to coffee ".
"Access violation at address 0000000. Read of address 0000000"
This is an unexpected message about memory violations, for many reasons. But in general, it is caused by calling objects that are not instantiated.
If you destroy an instance and then call it. There are many reasons for this. It is really difficult to diagnose without looking at the code.

I just found the reason:
I used it in DLL
Ado. recordcount = 0
And
Ado. recno: = 1;
The program is executed here, and sometimes an error occurs !!! Why ?!!!

Here:
ADO: = TADODataSet. Create (NiL );

I am embarrassed to ask so many questions.
However, this is indeed a headache, and the answer is not found in the monopoly,
Thank you again for solving this problem.

Up
...
..