QualityCentral

Public Report

Report From: Delphi-BCB/Database/Core VCL [ Add a report in this area ]

Report #: 4343

Status: Closed

Proposal of modification of the TDataSet.Post method in DB.pas unit

Project: Delphi

Build #: 6.240

Version: 6.0

Submitted By: Stefano Vecchiato

Report Type: Suggestion / Enhancement Request

Date Reported: 5/7/2003 11:14:38 PM

Severity: Commonly encountered problem

Last Updated: 3/20/2012 2:24:39 AM

Platform: All versions

Internal Tracking #: 216027

Resolution: Test Case Error (Resolution Comments)

Resolved in Build: : 10.0.2097.6343

Duplicate of: None

Voting and Rating

Overall Rating: (4 Total Ratings)

1.00 out of 5

Total Votes: None

Description

I have had a problem with a form that contains a DBGrid component.

The form is showed with a code such this:

try
  Form.ShowModal;
except
  ShowMessage('Error');
end;

In the form there is a DBGrid. When a new record is inserted or modified I verify some conditions in the BeforePost Event of the Dataset.
If I have to abort the post operation in the BeforePost event I can call the Abort procedure.
The abort procedure generate an exception that, sometimes, closes the form.
To solve this problem I suggest modifying the TDataSet.Post method in the DB.pas unit. If I raise an Exception with the 'DO NOT POST' message then it is intercepted in the modified Post method and the post operation is not executed.

procedure TDataSet.Post;
var                                                    {Mod}
  SkipOperation: boolean;                              {Mod}
begin
  SkipOperation:= false;
  UpdateRecord;
  case State of
    dsEdit, dsInsert:
      begin
        DataEvent(deCheckBrowseMode, 0);
        try                                            {Mod}
          DoBeforePost;
        except                                         {Mod}
          on E: Exception do                           {Mod}
            if E.Message = 'DO NOT POST'               {Mod}
            then                                       {Mod}
              SkipOperation:=true                      {Mod}
             else                                      {Mod}
               raise;                                  {Mod}
        end;                                           {Mod}
        if not SkipOperation                           {Mod}
        then                                           {Mod}
          begin                                        {Mod}
          CheckOperation(InternalPost, FOnPostError);
          FreeFieldBuffers;
          SetState(dsBrowse);
          Resync([]);
          DoAfterPost;
          end;                                         {Mod}
      end;
  end;
end;

Steps to Reproduce:

note from daniel: it's been like that since delphi 1, the form should be well designed. showmessage has its own message pump/handler, the example is artificial...

ps
qa: when you promote a bug to raid, PLEASE enter steps instead of fragments of source code, etc

Workarounds

None

Attachment

None

Comments

Robert Cerny at 5/8/2003 12:34:38 AM -

Most of users would hate such change since it could break existing code.

As it is, the caller knows when post operation was successfull, with your
proposal the caller would get no error, if E.Message = 'DO NOT POST', which
is IMO plain silly and would break a lot of existing code.

If you have a modal form that posts changes on button click that has
ModalResult other than none, it always closes the form regardless of
exceptions. That's your design problem, not a VCL problem.
You don't fix computer hardware problems with a hammer, so don't do it with
software. <g>
Here's a workaround for you:
1. set Button.ModalResult := mrNone
2. in ButtonClick() add ModalResult := mrOk {or whatever it was}:
procedure Txx.OkButtonClick(...);
begin
AQuery.Post;
ModalResult := mrOk;//only set modalresult, if it reaches this line
//if post raises exception, it never gets here, ModalResult remains mrNone,
so form isn't closed
end;

HTH

Stefano Vecchiato at 7/4/2003 4:08:14 AM -

I think that this change don't break existing code.
How can I skip a post operation in the BeforePost event without using the Abort exception?
With the change I suggested If I raise an Exception with a message 'DO NOT POST' it is handled in the Post method which skips the Post operation.
So I can raise this exception to skip a post operation in the BeforePost event.
If I don't raise an exception with a 'DO NOT POST' message all run as without the change.

Robert Cerny at 7/14/2003 11:24:24 AM -

The Abort procedure *never* closes the form.
Please read my first reply once again very carefully. You should notice the diagnosis and resolution for your problem.
It also explains why your suggestion would not solve your problem.

Stefano Vecchiato at 7/21/2003 4:26:16 AM -

I have the following code:
try
   ...
  Form1.ShowModal;
  ...
except
  ShowMessage('Error');
end;

In the form Form1 I have a DBGrid. With the DBGrid the user inserts rows in a table.
Before inserting a new row (BeforePost event) I verify that the row values are correct.
If a value is not correct I have to 'abort' the insert operation and I call the Abort procedure.
I have noticed that the abort procedure closes Form1 and the 'Error' message is shown.

I search an answer to this question:

How can I skip a post operation in the BeforePost event without using the Abort exception?

Robert Cerny at 7/21/2003 11:20:45 AM -

Ok, once again.
If the form is non-modal, it closes when you call close, hide or release methods
If the form is modal, it closes when something sets its ModalResult to <>mrNone or same as above.
If you have a button (with ModalResult<>mrNone), it sets ModalResult of form and *after* that it calls its click method. In click method you verify some data and execute Post method. Regardless of any exceptions the form will close, because the button already set the form's ModalResult.
Do you understand this?
So, your enhancement request would not help at all. Try and see.
Now read my first reply once again very carefully for a workaround.

Also, newsgroups is the proper place for such discussions, if QC becomes flooded with things that do not belong here, it will lose its purpose - the Borland team will have a lot harder time to filter out real bugs and suggestions that really need attention. I rared it 1 to help them here.

Developer Tools

Database Tools