I have the following code which is working, but I don't understand it 100% (please see the comments from code):
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TMyRec=record
a:Integer;
b:String;
end;
TRecArray=array of TMyRec;
PRecArray = ^TRecArray;
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
v1:TRecArray;
procedure Test(a:PRecArray);
{ Public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
{ TForm1 }
procedure TForm1.FormCreate(Sender: TObject);
begin
SetLength(v1,3);
v1[0].b:='test1';//set the first value
Test(PRecArray(v1));//call method to change the value assigned before
end;
procedure TForm1.Test(a: PRecArray);
begin
ShowMessage(v1[0].b);//shows test1
try
a^[0].b:='test2' //this is raising an error...
except
end;
PRecArray(#a)^[0].b:='test3';//this is working...
ShowMessage(v1[0].b);//shows test3
end;
end.
I don't understand why 'a^[0].b:='test2' is raising an error.
Thank you!
Your 'Test' procedure expects a 'PRecArray', but you're passing a 'TRecArray' to it. Try calling it like
Test(#v1);//call method to change the value assigned before
Typecasting a 'TRecArray' to a 'PRecArray' will not make it a 'PRecArray'. (Note: your 'test3' will fail then of course.)
I see several things that are suspicious.
1
There is hardly ever a need to take a pointer to a dynamic array, as dynamic array variables are already pointers (well, references).
To pass such an array to a function or procedure, use var parameters:
procedure TForm1.Test(var a: TRecArray);
Now you don't have to use pointer syntax to access the array:
a[0].b := 'test2';
2
You call Test with:
Test(PRecArray(v1));
In your original, Test took a PRecArray, but you are not passing one (you are passing a TRecArray), so you should have done:
Test(#v1); // or Test(Addr(v1));
Applying my change above, where Test has a var parameter, simply use:
Test(v1);
3
Ok, this is probably not suspicous, but I'd like to plug my article Addressing Pointers, about pointers for Delphi programmers. It explains many of the issues you seem to have.
You could replace the
procedure TForm1.Test(a: TPointerArrayRec);
with
procedure TForm1.Test(var a: TArrayRec);
it's simpler and you don't have to use the deprecation dereference operator ^.
Related
I'm learning OOP and I have created a basic program so far. I have create my own clas:
Type
Zombie = class
private
fLife : Integer;
fAge : Integer;
fHeight: String;
public
Constructor Create(pLife, pAge : Integer; pHeight : String);
Procedure SetLife(pLife : Integer);
function GetLife : Integer;
Procedure ShowLife;
end;
The procedure ShowLife does exactly what it says:
procedure Zombie.ShowLife;
begin
ShowMessage(inttostr(fLife));
end;
I'm trying to call this procedure on a Form but it says undeclared identifier:
procedure Tform1.ShowLifebtnClick(Sender: TObject);
begin
Zombies_Unit.ShowLife;
end;
I have included the unit in the user of the Form. How can I use methods on another form
You need to create and free the object before/after you use it. The pattern is like this:
MyZombie := TZombie.Create(10, 20, 30);
try
MyZombie.ShowLife();
finally
MyZombie.Free();
end;
You have to create an instance of your class and call the method of that object like
MyZombie := Zombie.create(20,15);
MyZombie.ShowLife;
...
MyZombie.free;
Sending from mobile, cannot format code.
EDIT/SUPPLEMENT:
As my short answer seems to be suitable to tech bad habits (I am sorry for that) I want to add the following advices to the asker:
Please use Try/Finally constructs to avoid that objects are not removed in case of an error occuring between create() and free() like Zdravko Danev's answer points out. It also makes sense to use common naming conventions to make your code easier to understand (e.g. TZombie as class name).
You must pay attention in one thing: Your class is in the same file of your form? If the answer is no, you must declare the unit name on uses of your form file like:
unit MyUnit;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TMyForm = class(TForm)
private
{ Private declarations }
public
{ Public declarations }
end;
var
MyForm: TMyForm;
implementation
uses unitzombie; //The name unit where is your class
{$R *.dfm}
end.
After solving this little problem, you must create your object before calling this methods:
procedure Tform1.ShowLifebtnClick(Sender: TObject);
var
Zombi: Zombie;
begin
Zombi := Zombie.Create(5,10,15);
try
Zombi.ShowLife;
finally
Zombi.Free;
end;
end;
One of my coworkers show me a code written in Delphi-XE XE Version 15.0.3953.35171, which I believe it should raise an access violation. The code is bellow:
unit Unit3;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm3 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
function test:TstringList;
{ Public declarations }
end;
var
Form3: TForm3;
implementation
{$R *.dfm}
procedure TForm3.FormCreate(Sender: TObject);
var aStrList : TStringList;
begin
aStrList := TStringList.Create;
test;
FreeAndNil(aStrList);
end;
function TForm3.test: TstringList;
var i:Integer;
begin
for i:=0 to 1000 do
Result.Add('aaa');//AV?
end;
end.
Inspecting aStrList and Result has the following results:
aStrList: TStringList $12FEDC : $42138A
Result: TStringList $12FEC4 : $B01B90
I do not understand why it is working. Result.Add should raise an access violation
LE: It seems that is working only on Debug Build Configuration.
The Result variable in that function has not been initialized and could hold any value. Now, the implementation detail means that, in some combinations of compiler options, your code happens to run with Result referring to a valid object. But that's really just a coincidence of those implementation details.
If this were C++ then that function would exhibit undefined behaviour. Although that term does not have a formal meaning in Delphi, it can be helpful to use that term in a Delphi setting to mean the same thing as in the context of C++.
I would also make the point that even if Result did not refer to a valid string list object, your code would not be guaranteed to raise an access violation. It could be that Result points to a block of memory that just happens to look enough like a string list for that code to execute successfully.
If you do things properly, you can predict the behaviour of your program. If your code is flawed and induces undefined behaviour, then your program's behaviour becomes unpredictable. It may work. It may fail. Or that code may execute fine, but then lead to a failure later in the program's execution. And so on.
It is possible to have a parameter in a routine which can be in the same time either an type, either an string? I know I can accomplish this by overloading a routine, I ask if it possible to do it in another way.
Assume that I have this type - TTest = (t1,t2,t3). I want to have a routine which accepts a parameter of type TTest, but in the same time to be a String, so I can call it myproc(t1) or myproc('blabla')
You should use an overloaded function.
You already have the perfect solution to the problem and there is no need to look for a different way to do this. You could try with a single function that receives a Variant, but then that function will also receive anything which means that the following would also be legal:
myproc(0.5);
myproc(intf);
myproc(-666);
Using an overload allows you to maintain compile time type safety and there is absolutely no loss of generality in using an overload.
Even this can be easily accomplished with overloaded functions, considering it's a good exercise, based on David Hefferman's and Sertac Akyuz answers I made a small example to test both solutions. It is not perfect, it only shows both possibilities.
unit Unit4;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
ttest = (t1,t2);
TForm4 = class(TForm)
procedure FormCreate(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
function my(aVar:Variant):String;
function MyUntype(const aVar):String;
end;
var
Form4: TForm4;
implementation
{$R *.dfm}
{ TForm4 }
procedure TForm4.FormCreate(Sender: TObject);
var aTestTypeVar : ttest;
aString : String;
begin
my(t1);
my(t2);
my('ssss');
//with untyped params
aString := 'aaaa';
MyUntype(aString);
aTestTypeVar := t1;
aString := IntToStr(Ord(aTestTypeVar));
MyUntype(aString);//can not be a numeral due to delphi Help
end;
function TForm4.my(aVar: Variant): String;
begin
showmessage(VarToStr(aVar));//shows either the string, either position in type
end;
function TForm4.MyUntype(const aVar): String;
begin
//need to cast the parameter
try
ShowMessage(pchar(aVar))
except
showmessage(IntToStr(Ord(ttest(aVar))));
end;
end;
end.
Also I know that Variants are slow and must be used only needed.
i can't figure out the formatting rules here .. too many lines of code in my example to add 4 spaces to each line, so here is the link to the code i need help with
http://nitemsg.blogspot.com/2011/01/heres-unit-written-in-delphi-7-that-you.html
The problem I have is that I don't know enough about delphi to use this code with a form.
I am a drag and drop programmer only.
An example with a showmessage('friendly name =' + ... ) when a USB device is detected is what I need.
cheers,
If you are only familiar with drag-and-drop programming, and don't know much about objects or other units, then you need to get yourself familiarized with using objects other than auto-created forms and the components you drop in them.
The code at this link is an entire unit. You need to create a new Unit in your project (File > New > Unit). It will look something like this:
unit Unit1;
interface
implementation
end.
Now when you save the unit, the name of the unit will automatically change to the filename (without the extension) like this:
unit MahUSB;
interface
implementation
end.
In this example, you should use the same unit name as that source you're trying to use. Save the unit as 'MahUSB.pas', and should be in the same folder as the rest of your project (or elsewhere, just a suggestion). Copy/Paste all the code from that website and replace everything in this unit now.
Now in order to actually use this, you need to create an instance of this object. ONLY ONE INSTANCE (I say that just because by the looks of this, there's no need for more than one).
Very important: Seeing as you are not familiar with objects, let me quickly explain something. Objects need to be created in order to work. At the same time, anything that's created also needs to be free'd when you're done with it. In this case, we will create this object when your application starts, and free the object when your application closes.
Now on your MAIN FORM (not any other forms) you need to put an event handler for both OnCreate and OnDestroy. You also need to declare a variable to represent this object. In the declaration of your main form, add a variable 'USB' with the type of this object. Make sure that goes under the 'private' or 'public' section, either one is ok. Also make sure you declare the "MahUSB" unit at the top of your main unit in the uses clause.
Declaring the object in your main form:
type
TForm1 = class(TForm)
private
USB: TUsbClass;
public
end;
Creating/freeing object when your app starts/closes:
procedure TForm1.FormCreate(Sender: TObject);
begin
USB:= TUsbClass.Create;
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
if assigned(USB) then USB.Free;
end;
Now we're not done yet. Now we need to add the event handlers. Notice at the top of this unit you got, there are two types called TOnDevVolumeEvent and TOnUsbChangeEvent. These are event types. The parameters in the event handlers must be identical to the parameters declared in these types. So now in your main form, declare these event handler procedures...
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private
USB: TUsbClass;
procedure VolumeEvent(const bInserted : boolean; const sDrive : string);
procedure ChangeEvent(const bInserted : boolean;
const ADevType,ADriverName, AFriendlyName : string);
public
end;
Now just one more thing we have to do before this will work. The USB object needs to know what event handlers to use, therefore, we need to assign these procedures to the events. Upon your form's creation, we need to assign these events...
procedure TForm1.FormCreate(Sender: TObject);
begin
USB:= TUsbClass.Create;
USB.OnUsbChange:= Self.ChangeEvent;
USB.OnDevVolume:= Self.VolumeEvent;
end;
When all is said and done, your main form unit should look something like this:
unit uUSBTest;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, MahUSB;
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private
USB: TUsbClass;
procedure VolumeEvent(const bInserted : boolean; const sDrive : string);
procedure ChangeEvent(const bInserted : boolean;
const ADevType,ADriverName, AFriendlyName : string);
public
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.ChangeEvent(const bInserted: boolean; const ADevType,
ADriverName, AFriendlyName: string);
begin
ShowMessage('Change event for "'+AFriendlyName+'"');
end;
procedure TForm1.VolumeEvent(const bInserted: boolean;
const sDrive: string);
begin
ShowMessage('Volume event for "'+sDrive+'\"');
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
USB:= TUsbClass.Create;
USB.OnUsbChange:= Self.ChangeEvent;
USB.OnDevVolume:= Self.VolumeEvent;
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
if assigned(USB) then USB.Free;
end;
end.
And there you are! You will have these two event handler procedures where you can further handle either of those two events.
Let's say I have two forms in a delphi project, I want to be able to access form1's variables from form2. Is there anyone to declare, say a 'public' variable in form1 which can be read from all forms?
I have tried putting a variable in the public declaration
{ private declarations }
public
{ public declarations }
test: integer;
end;
and in form 2 i have
unit Unit2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, unit1;
type
{ TForm2 }
TForm2 = class(TForm)
procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
procedure FormCreate(Sender: TObject);
private
{ private declarations }
public
{ public declarations }
end;
var
Form2: TForm2;
implementation
{$R *.lfm}
{ TForm2 }
procedure TForm2.FormCreate(Sender: TObject);
begin
form1 //<---------- DOES NOT GET RECOGNIZED
end;
end.
I then put 'Unit1' into the uses section on Form2, but it seems I can't do that due to a circular reference. I'd like to refrain from using pointers if possible.
First, it's better to pretend that globals don't exist at all. If you start out programming with the crutch of global variables, you'll just avoid learning the very simple techniques that allow you to do without them. You're worrying about using pointers (which actually wouldn't help your problem at all), but not concerned about using globals which are actually more dangerous.
Globals are dangerous because:
They provide a link between the units that share them (a concept called tight coupling)
This link is hidden in the sense that it's not obvious the exact nature of the link without examining the detail of the code.
Your code will become littered with side effects, which is to say that when you do something in a method, other unexpected things happen as well. This increases the possibility and complexity of subtle bugs.
The cumulative effect of the above points is that even if you break a project down into 20 units, your brain still has to think about all 20 units at the same time - as if they were only1 unit. This defeats the purpose of breaking your project down into smaller manageable units in the first place.
You'll quickly find that even medium sized projects start becoming very difficult to maintain.
Circular References
Please take a look at my answer to a previous question for thoughts on dealing with circular references more generally.
In your case, you simply need to move Unit1 from the interface uses to the implementation uses.
var
Form2: TForm2;
implementation
uses
Unit1;
{$R *.lfm}
{ TForm2 }
procedure TForm2.FormCreate(Sender: TObject);
begin
Form1.test; //Is now accessible, but remember: it will cause a runtime error if Form1 hasn't been created or has already been destroyed.
end;
Sharing data without globals
You'll notice that technically you're still using globals; albeit ones created by Delphi and not your own. Here's a technique you can use to share data in a more controlled fashion.
unit Unit3;
interface
type
TSharedData = class(TObject)
public
Test1: Integer;
Test2: Integer;
end;
Then in Form1 you add the following:
implementation
uses
...
Unit3;
type
TForm1 = class(TForm)
...
public
SharedData: TSharedData;
end;
//Inside either the constructor or OnCreate event add the following line:
SharedData := TSharedData.Create;
//Inside either the destructor or OnDestroyevent add the following line:
SharedData.Free;
Then in Form2 you do something slightly different because you want to use Form1's shared data not its own "shared data".
implementation
uses
...
Unit3;
type
TForm2 = class(TForm)
...
public
Form1SharedData: TSharedData;
end;
//Nothing added to constructor/destructor or OnCreate/OnDestroy events
Finally, after creating both forms, you give Form2 a refernce to Form1's shared data:
procedure RunApplicationWithoutFormGlobals;
var
LForm1: TForm1;
LForm2: TForm2;
begin
Application.Initialize;
Application.MainFormOnTaskbar := True;
Application.CreateForm(TForm1, LForm1);
Application.CreateForm(TForm2, LForm2);
LForm2.Form1SharedData := LForm1.SharedData;
Application.Run;
end;
The above illustrates how easily you can do away with even Delphi's global variables.
Disclaimer: Some of the code goes agaisnt generally accepted encapsulation principles, but is for illustrative purposes only.
First, if you must use globals (it's probably better not to use globals, as Craig has wisely pointed out) then you should put the globals you want to share in SharedGlobals.pas:
unit SharedGlobals;
interface
var
{variables here}
Something:Integer;
implementation
{ nothing here?}
Now use that unit, from the two units you want to share access to that variable in. Alternatively, have both reference another object, which is named something sensible, and have that object be designed, as the holder of state (variable values) that those two instances (forms or classes, or whatever) need to share.
Second idea, since your two units that you have already have dependencies on each other, you could also get around your circular dependency by using the unit that would create a circular dependency, from the implementation section instead of the interface:
unit Unit2;
interface
/// stuff
implementation
uses Unit1;
...
unit Unit1;
interface
/// stuff
implementation
uses Unit2;
the example shows Form1(main) and Form2(other) which has better use for organization;
FORM1 interface declaration only;
can be read from all forms;
interface
procedure oncreate(Sender: TObject);
implementation
uses Form2;
procedure TForm1.oncreate(Sender: TObject);
begin
Form2.test1;
//{Form2.test2} are not visible to Form1;
end;
FORM2 interface and implementation declarations;
implementation declaration are local to the unit; cannot be read from all forms;
interface
procedure test1;
implementation
procedure test2; //declared under implementation;
procedure TForm2.test1;
begin
ShowMessage('form2 test1 message');
end;
procedure TForm2.test2;
begin
ShowMessage('form2 test2 message');
end;
any procedure, function, type, variable can be local to the unit under implementation;
it also makes intellisense(Ctrl+Space) clean from declarations used only to the unit;