TImage size ved proportinal

har også selv bøvlet med dette problem... jeg løste det med the protected hack.

/FunteX! :-)

{Accessing Protected Data of Other Classes (or, the "Protected Hack")
You've seen that in Delphi, the private and protected data of a class is accessible to any functions or methods
that appear in the same unit as the class. For example, consider this class (part of the Protection example):
type}
  TTest = class
    protected
    ProtectedData: Integer;
  end;
  //Once you place this class in its own unit, you won't be able to access its protected portion from other units
  //directly. Accordingly, if you write the following code
var
  Obj: TTest;
  Obj.ProtectedData := 20; // won't compile
  //the compiler will issue an error message, "Undeclared identifier: 'ProtectedData.'" At this point, you might think
  //there is no way to access the protected data of a class defined in a different unit. However, there is a way.
  //Consider what happens if you create an apparently useless derived class, such as the following:

type
  TTestHack = class (TTest);
  //Now, if you make a direct cast of the object to the new class and access the protected data through it, this is
  //how the code will look:
var
Obj: TTest;
begin
Obj := TTest.Create;
TTestHack (Obj).ProtectedData := 20; // compiles!
{This code compiles and works properly, as you can see by running the Protection program. How is it possible for
this approach to work? Well, if you think about it, the TTestHack class automatically inherits the protected fields
of the TTest base class, and because the TTestHack class is in the same unit as the code that tries to access the
data in the inherited fields, the protected data is accessible. As you would expect, if you move the declaration of
the TTestHack class to a secondary unit, the program will no longer compile.
Now that I've shown you how to do this, I must warn you that violating the class-protection mechanism this way
is likely to cause errors in your program (from accessing data that you really shouldn't), and it runs counter to
good OOP technique. However, there are times when using this technique is the best solution, as you'll see by
looking at the VCL source code and the code of many Delphi components. Two examples that come to mind are
accessing the Text property of the TControl class and the Row and Col positions of the DBGrid control. These two
ideas are demonstrated by the TextProp and DBGridCol examples, respectively. (These examples are quite
advanced, so I suggest that only programmers with a good background in Delphi programming read them at this
point in the text—other readers might come back later.) Although the first example shows a reasonable example
of using the typecast cracker, the DBGrid example of Row and Col is a counterexample—it illustrates the risks of
accessing bits that the class writer chose not to expose. The row and column of a DBGrid do not mean the same
thing as they do in a DrawGrid or StringGrid (the base classes). First, DBGrid does not count the fixed cells as
actual cells (it distinguishes data cells from decoration), so your row and column indexes will have to be
adjusted by whatever decorations are currently in effect on the grid (and those can change on the fly). Second,}

/FunteX!

Ja det er sådan jeg gør det nu bortset fra at jeg ikke behøver at typecaste da jeg creater min Image at runtime. Men som nævnt var jeg bare nysgerrig efter om ikke værdierne gemte sig et eller andet sted dybt nede i TImage.

ok.  det bliver sikkert mit næste projekt - at udvidde TImage så man kan få fat i DestRect værdierne på en mere bekvem måde.

/FunteX! :-)

Nå de findes sikkert ikke, smider du et svar psycosoft.

kommer her :o)

prøv lige at tage et kig på denne komponent: http://graphics32.org/documentation/Docs/Units/GR32_Image/Classes/TImage32/_Body.htm :)