Freeing Objects during FomClose or FormDestroy

[1HuntnMan]

Question, do you need to free objects during FormClose or in FormDestroy? In another post I was receiving Access Violations/Database is lock error.

I'm having a bit of a issue with the JvDBLookupCombos in units during testing. When I run a test and the mainform appears.  The user launches the application, and the main form appears which is just an access form to all the forms such as Clients Mgt., I can close the form and then launch other forms such as Contacts, References, etc. and test. But when I go back to the Clients Mgt., the JvDBLookupCombo's are dead, don't respond.

Should I free these components during FormClose or during FormDestroy. I tried freeing all these components but the Compile hic-Up's at the last line in the .lpr file.

Or should I not free components, FormClose does all this automatically. Trying to figure out why the JvDBLookUp components die after you test in a form, close it and test another form then go back to the original form tested and all the JvDBLookupCombo's are locked...?

[Hartmut]

I don't know JvDBLookupCombo, so I can only give you a common answer.

If you free something, you should do it in Destroy and not in Close.

In Destroy of a Form, before the Form itself is freed, automatically all Components of this Form are freed, which have this Form as their Owner (recursively).

So you must only free all other Components which you had created before by yourself.

[1HuntnMan]

So, in my FormClose procedure I'm checking to make sure the user is still in Insert or Edit, if so I'm show a message to Save the current record in dsInsert or dsEdit, else Cancel.

Then I was attempting in the FormDestroy:
  FreeAndNil(keys);
  JvDBLukupCmboTypeCust.Free;
  JvDBLukupCmboRefType.Free;
  JvDBLukupCmboState.Free;
  JvDBLukupCmboCntry.Free;
  FrmClientsMgt.Free;

But, when compiling, Lazarus hiccups at the very end of the .lpr and doesn't compile.

So, do I even need the to do any of this?  Just do not worry with a FormDestroy and freeing these JvDBLookUpCombos, similar to the Lazarus provided TDBLookUpCombo?

[1HuntnMan]

Just to add, in the FormClose after checking the current edit/insert and saving or cancel, I then close the Qry's.

[dseligo]

So, in my FormClose procedure I'm checking to make sure the user is still in Insert or Edit, if so I'm show a message to Save the current record in dsInsert or dsEdit, else Cancel.

Then I was attempting in the FormDestroy:
  FreeAndNil(keys);
  JvDBLukupCmboTypeCust.Free;
  JvDBLukupCmboRefType.Free;
  JvDBLukupCmboState.Free;
  JvDBLukupCmboCntry.Free;
  FrmClientsMgt.Free;

But, when compiling, Lazarus hiccups at the very end of the .lpr and doesn't compile.

Does this hiccups produce any errors or do we have to guess?

Also, we don't know what 'keys', 'FrmClientsMgt', etc. are. So I suggest you make some test application where you show problems you have, and I'm sure someone will help. Otherwise, this is guessing game - we don't know what you do and why.

[egsuh]

Are JvDBLookUpComboss components? If then, what is owner of them?
I guess the owner is the form. In that case, you shouldn't free them yourself.

If they are components but created by yourself, like

   JvDBLookUpCombos := TJvDBLookUpCombos.create(nil);

Or if they are classes not components,

then you should free them yourself. If they are created in FormShow then they should be freed in FormClose, and if created in FormCreate then freed in FormDestroy.

Check these relationships first, and if still problem exists, check when  the dataset is created, closed, and destroyed.

[LeP]

I guess the owner is the form. In that case, you shouldn't free them yourself.
......
If they are created in FormShow then they should be freed in FormClose, and if created in FormCreate then freed in FormDestroy.

Logically, you're right, but any object can be instantiated and destroyed anywhere in the program, not necessarily according to what you said (Create->Destroy, Show->Close).
Furthermore, you can also destroy any object (class, control, or otherwise) belonging to "anyone" by paying attention to two things:
1) Verify that it's instantiated before destroying it;
2) After destroying it, set the instance variable to NIL.
It's not a good programming rule to destroy objects belonging to "others," but technically it's feasible.

Obviously, it all depends on the object's lifetime and visibility, as well as the application's logic.

When in doubt, explicitly NIL the variable that defines the object after destroying it.

Code: Pascal  [Select][+][-]

1. JvDBLukupCmboTypeCust.Free;
2. JvDBLukupCmboTypeCust := nil;
3. .....

[Hartmut]

So, in my FormClose procedure I'm checking to make sure the user is still in Insert or Edit, if so I'm show a message to Save the current record in dsInsert or dsEdit, else Cancel.

Then I was attempting in the FormDestroy:
  FreeAndNil(keys);
  JvDBLukupCmboTypeCust.Free;
  JvDBLukupCmboRefType.Free;
  JvDBLukupCmboState.Free;
  JvDBLukupCmboCntry.Free;
  FrmClientsMgt.Free;

But, when compiling, Lazarus hiccups at the very end of the .lpr and doesn't compile.

So, do I even need the to do any of this?  Just do not worry with a FormDestroy and freeing these JvDBLookUpCombos, similar to the Lazarus provided TDBLookUpCombo?

I don't understand what you are doing there, so I can only give you common answers.
Because you showed no code:
Did you pay attention that 'Destroy' always needs 'override'?
And do you call inside of your 'Destroy' the ancestors 'Destroy' via inherited?

[paweld]

Did you pay attention that 'Destroy' always needs 'override'?
And do you call inside of your 'Destroy' the ancestors 'Destroy' via inherited?

In this case it is not required because it is a form event.

@1HuntnMan: It all depends on how you create these components. If you specify the owner when creating them, they will be released automatically when the owner is released.

[Hartmut]

Did you pay attention that 'Destroy' always needs 'override'?
And do you call inside of your 'Destroy' the ancestors 'Destroy' via inherited?

In this case it is not required because it is a form event.

In this case we misunderstood.
I'm speaking of destructor 'Destroy' and not of Event 'OnDestroy'.

[CharlyTango]

my database connection lies either in a Datamodule or even an independant object which is created and destroyed independently from any form.
Such an object is created at startup before any form with database access exists and is destroyed after all forms with database access were destroyed.

Therefore no database lock problem exist because this one object handles all database connections. In my opinion different database capable forms seldom need an own database connection.

Per form created database connection may bother the memory management of a sql server or cause troubles on single user databases.

[1HuntnMan]

Okay, thanks all. Figured it out from all your advice.  Form owns these components such as JvDBLookUpCombo's, etc. So I was causing most of the problems by attempting to Free these components, no need as I learned, the Form closing takes care of this.  I changed to this:

Code: Pascal  [Select][+][-]

1. procedure TFrmAppmnts.FormClose(Sender: TObject; var CloseAction: TCloseAction);
2. begin
3.   if FClosing then Exit;
4.   FClosing:= True;
5.   with PMSDataModule.QryAppmts do
6.     begin
7.       if State in [dsEdit, dsInsert] then
8.         begin
9.           if MessageDlg('Changes pending, save current updates?', mtConfirmation,
10.            [mbYes, mbNo],0) = mrYes then
11.             SaveQueryChanges(PMSDataModule.QryAppmts, PMSDataModule.TransPMSDB)
12.           else
13.             Cancel;
14.         end;
15.     end;
16.     //=>Close count query (form-owned) safely...
17.     SafeClose(QryCountAppmts);
18.  
19.     // 4) Close QryAppmnts, not used in any forms except the DM and FrmAppmnts...
20.     SafeClose(PMSDataModule.QryAppmts);
21.  
22.     // 5) Close lookups because forms are independent of each other...
23.     PMSDataModule.CloseLookupTables;
24.     CloseAction:= caHide; //=> caFree?, caHide bcause not recreating forms...
25.     FClosing:= False;
26. end;
27.  
28. procedure TFrmAppmnts.FormDestroy(Sender: TObject);
29. begin
30.   FreeAndNil(keys);
31.   FrmAppmnts:= Nil;
32. end;
33.  

The SaveQueryChanges and SafeClose are just small procedures I put in a Utility unit that I can call when needed and pass the dataset. Everything is working, not Access errors on closing anymore but once in awhile, I get a StackOverflow, but not every time.  My thinking is I don't need to keep opening and closing datasets except the ones that are just used once.  But anyway, in the process, I moved all the datasets, etc. to the DataModule, only accessing from forms the tables, etc. from the DataModule that way everything is located database everything in one DataModule unit.  Getting there... thanks all

[1HuntnMan]

Also, another issue, would anyone be able to tell me why a unit can't see the datamodule when I have it defined in the 'uses' at the top of every unit that's database related.

Code: Pascal  [Select][+][-]

1. uses
2.   Classes, SysUtils, sqldb, SQLite3Conn, Db, Forms, Controls, Graphics, Dialogs,
3.   ExtCtrls, DBGrids, Buttons, StdCtrls, DBCtrls, JDBDateEdit, JvDBLookup,
4.   JvDBSearchEdit, LCLIntf, LR_Class, LR_DBSet, PMSDM, PMSUtils;
5.  

 

PMSDM= DataModule and PMSUtils= my unit with database procedure that are used over and over such as SaveQueryChanges(Q: TSQLQuery; Trans: TSQLTransaction), SaveClose(const DS: TDataSet), etc.

For example, if I click the StateProvince dropdown combo, clicking the DataSource can't see the DataModule. I can assign it via code, but I should see everything in the DataModule even for assigning the DataSource in DBEdit's

[Josh]

Just SomeNotes

Units depending on each other
Put them in the implementation section if they rely on each other.
Example:

Code: Pascal  [Select][+][-]

1. implementation
2. uses DataStuff, IOStuff;

OnCloseQuery event
Best place to ask the user to save data or confirm closing.
Example:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
2. begin
3.   CanClose := MessageDlg('Do you want to save your data?', mtConfirmation, [mbYes, mbNo], 0) = mrYes;
4. end;

Purpose
Lets you perform cleanup or cancel the program close if necessary.
Clean up units that manage your form, such as data modules.
Do not free objects owned by the form itself—FormClose will automatically free/destroy anything the form owns.

Note
OnClose will only run if CanClose = True.

[1HuntnMan]

Awesome, thanks Josh. Changing a lot of my closing in other units.