Possible bug on TDBEDIT on Mint - Error, SIGSEGV

[rvk]

2. After data displayed to users,  users click TDbEdit and start typing, this will fire up BeforeEdit event.

That was what I was asking. Your TDBEdit switches the Dataset to Edit.

BTW. I would use Datasource.OnStateChange for checking if you can edit the record. Not Dataset.BeforeEdit.

The upside of Datasource.OnStateChange is that you can also catch insert etc.

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

1. procedure TDocument.srDocStateChange(Sender: TObject);
2. begin
3.     if (TDatasource(Sender).Dataset.State in [dsInsert, dsEdit]) then // ERROR? // you could also just use tbDoc.State instead of Sender
4.     begin
5. // etc..

Maybe that one doesn't crash in Mint.

[incendio]

2. After data displayed to users,  users click TDbEdit and start typing, this will fire up BeforeEdit event.

That was what I was asking. Your TDBEdit switches the Dataset to Edit.

BTW. I would use Datasource.OnStateChange for checking if you can edit the record. Not Dataset.BeforeEdit.

The upside of Datasource.OnStateChange is that you can also catch insert etc.

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

1. procedure TDocument.srDocStateChange(Sender: TObject);
2. begin
3.     if (TDatasource(Sender).Dataset.State in [dsInsert, dsEdit]) then // ERROR? // you could also just use tbDoc.State instead of Sender
4.     begin
5. // etc..

Maybe that one doesn't crash in Mint.

Good info, thanks,  will try it when in front of computer.

[rvk]

Good info, thanks,  will try it when in front of computer.

PS. The complete start of the code I have in my program is like this:

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

1. procedure TDocument.srDocStateChange(Sender: TObject);
2. begin
3.  
4.   if OnlyReadAllowed then
5.   begin
6.     if (tbDoc.State in [dsInsert, dsEdit]) then // ERROR?
7.     begin
8.       tbDoc.Cancel;
9.       if tbDoc.Transaction.InTransaction then
10.           tbDoc.Transaction.RollbackRetaining;
11.     end;
12.   end;
13.  
14.   //... some extra code for enabling save buttons etc.
15.  

This will prevent any component from switching the Datasource to dsEdit or dsInsert.
And works perfectly with all TDBEdits and TDBGrids.

[incendio]

Good info, thanks,  will try it when in front of computer.

PS. The complete start of the code I have in my program is like this:

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

1. procedure TDocument.srDocStateChange(Sender: TObject);
2. begin
3.  
4.   if OnlyReadAllowed then
5.   begin
6.     if (tbDoc.State in [dsInsert, dsEdit]) then // ERROR?
7.     begin
8.       tbDoc.Cancel;
9.       if tbDoc.Transaction.InTransaction then
10.           tbDoc.Transaction.RollbackRetaining;
11.     end;
12.   end;
13.  
14.   //... some extra code for enabling save buttons etc.
15.  

This will prevent any component from switching the Datasource to dsEdit or dsInsert.
And works perfectly with all TDBEdits and TDBGrids.

This solution kind of solved the problem in Linux Mint, it didn't crash, but raised another problem.

Cancel method seem didn't halt the application. After Cancel issued, execution of next codes continued and here is the problem. Sometimes, there is some condition must be meet before able to successfully execute next code.

For example, there are 3 Fields, Field A, B & C.
Field C will calculate Field B/Field A. If there is Cancel method issued on Field A, since execution will still continue, error will be raised.

This is different with Abort method. When Abort issued, code to calculate Field C won't be execute.

Of course, another checking codes could be added to check for certain condition, but because there are lots of events that will be affected by OnStageChange, application complexity grows.
 

[rvk]

Cancel method seem didn't halt the application. After Cancel issued, execution of next codes continued and here is the problem. Sometimes, there is some condition must be meet before able to successfully execute next code.

I'm not sure what exactly you are doing in code but that's just a code flow problem.
I've never had that problem.

If you don't want to check the state in a calculate event you could see if calling raise/abort in statechange after the cancel would help.

Otherwise you need to show some small example code which would reproduce your problem (preferably a complete small test project).

[incendio]

Cancel method seem didn't halt the application. After Cancel issued, execution of next codes continued and here is the problem. Sometimes, there is some condition must be meet before able to successfully execute next code.

I'm not sure what exactly you are doing in code but that's just a code flow problem.
I've never had that problem.

If you don't want to check the state in a calculate event you could see if calling raise/abort in statechange after the cancel would help.

Otherwise you need to show some small example code which would reproduce your problem (preferably a complete small test project).

OK, will try to create small project to demonstrate the problem.

[incendio]

I'm not sure what exactly you are doing in code but that's just a code flow problem.
I've never had that problem.

If you don't want to check the state in a calculate event you could see if calling raise/abort in statechange after the cancel would help.

Otherwise you need to show some small example code which would reproduce your problem (preferably a complete small test project).

Here is the sample project with Firebird database.

Thanks for your help, appreciated.

[rvk]

Here is the sample project with Firebird database.

I can have a look at it later this morning (it's night now).

But can you explain the exact problem again.
I don't see a calculated field, only you adding two values before an edit.

BTW. Have you tried an Abort after the showmessage in statechange?
(I would never work with Abort like this.
You need to anticipate the Post failing in a proper way
 and not rely on an exception to dictate code flow.)

[incendio]

Here is the sample project with Firebird database.

I can have a look at it later this morning (it's night now).

But can you explain the exact problem again.
I don't see a calculated field, only you adding two values before an edit.

BTW. Have you tried an Abort after the showmessage in statechange?
(I would never work with Abort like this.
You need to anticipate the Post failing in a proper way
 and not rely on an exception to dictate code flow.)

Take your time, no hurry.

The problem is on the Append method, this method will fire OnStateChange and NewRecord events.

On event OnStateChange, dataset was cancel, then process continued to NewRecord event, where the new value to field Id is assigned.

This NewRecord event raised an error : not in edit mode. This is understanable, since dataset is in dsbrowse state after Cancel method called.

Like I said before, Cancel method will not halt the next process, that is why NewRecord event still fire up. This is different with Abort. Abort stop next process.

Of course, I can add codes in NewRecord to add another checking, but since OnStateChange scope is large, it mean every procedures / functions that affected by OnStateChange must be evaluated again.

[rvk]

The problem is on the Append method, this method will fire OnStateChange and NewRecord events.

Yes, but that's easilly solved by putting an raise or Abort in OnStateChange.

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

1. TDataSource(Sender).DataSet.Cancel;
2. ShowMessage('Can not edit!');
3. Abort;

Do note that this code can also run into an exception which you need to handle.
.Post can also fail and it's better to show a proper message instead of an exception.

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

1.   if (Dt2.State = dsEdit) or (Dt2.State = dsInsert) then Dt2.Post();
2.   Edit1.Text:=(Dt2NUM1.AsInteger +Dt2NUM2.AsInteger).ToString();
3.   ShowMessage(Edit1.Text);
4.   Dt2.Append;

[incendio]

The problem is on the Append method, this method will fire OnStateChange and NewRecord events.

Yes, but that's easilly solved by putting an raise or Abort in OnStateChange.

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

1. TDataSource(Sender).DataSet.Cancel;
2. ShowMessage('Can not edit!');
3. Abort;

Do note that this code can also run into an exception which you need to handle.
.Post can also fail and it's better to show a proper message instead of an exception.

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

1.   if (Dt2.State = dsEdit) or (Dt2.State = dsInsert) then Dt2.Post();
2.   Edit1.Text:=(Dt2NUM1.AsInteger +Dt2NUM2.AsInteger).ToString();
3.   ShowMessage(Edit1.Text);
4.   Dt2.Append;

That's the real problem.
Abort on Linux Mint raised an error SIGSEGV.

On Windows Abort is OK & enough if it is put in BeforeEdit event, no need for Cancel.

On Mint, Lazarus ver I installed from Software Manager was ver 2.2.0, not the latest version.

Will try to install ver 3 on mint, probably the error is gone.

[rvk]

That's the real problem.
Abort on Linux Mint raised an error SIGSEGV.

Ok, did it also raise an SIGSEGV exception when you used it in OnStateChange?

(Because that's a different place from BeforeEdit and I thought it should/could work there)

[incendio]

That's the real problem.
Abort on Linux Mint raised an error SIGSEGV.

Ok, did it also raise an SIGSEGV exception when you used it in OnStateChange?

(Because that's a different place from BeforeEdit and I thought it should/could work there)

Don't know, already un-installed Lazarus 2.2.0, will try on ver 3.

[tonyw]

This is not going to be an IBX bug. TIBDataset is a subclass of TDataset (which is in the FCL) and, IBX gets involved only when TDataset.InternalEdit is called. This is called after the BeforeEdit handler runs.

An exception raised in TDataset.Edit flows back to whoever called it. This may be either your code or a Data Aware control (In the LCL) which is where you should look for any dodgy exception handling.

On the other hand. Sysutils.Abort() is a one liner:

 Raise EAbort.Create(SAbortError) at CodePointer(Get_Caller_addr(Get_Frame));

I'm just wondering if the Windows/Linux difference is in the call to CodePointer and is due to the debug level you have compiled at. E.g. if you have not compiled in any debugging info under Linux  then maybe this call will result in a segment fault.

I would replace your call to Abort with your own exception and see if you get the same result.

Also, looking at your code, if seems odd that you are looking at a record field when deciding whether to abort. Remember that IBX has a record cache which is separate for each TIBDataset instance. Setting a field in one TIBDataset instance does not necessarily result in the field value being propagated to all such instances whether in the same process or another process. Firebird transaction control is a much better way to co-ordinate multiple threads working on the same data but, even here, you have to call TDataset.Post to lock a record and update the database. TDataset.Edit is not enough.

I don't know much about Lazarus, all I have done is untick Generate debuging info in project option. Do you have any hints what parameters should be set in Linux?

My goal is, if column lck_by is not null, then cancel editing from users. Dataset.Cancel seem able to solved this, unfortunately, event BeforeEdit only triggered once, after a call to Dataset.Cancel, it won't call again, hence I use Abort with is fine in Windows.

How to use IBX's record cache to achieve my goal?

If you have unticked "Generate Debugging Info" in the project options then I am not surprised to see a call to Abort() fail with a segment fault. Suggest you replace with your own exception e.g.

raise Exception.Create("My abort message");

[incendio]

That's the real problem.
Abort on Linux Mint raised an error SIGSEGV.

Ok, did it also raise an SIGSEGV exception when you used it in OnStateChange?

(Because that's a different place from BeforeEdit and I thought it should/could work there)

Tried it on Lazarus Linux 2.2.6, same error : SIGSEGV