1

In the unit below I have a variable declared in the IMPLEMENTATION section - local to the unit. I also have a procedure, declared in the TYPE section which takes an argument and assigns that argument to the local variable in question. Each instance of this TFrame gets passed a unique variable via passMeTheVar.

What I want it to do is for each instance of the frame to keep its own version of that variable, different from the others, and use that to define how it operates. What seems to be happening, however, is that all instances are using the same value, even if I explicitly pass each instance a different variable.

ie:

Unit FlexibleUnit;
interface
uses
//the uses stuff
type
TFlexibleUnit=class(TFrame)
   //declarations including
   procedure makeThisInstanceX(passMeTheVar:integer);
private
//
public
//
end;

implementation
uses //the uses
var myLocalVar;

procedure makeThisInstanceX(passMeTheVar:integer);
begin
myLocalVar:=passMeTheVar;
end;

//other procedures using myLocalVar 
//etc to the 
end;

Now somewhere in another Form I've dropped this Frame onto the Design pane, sometimes two of these frames on one Form, and have it declared in the proper places, etc. Each is unique in that :

ThisFlexibleUnit : TFlexibleUnit;
ThatFlexibleUnit : TFlexibleUnit;

and when I do a:

ThisFlexibleUnit.makeThisInstanceX(var1); //want to behave in way "var1"
ThatFlexibleUnit.makeThisInstanceX(var2); //want to behave in way "var2"

it seems that they both share the same variable "myLocalVar".

Am I doing this wrong, in principle? If this is the correct method then it's a matter of debugging what I have (which is too huge to post) but if this is not correct in principle then is there a way to do what I am suggesting?

EDIT:

Ok, so the lesson learned here is that the class definition is just that. Many classes can go in one unit and all instances of all classes in the Type section share the implementation section of the unit.

J...
  • 30,968
  • 6
  • 66
  • 143

3 Answers3

8

myLocalVar is a global variable, but only visible within the unit.

A local variable would be in a procedure/function, like

procedure makeThisInstanceX(passMeTheVar: integer);
var
  myLocalVar: Integer;
begin
  myLocalVar := passMeTheVar;
end;

if you want an instance variable, that is each frame has its own copy, put it in the class:

type
  TFlexibleUnit = class(TFrame)
     procedure makeThisInstanceX(passMeTheVar:integer);
  private
    myLocalVar: Integer;
  ...
  end;
jasonpenny
  • 2,999
  • 1
  • 24
  • 23
  • 1
    Justin, please note that *variables* declared at unit scope have absolutely no relation whatsoever to *classes* declared at unit scope. You might be confusing things with Java, where everything belongs to a class, and there's only one class per source file. In Delphi, neither of those things is true. – Rob Kennedy May 12 '10 at 20:36
  • 2
    Variables in the implementation section are local to the *unit* but global to all the code inside the unit. It has nothing to do with classes or instances, since Delphi isn't a "pure" object-oriented language. – Mason Wheeler May 12 '10 at 20:37
1

You are calling the makeThisInstanceX method as a class (static) method rather than creating an instance of the class and calling it as an object method. Take a look at this reference:

http://oreilly.com/catalog/delphi/chapter/ch02.html

David M
  • 71,481
  • 13
  • 158
  • 186
-2

frame / unit / class / control

I applaud your heroic attempt to better the code. However, judging by your questions and comments I regret to inform you that your understanding is very limited.

A frame is not a unit which is not a class. A frame is a class but not every class is a frame. A frame is a control but not every control is a frame. Units have interface and implementation (and initialization and finalization) sections. Classes have private and public (and protected and published) parts.

I did not put the last paragraph in to try to teach but to allow you to gauge your understanding level. A Delphi developer ought to have no problem with the paragraph. I'm not trying to make you feel bad or to show off - just trying to help. Perhaps Stack Overflow is not the right tool for you at this time.

As somebody just learning Delphi for the first time, I might be confused by some of the seemingly redundant features. But the product has a long history and each addition made sense at the time it was added. It was also easier to learn when you only had to learn it a piece at a time.

Pete R.
  • 27
  • 1
  • SO is the right place for everyone who's got a programming problem of any kind. I don't like to downvote, but I don't see how demotivating and sending the OP away from this site is helpful to anyone, sorry. – Wouter van Nifterick May 13 '10 at 04:06
  • 1
    -1 as it is not an answer, and for same reasons as upper. Just be cool ! – TridenT May 13 '10 at 08:40
  • 1
    I'm sorry that I came across as passive aggressive. I assure you that was not my intent. Since you could not hear my spoken voice let alone see my face and body language you had to evaluate my emotions solely from my written words. (Maybe I should have tried some emoticons.) I am, however, more convinced than ever that SO is a limited tool. It does allow information exchange, but, as the comments show, it doesn't always convey emotion correctly. – Pete R. May 23 '10 at 00:58