[SOLVED] Application crash when entering huge values in TDBEdit->TIntegerField

[eara]

When you think that you solved a problem, a new one arrises always...
well i tried to test my app, which seems to be in an almost good state (i thought so  ), and everything are starting to collapse (as they usuall do) ...
This time are the int fields in my db, where i tried to enter a huge value to see how the app reacts, and i got a crash instead of the expected exception.
In debugger i see that an exception is raised ... twice!  and don't know what the heck is happening...
I tried to make another test project where i see the same behaviour, so i believe (?)  is not my fault....
i tried also to make a bug report (http://bugs.freepascal.org/view.php?id=26081), and now i wait for responses

p.s. Lazarus 1.2/windows 7 32-bits/planet earth

[mangakissa]

what's a application without a database. bug2.rar isn't complete.

[eara]

what exactly do you mean with "complete"?
Bug2, is just a quick and small isolated example that shows the situation i faced.
It creates a table (in a db you choose) with an integer field and let you try to enter a huge integer in the TDBedit field, thats all... Do you need more?
then specify plz....
The problem from my point of view is that underyling components should give me a change to handle the situation by raising an exception that i can handle somehow, and not to terminate the appication without second change...

[mangakissa]

I've tested it and came with the same results.

[eara]

1.

what's a application without a database. bug2.rar isn't complete.

Sorry, you where right on this, my fault... i resend the example in a more "user friendly version"...

2.

I've tested it and came with the same results.

What do you mean?
a) You got a nice exception in both cases? If so plz, tell me version, etc... and how to get them
b) You got a nice exception when entering value with code, but in manual entry the application terminates (this is my situation)

[mangakissa]

Option b. I was killed the second time the message arrived.
I put a UpdateError event to check what's wrong and tried to abort.
But after manually put a large value into dbedit the application still terminated.

[eara]

So we are talking for the same problem, that is encouraging me that i am not the only one in this world with this problem (  )

[eara]

Since we see in debugger the error to be raised then is not i think problem of db components (i believe, but can not prove it), but something else which has to do with default error handing mayby ? Something is not properly initialized there...

[LacaK]

Can you reporoduce without LCL, only with simple "console" application ?
See template program in wiki.lazarus.freepascal.org/Database_bug_reporting

[eara]

I don't know how i can reproduce a TDBEdit entry without TDBEdit....

[eara]

  Finally (thanks to Luiz) we got a workaround solution till next version comes out.

On DbCtrls.pp, near line 1587 put a try-finally like the code below

Code: [Select]

procedure TFieldDataLink.UpdateData;
begin
  if not IsModified then
    exit;

  try
    if Assigned(FOnUpdateData) then
      FOnUpdateData(Self);
  finally
    IsModified := False;
  end;
end; 
and problem seems to vanish...

[mangakissa]

Put it in the trunk for future releases...

[LacaK]

I don't know how i can reproduce a TDBEdit entry without TDBEdit....

Intention is isolate source of problem. If it is only DB related or related to DB-controls.
If you can reproduce it without DB aware controls, then it is clear that problem is in fcl-db and has no relation to LCL (TDBEdit, TDatalink etc)

[eara]

Yes, i got it what you where trying to say... it's only i couldn't apply that in this case.
After 2 days of debugging i detected that problem was generated from a lost focus event handling (see the bug report),
but since i did not write all this stuff is very hard for me to spot what exactly shoulb be fixed.
Thank givings should go to Luiz who fixed it... and of course all you people