Jason,

J> There are some enhanced abilities of IBO this may not be ideal with. I'll
J> need to consider this carefully.

Yep, putting together enhanced abilities with expected compatibility
is always a source of headaches. Anyway, for a more correct "fix"
please see my other followup post.

The CanModify behaviour is very important for data-aware controls: if
CanModify is False then the DBNavigator disables some buttons, the
DBGrid doesn't try to insert when you scroll past the last record or
press the Insert key, etc. The bottom line is: CanModify should return
False in all the cases in which one or more of the following
operations would raise a client-generated exception: insert, edit,
delete. Hope this helps.

J> ----- Original Message -----
J> From: "Nando Dessena" <nandod@...>
J> To: <IBObjects@yahoogroups.com>
J> Sent: Friday, January 16, 2004 3:05 AM
J> Subject: [IBO] Issue with TIBODataset.CanModify

>> Hello,
>> I have discovered yet another difference in behaviour between
>> TIBOQuery and good ol' TQuery (well, every query component that has a
>> RequestLive property, actually). If you set TQuery.RequestLive to false
>> then TQuery.CanModify always returns False. This has a number of
>> implications, i.e. the data-aware controls set themselves to a
>> read-only state and don't try modify operations on the dataset, which
>> would throw exceptions.
>>
>> Unfortunately TIBODataset.CanModify doesn't take RequestLive into
>> account. Here's the current (4.3Aa) code:
>>
>> function TIBODataset.GetCanModify: boolean;
>> begin
>> if Assigned( IB_Transaction ) and IB_Transaction.ReadOnly then
>> Result := false
>> else
>> begin
>> Result := InternalDataset.NeedToPost;
>> if not Result then
>> Result := not FReadOnly;
>> end;
>> {!!!
>> begin
>> CursorPosChanged;
>> UpdateCursorPos;
>> InternalDataset.RowNum := InternalDataset.BufferRowNum;
>> Result := InternalDataset.CanModify;
>> end;
>> }
>> end;
>>
>> And my proposed modification:
>>
>> function TIBODataset.GetCanModify: boolean;
>> begin
>> if not RequestLive then
>> Result := False
>> else if Assigned( IB_Transaction ) and IB_Transaction.ReadOnly then
>> Result := false
>> else
>> begin
>> Result := InternalDataset.NeedToPost;
>> if not Result then
>> Result := not FReadOnly;
>> end;
>> {!!!
>> begin
>> CursorPosChanged;
>> UpdateCursorPos;
>> InternalDataset.RowNum := InternalDataset.BufferRowNum;
>> Result := InternalDataset.CanModify;
>> end;
>> }
>> end;
>>
>> BTW I haven't got the foggiest idea why the call to
>> InternalDataset.NeedToPost is necessary or even relevant here. Would
>> very much like to find out.
>>
>> Does Jason or anyone else foresee any problems with this change? It is
>> not a light change compatibility-wise, as it has the potential to
>> expose logic bugs in applications, but IMHO it's the only right
>> behaviour (incidentally it makes my apps work as they did before ;-)).
>>
>> If everybody thinks it is OK then I ask this change (or equivalent,
>> interface-wise) be integrated in IBO's next subrelease.
>> Thanks
>> --
>> Nando mailto:nandod@...

Ciao
--
Nando mailto:nandod@...