MySql and Delphi direct connection - mysql

I am looking into a free solution to connect delphi with a mysql database but without using ODBC.Is there such a component ?
Thanks.

You can use either:
TmySQL latest version released on 2002.
mysql.pas which works with recent Delphi version (D3 through DXE2) / MySQL version 3.23, 4.0, 4.1, 5.0, 5.1.

i have been looking and using for years many tools, free and paid.
1st free is weak or difficult, at least u need too much code to do simple tasks which can be done in one or two functions in paid tools.
Paid tools i have used Devart MyDAC and microOLAP for MySQL which are the top rated tools in this area.
i used mydac for around 2 years, but lately i moved to MicroOLAP DAC for MySQL as a better alternative for many reasons
microlap mydac is much smaller, much easier to maintain and install and to use, mydac is much bigger details and many of these details and properties give unclear errors when used in some wrong way. since microolap is smaller, it is almost error free, and easier to use.
mydac has a unicode issue in TmyDump vcl component, which repeatly appear and fixed in next update and reappear in the next one, fixed in the next and so on. this bug creats a nonunicode backup file containing unicode data, which when restore with the fixed version will cause wrong unicode conversion and damage of data, MicroOLAP tool has no issue with that with its similar component and smaller amount of details.
i believe simplicity is much better than complications, easier, and much bug free. that is main reasons for me to convert to DAC for MySQL from MicroOLAP.
that is my simple experiement with this important basic subject for any serious database busniness developer.
i tried also the new FireDAC, i highly discourage to use it, too much complications, difficult unicode handling, difficult to deploy.
Have luck.

You can use dbExpress. The only thing you will need is libmysql.dll from 5.1.X server.

I have been using MyDac since years, which is one of best DAC components for Delphi.
AFAIK it's the only native component that offer Direct Connection to MySql (No ODBC, No OLEDB, No libmysql.dll).

This is what I use in Delphi XE4 (works in previous versions too). It creates components during runtime. Note: if you want to create databases, the default MySQL database 'mysql' needs to be used. Make sure you check if you have access to it, put try..except..end; in your code. And yes, it requires having dbxmys.dll and libmysql.dll in the same folder as your *.exe. This video might give you some hints http://www.youtube.com/watch?v=6mRGAB4LsEE
unit MainUnit;
interface
uses
System.SysUtils, System.Types, System.UITypes, System.Rtti, System.Classes,
System.Variants, FMX.Types, FMX.Controls, FMX.Forms,
FMX.StdCtrls, Data.DBXMySQL, FMX.Edit, Data.DB, Data.SqlExpr, FMX.Dialogs, Windows,
Data.FMTBcd, FMX.Layouts, FMX.Memo, FMX.ListBox, FMX.ListView.Types,
FMX.ListView;
type
TForm3 = class(TForm)
Button1: TButton;
Label1: TLabel;
Edit1: TEdit;
Memo1: TMemo;
ListBox1: TListBox;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
MySQLConnection: TSQLConnection;
MySQLQuery: TSQLQuery;
Function ConnectToMySQLDatabase(szHostName, szUserName, szPassword, szDatabaseName: String): boolean;
end;
var
Form3: TForm3;
implementation
{$R *.fmx}
procedure TForm3.Button1Click(Sender: TObject);
begin
if ConnectToMySQLDatabase('localhost', 'root', 'passw_ord', 'table_name') = False then
Caption := 'Not Connected'
else
begin
Caption := 'Connected';
try
MySQLQuery.SQL.Clear;
{MySQLQuery.SQL.Add('insert into table_name(vardas_pavarde, asmens_kodas, kodas, pazym_nr, registravimo_data, '+
'data_nuo_kada_taikomas, isregistravimo_data, negalioja_nuo, paskelbimas_negaliojanciu, priezastis, pastabos) '+
'values ("Edijs Test", "3001000", "38", "PazPK122", "2013.05.03", "2013.06.01", NULL, NULL, NULL, "Tuščia", '+
'"ąčęėįšįųūž");');}
MySQLQuery.SQL.Add('select * from table_name where vardas_pavarde="edIJS tEst";');
MySQLQuery.Open;
Memo1.Lines.Add(VarToSTr(MySQLQuery['vardas_pavarde']));
Memo1.Lines.Add(VarToSTr(MySQLQuery['asmens_kodas']));
Memo1.Lines.Add(VarToSTr(MySQLQuery['pastabos']));
MySQLQuery.Close;
except
on E: Exception do
MessageBox(0, PWideChar(E.Message), 'Error', MB_ICONERROR);
end;
end;
end;
Function TForm3.ConnectToMySQLDatabase(szHostName, szUserName, szPassword, szDatabaseName: String): boolean;
begin
MySQLConnection := FindComponent('MySQLConnection') as TSQLConnection;
if not Assigned(MySQLConnection) then
MySQLConnection := TSQLConnection.Create(Self);
MySQLConnection.DriverName := 'MySQL';
MySQLConnection.GetDriverFunc := 'getSQLDriverMYSQL';
MySQLConnection.LibraryName := 'dbxmys.dll';
MySQLConnection.VendorLib := 'LIBMYSQL.dll';
MySQLConnection.Params.Values['HostName'] := szHostName;
MySQLConnection.Params.Values['Database'] := szDatabaseName;
MySQLConnection.Params.Values['User_Name'] := szUserName;
MySQLConnection.Params.Values['Password'] := szPassword;
MySQLConnection.Params.Values['ServerCharSet'] := 'utf8';
MySQLConnection.LoginPrompt := False;
try
MySQLConnection.Connected := True;
MySQLQuery := FindComponent('MySQLQuery') as TSQLQuery;
if not Assigned(MySQLQuery) then
MySQLQuery := TSQLQuery.Create(Self);
MySQLQuery.SQLConnection := MySQLConnection;
Result := True;
except
on E: Exception do
begina
MessageBox(0, PWideChar(E.Message), 'Error', MB_ICONERROR);
Result := False;
end;
end;
end;
end.

Use DB Express with MySQL 5.x in Delphi 7
See this link
http://www.justsoftwaresolutions.co.uk/delphi/dbexpress_and_mysql_5.html

Related

Throw Exceptions in CODESYS

How can I throw standard system exceptions (and if possible, create custom exceptions and throw them too).
The simplest thing that comes to mind, is to just divide a variable by zero, but that's just a hack at best.
I did find mentions of a function AppGenerateException in the CmpApp library, but I can't find any documentation for it, nor any examples. Can anybody point me to some documentation for this?
Out of curiosity I checked the AppGenerateException and got it working. Got some help from this Codesys help page.
I still think this is not the best way to achieve what you need, but it could work.
Unfortunately, I have 64 bit system and the TRY..CATCH is not yet working in other that 32 bit systems as far as I know, so I couldn't test catching.
Add the following libraries:
CmpApp
SysExcept
Then the following code seems to work. Set ThrowErr to true to get the system exception.
PROGRAM PRG_TestThrow
VAR CONSTANT
MY_PRIVATE_EXCEPTION : DWORD := 32001;
END_VAR
VAR
ThrowErr : BOOL; //Set this to TRUE to throw an error
//The next two are for getting App instance
_pApp : POINTER TO CmpApp.APPLICATION;
_Result : SysExcept.SysTypes.RTS_IEC_RESULT;
END_VAR
//Get App instance
_pApp := AppGetCurrent(pResult := ADR(_Result));
IF ThrowErr THEN
ThrowErr := FALSE;
IF _pApp <> 0 THEN
//Throw divide by zero exception
AppGenerateException(pApp:=_pApp, ulException:=RtsExceptions.RTSEXCPT_DIVIDEBYZERO);
//You could use probably any available number as your own custom exception.
//For example the following works BUT not sure if it's ok to this.
//AppGenerateException(pApp:=_pApp, ulException:=MY_PRIVATE_EXCEPTION);
//See RtsExceptions type for available exception codes.
//For my Codesys version, it has largest exception number of 0x2000 so all larger number are free (for now...)
END_IF
END_IF
It seems that it's possibly to use any custom exception code like:
AppGenerateException(pApp:=_pApp, ulException:=MY_PRIVATE_EXCEPTION);
But it's not documented so I would be careful.

Pascal (Script) and exception control flow

I'm working with a PascalScript innosetup installer, and I fail to see where the control of the following block is flowing.
function Foo(): String;
begin
Result := 'foo';
RaiseException('...');
end;
procedure Test();
var
Z : String;
begin
Z := '';
try
Z := Foo();
except
Log(Z);
end
end;
My installer seems to indicate Z is being set with the Result of the Foo function. My understanding of exceptions in 'most' programming languages tells me the assignment Z := Foo() should not happen in case of exception.
When the Foo function raises, should Z still be assigned to?
Probably it handles result values by reference as implicit first argument. But then this can happen. It could be considered a legal of certain codegeneration/optimization, since it is quite a common way of handling return values.
However what is exactly defined in Object Pascal outside testing what Delphi does is murky territory, since there is only a x86 and x86_64 implementation. And Delphi will return the value in eax, so if you follow that logic this is illegal.
added later:
I tested Delphi with structured types, and while it passes a reference, it creates a copy on the stack to pass it.
This could make it hard to optimize code with structured types though, but a modifier/attribute to declare the return type const could fix that if ever needed.
In Delphi, strings as result values are treated like var parameters. In other words, a function like Foo is in fact compiled as:
procedure Foo(var Result: string);
begin
Result := 'Foo';
RaiseException(...);
end;
This means that Z (through the reference parameter) is assigned the value 'Foo' immediately, i.e. before the exception is raised.
In other words, the function result is not just kept in a local variable called Result and then returned when the function ends -- which would be prevented by the exception -- it is assigned immediately.
I assume this is exactly what happens in PascalScript as well.

Why do i need at least two sockets to handle http connections?

I found description of simple web server at free pascal documentation.
Example code uses two sockets: listenerSocket and connectionSocket. Why? I thought it should be enough one.
ListenerSocket := TTCPBlockSocket.Create;
ConnectionSocket := TTCPBlockSocket.Create;
ListenerSocket.CreateSocket;
ListenerSocket.setLinger(true,10);
ListenerSocket.bind('0.0.0.0','1500');
ListenerSocket.listen;
repeat
if ListenerSocket.canread(1000) then
begin
ConnectionSocket.Socket := ListenerSocket.accept;
AttendConnection(ConnectionSocket);
ConnectionSocket.CloseSocket;
end;
until false;
ListenerSocket.Free;
ConnectionSocket.Free;

Attaching to datasets previously created by another thread

this is a question similar to this one but with a different background.
Compiler: Delphi 2010, soon Delphi XE5.
I have built a nice application that manages data on a remote MySQL server through the ZEOS components.
Since the connection could fail and SQL be slow I have used the neat OmniThreadLibrary to create an SQL server watchdog and to offload a lot of "read only" tables loading to threads.
As of now I have three data modules manually created before the main form shows, each with their independent TZConnection and some TZReadOnlyQuery components linked to the same data module TZConnection. Each thread instantiates its related data module from within itself and then executes the queries.
The watchdog is working quite well, but I have some doubts about the second part, that is the "read only" tables thread. The queries work already but I have yet to use their results in the main application business code, where I have to insert and update data on other tables.
In my plans I get all these "read only" dataset read and loaded before the main application even connects to them (the whole inter-thread state machine is done already). In theory there should be no concurrency issue as the "read only" tables thread has finished its task and is now being idle.
But I don't know what happens if at this point I connect a control or another dataset / datasource / whatever from the main form to the idle-threaded data module.
Will I mess up because the main form TZSession is not the same of the threaded data module? Will I get rare & nasty access violations to be discovered ONLY after having delivered the application (of course!). Basically with what kind of confidence or precautions should I access a query component created in another thread, assuming only the main application does it and only for reading data? Is it even possible / healthy at all? Or am I missing some "best practices" way of doing it?
Thanks in advance.
I am going to post how I have done it. It'll be "terse" (it's still a monumental wall of text!) due to lack of time, if you find something being too obscure feel free to ask. I don't pretend to have written neither the best nor the quickest nor the best formatted code. Just use it as your starting point.
Short recap of the problem domain: having a software that "pre-opens" tables at startup using a thread. This lets the software stay responsive and even perform other non database related startup tasks.
I have tested this program for 1 month now and the database components used are enough to prove it's not just a "toy demo" ready to break as you add your 3rd dataset.
Ingredients:
As stated above: Delphi 2010+ (I am now running this in RAD Studio XE5 Ultimate) but could probably work with earlier versions. I just did not test them.
ZEOS library, 7 and upwards should work including the latest 7.2 alpha.
OmniThreadLibrary
In my case I also used JVCL but that's only because I needed some specific data source events the basic components don't offer.
IDE, non code portion
create 2 data modules that will host the database components: one is for the "preload", threaded portion, the other for the "runtime", read write portion that will be basically the one used by the program users to perform their tasks.
create 1 unit where to store the thread worker code
create 1 or more form(s) that will constitute your application.
The two data modules would look like this:
Preload module, to be managed by the worker thread.
Portion of the main database module. It includes several additional datasets that the preload module cannot preload. Those are typically "dynamic" datasets whose queries are directly affected by interaction with the users.
The main database module's components started as copy and paste of the preload module so it does not take twice as long to prepare both.
Both the preload and the main database modules come with a ConnectToDatabase and DisconnectFromDatabase procedures that perform all the steps required to have the system up and running.
Very important!
The preload module performs the "true" queries in a separate thread and fills in their related TClientDataSets. Its components have no events attached. I only use them as blind "static" data containers.
The main database module will just "attach" to the preload module components.
In example: whereas the preload module cdsProducts ClientDataSet performs a "true database query" with the
cdsProduct => dspProduct => qryProduct
chain, the main database module cdsProduct just takes the preload module's cdsProduct data without performing any query at all (otherwise what'd be the point, performing queries twice?).
You see how counter-intuitively enough, the main database module cdsProduct comes with a linked TDataSetProvider and query components as well. Why? Because I use them to write modified data back.
That is, we have three program phases:
Startup, where the preload data module performs the queries (in a thread) and that's it. No events managed, all read only.
Running-start phase, where the main database module (in the VCL thread) copies the data gathered in 1 into its ClientDataSets.
Running phase, where the users interact with the main database module's ClientDataSets. When they need to save data (and only then), the main database module's DataSetProviders and queries are engaged. They only write.
I could have skipped the whole ClientDataSet => Provider => Query chain for some of those ClientDataSets but most of them require some huge data processing, must update many joined tables by hand and so on, so I just used the full stack.
Code portion
Lets get to some more nitty-gritty details. I can't post the whole stuff since it's a commercial application so I'll only paste some significant snippets.
Threaded, preload data module
procedure TModDBPreload.ConnectToDatabase;
begin
dbcEShop.Connect;
SendStatusMessage('Loading languages archive');
qryLanguage.Open;
qryLanguage.First;
SearchOptions := [loCaseInsensitive];
ModApplicationCommon.ApplicationLocaleInfo.Lock;
...
try
...
// All the queries parameters needing a language id need to be assigned to the locked LocaleInfo object
qryGeoZone.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
cdsGeoZones.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
...
finally
ModApplicationCommon.ApplicationLocaleInfo.Unlock;
end;
SendStatusMessage('Loading countries archive');
cdsGeoZones.Open;
cdsGeoZones.First;
SendStatusMessage('Loading currencies archive');
qryCurrency.Open;
qryCurrency.First;
Sleep(100);
SendStatusMessage('Loading products archive');
cdsProduct.Open;
cdsProduct.First;
...
end;
The above snippet could use a lot of explanations. In particular:
SendStatusMessage('Loading languages archive');
is a thread sending an end user friendly update string to be shown on a status line. Of course the status line is managed by the main VCL thread. How to do it? I'll show it later.
qryLanguage.Open;
qryLanguage.First;
...
cdsGeoZones.Open;
cdsGeoZones.First;
Not all the datasets need to be managed for the whole application duration. Only those that need are managed by ClientDataSets.
The "First" calls happen because I don't know if the server back end will change. Some database drivers, DLLs, (expecially) ODBC connectors etc. etc. don't perform the actual heavy lifting during Open but at the first cursor operation.
Therefore I make sure it happens, even if the current driver does not strictly need it.
The Sleep(100) is there to let the users and the developers see the messages when opening small tables. May be removed once the software is final, of course.
The Lock, try / finally clauses etc. are there to remind you that we are in a thread and some resources are best accessed with some precautions. In this specific case we have other threads (irrelevant for this article, thus not covered) so we have to protect some data structures.
In particular, I have "borrowed" the basic Delphi thread safe list locking mechanism paradygm so the method names are also the same.
OmniThreadLibrary based preload module thread worker
Here is the most relevant / didactic code:
type
TDBPreloadWorker = class(TOmniWorker)
protected
ThreadModDatabase : TModDBPreload;
FStatusString : string;
public
constructor Create;
function Initialize : boolean; override;
procedure Cleanup; override;
procedure SendStatusMessage(anID : Word; aValue : string = ''); overload;
procedure SendStatusMessage(aValue : string); overload;
procedure DisconnectFromDatabase;
procedure OMSendMessage(var msg: TOmniMessage); message MSG_SEND_MESSAGE;
procedure OMDisconnectFromDatabase(var msg: TOmniMessage); message MSG_DISCONNECT_FROM_DATABASE;
procedure OMUpdateStateMachine(var msg: TOmniMessage); message MSG_UPDATE_STATE_MACHINE;
end;
...
constructor TDBPreloadWorker.Create;
begin
Inherited;
FStatusString := 'Connecting to server...';
ThreadModDatabase := Nil;
end;
function TDBPreloadWorker.Initialize : boolean;
begin
ThreadModDatabase := TModDBPreload.Create(Nil);
ModDBPreload := ThreadModDatabase;
ThreadModDatabase.DBPreloadWorker := Self;
DisconnectFromDatabase; // In case of leftover Active := true from designing the software
Result := true;
end;
procedure TDBPreloadWorker.Cleanup;
begin
DisconnectFromDatabase;
ThreadModDatabase.Free;
ThreadModDatabase := Nil;
end;
procedure TDBPreloadWorker.SendStatusMessage(anID : Word; aValue : string);
begin
FStatusString := aValue; // Stored in case the main application polls a status update
Task.Comm.Send(anID, aValue);
end;
procedure TDBPreloadWorker.SendStatusMessage(aValue : string);
begin
SendStatusMessage(MSG_GENERAL_RESPONSE, aValue);
end;
procedure TDBPreloadWorker.DisconnectFromDatabase;
begin
if Assigned(ThreadModDatabase) then
ThreadModDatabase.DisconnectFromDatabase;
end;
procedure TDBPreloadWorker.OMSendMessage(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString);
end;
procedure TDBPreloadWorker.OMDisconnectFromDatabase(var msg: TOmniMessage);
begin
...
DisconnectFromDatabase;
end;
procedure TDBPreloadWorker.OMSendMessage(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString);
end;
procedure TDBPreloadWorker.OMUpdateStateMachine(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString); // Needed to show the pre-loaded status
if Assigned(ThreadModDatabase) then
begin
try
ThreadModDatabase.ConnectToDatabase;
SendStatusMessage('Reading database tables...');
if not ThreadModDatabase.QueryExecute then
begin
raise Exception.Create('Consistency check: the database does not return the expected values');
end;
SendStatusMessage(MSG_SUCCESS, 'Tables have been succesfully read');
SendStatusMessage(MSG_TASK_COMPLETED);
except
On E : Exception do
begin
DisconnectFromDatabase;
SendStatusMessage(MSG_TASK_FAILURE, E.Message);
end;
end;
end;
end;
Some code deserves further explanations:
function TDBPreloadWorker.Initialize : boolean;
creates the preload data module. That is, everything is self contained in the thread's context and does not clash with others.
procedure TDBPreloadWorker.SendStatusMessage(anID : Word; aValue : string);
this is how to send a message (by the way, it's not limited to strings) to the main VCL thread by means of the OmniThreadLibrary.
procedure TDBPreloadWorker.OMUpdateStateMachine(var msg: TOmniMessage);
this is the main preload data module initialization management code. It performs handshaking with the VCL main thread and basically plays as one of the state machines I have implemented in the program.
For those wondering where all those constants come from: they are declared in a separate file included by all the threads related classes. They are simple, free to choose integers:
const
MSG_GENERAL_RESPONSE = 0;
MSG_SEND_MESSAGE = 1;
MSG_SHUTDOWN = 2;
MSG_SUCCESS = $20;
MSG_ABORT = $30;
MSG_RETRY = $31;
MSG_TASK_COMPLETED = $40;
MSG_FAILURE = $8020;
MSG_ABORTED = $8030;
MSG_TASK_FAILURE = $8040;
MSG_UPDATE_STATE_MACHINE = 9;
MSG_TIMER_1 = 10;
MSG_DISCONNECT_FROM_DATABASE = 99;
Main form side preload management code
The various threads are spawned at program start. A TOmniEventMonitor has its OnTaskMessage event pointing to:
procedure TFrmMain.monDBPreloadTaskMessage(const task: IOmniTaskControl;
const msg: TOmniMessage);
var
MessageString : string;
ComponentsNewState : boolean;
begin
MessageString := msg.MsgData.AsString;
if Length(MessageString) > 0 then
UpdateStatusBar(MessageString);
if task = FDBPreloadWorkerControl then
begin
if (msg.MsgID = MSG_TASK_COMPLETED) or (msg.MsgID = MSG_TASK_FAILURE) then
begin
ComponentsNewState := (msg.MsgID = MSG_TASK_COMPLETED);
// Unlike for the watchdog, the preload thread is not terminated
// The data is needed by the program till its end
// DBPreloadTerminate;
// Lets the main database queries be started
DBPreloadSuccess := (msg.MsgID = MSG_TASK_COMPLETED);
MainViewEnabled := ComponentsNewState;
if msg.MsgID = MSG_TASK_FAILURE then
begin
if MessageDlg('Unable to load the data tables from the database server', mtError, [mbRetry, mbAbort], 0) = mrAbort then
Close
else
// Reinitialize the preload thread.
...
end;
end;
end;
end;
This is the totally simple procedure that in the end gets called in order to update the main form's status bar:
procedure TFrmMain.UpdateStatusBar(Value : string);
begin
pnlStatusBar.SimpleText := Value;
pnlStatusBar.Update;
Application.ProcessMessages;
end;
Main database module management code
Last but not least, here is how to actually "attach" to the preload data module ClientDataSets. Call this code from the main form and the foundations of your application are basically done!
procedure TModDatabase.ConnectToDatabase;
procedure ConnectDataSet(CDS : TClientDataSet; PreloadDataSet : TClientDataSet; RuntimeDataSet : TZAbstractRODataset; SetLanguage : boolean = false);
begin
// Only required by datasets needing a locale_id parameter
if (SetLanguage) then
begin
CDS.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
RuntimeDataSet.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
end;
CDS.Data := PreloadDataSet.Data;
CDS.Active := true;
end;
begin
DisconnectFromDatabase;
dbcEShop.Connect;
UpdateStatusBar('Setting up products archive');
ConnectDataSet(cdsProduct, ModDBPreload.cdsProduct, qryProduct, true);
UpdateStatusBar('Setting up products options archive');
ConnectDataSet(cdsProductOption, ModDBPreload.cdsProductOption, qryProductOption);
UpdateStatusBar('Setting up options archive');
ConnectDataSet(cdsOption, ModDBPreload.cdsOption, qryOption);
UpdateStatusBar('Setting up options descriptions archive');
ConnectDataSet(cdsOptionDescription, ModDBPreload.cdsOptionDescription, qryOptionDescription, true);
...
I hope to have posted enough information to give out an idea about the whole process. Please feel free to ask any questions and sorry for the lexicon, English is my fourth language.

Lazarus (Free Pascal). Seemingly unnecessary compiler warning

I'm new to Free Pascal and Lazarus. I'm testing out the new "advanced records" feature and getting what looks to be an unnecessary compiler warning.
The code is very simple, just a record with a single method to initialize the data fields. Something like:
{$mode delphi}
type TTest =
record
a,b: double;
procedure Init(x,y: double);
end
procedure TTest.Init(x,y: double);
begin
test.a := x;
test.b := y;
end;
var t: TTest;
begin
t.Init(0.1,0.2);
That last line shown, "t.Init()", always generates a compiler warning that 'variable "t" does not seem to have been initialized'.
Ok it's only warning, so obviously I can live with it, but I just want to make sure it's not due to some underlying misunderstanding on my part.
EDIT to add new information.
Re the Method verus Constructor point.
Looking into this some more I'm kind of glad that FPC doesn't allow constructors for records. Delphi has constructors but no destructors, and as far as I can tell constructors (for records) do absolutely nothing that a method couldn't do. I'm a minimalist, so to me there is no point to have extra syntax that does nothing more than some existing syntax does.
Particularly for a simple record like this, the very act of declaring it (var t: TTest) does all the "constructing" that this record needs. Anything else (like my Init) is just setting values, it's not constructing anything anyway. So as far as I can see constructors are not the answer, the compiler just needs to drop the warning.
Researching the issue I have come across one other technique that is often used, the so called "factory function". That is, a function outside of the record such as:
function InitTTest(x,y: double): TTest;
begin
Result.a := x;
Result.b := y;
end;
This technique does indeed work, and gets rid of the warning message. I don't like this method however and I wont use it. Advanced records don't have inheritance and other features of classes, encapsulation is all they've got going for them. So I really dislike having to make a "factory function" outside of the record like this.
Please bear in mind the the above is just the opinion of a "noob", after doing just a little research to answer my own question here. So if I'm wrong about anything above I'm quite happy to be corrected. :)
Yes, that is what constructors are for, the following compiles with FPC trunk and produces no warnings:
{$mode delphi}
type TTest =
record
a,b: double;
constructor Init(x,y: double);
end;
constructor TTest.Init(x,y: double);
begin
a := x;
b := y;
end;
var t: TTest;
begin
t.Init(0.1,0.2);
end.