Master/Detail filtration does not work if DisableControls is used?

[tatamata]

CodeTyphon 5.70 (FPC 3.1.1., CPU X86_64; OS: Win64)

I have just found that master/detail filtration between SQLQuery datasets does not work if DisableControls is used.
If EnableControls is set again, then master/detail filtration works OK again as well.

Is this a feature or a bug? Is it supposed to work this way?

[taazz]

Yes this is the proper behavior, think of it as, no event propagation while processing, the same way that a beginupdate/endupdate pair would work.

[tatamata]

Thanks, taaz for answer.
Though I don't think it is good nor logical not intuitive, it is important to know how DisableControls work.
In my opinion it should not have anything to do with master/detail filtration, but only with dbaware controls painting/refreshing on forms.

[taazz]

Thanks, taaz for answer.
Though I don't think it is good nor logical not intuitive, it is important to know how DisableControls work.
In my opinion it should not have anything to do with master/detail filtration, but only with dbaware controls painting/refreshing on forms.

disablecontrols stops the control from informing the attached controls for changes. It does not know nor should care of the attached control's reasons. The idea is to minimize the external influences in order to speed up processing a master detail link should only be a visual thing. Then again I haven't done any loop processing in my database application for ages I usually write some sort of Stored procedure or complicated (some over comlicated) SQL update to do what ever I need, I might be out of touch and you might have a good reason for an exception on the rule. How about changing your code to manually inform the detail  that the master has changed?

[tatamata]

What you say would be OK if both master and slave dataset would automatically be unfiltered when DisableControls is used.
But, what I saw is a nasty thing that the detail dataset remains filtered(!), it just does not accomodate when you iterate through master dataset.
This is quite inconsistent, I think.
Maybe applying Refresh to slave dataset would change this, but I didn't try, it was easier for me not to use DisableControls at all Flickering is less problematic than loosing control over master/detail filtration when I iterate through 4 levels master/detail datasets, I think.
However, I think this is incosistent behavior which can introduce unexpected bugs in a software. I'm convinced that most newbies would not think that DisableControls would destroy master/detail relationship of datasets.
Maybe I'm wrong, but for me when you say "Control" I automatically consider something visual, not non-visual stuff (such as DataSource or Dataset)...
On other hand, if this is expected behavior, than the dataset should be automatically unfiltered when DisableControls is applied.

[balazsszekely]

@tatamata
I see you're under windows. If you want to prevent flickering use the LockWindowUpdate api. It worked very well for me in the past. You should give it a try:

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

1.   LockWindowUpdate(Form1.Handle); //Panel1.Handle, DBGrid1.Handle, ...
2.   try
3.  
4.   finally
5.     LockWindowUpdate(0);
6.   end
7.  

[taazz]

What you say would be OK if both master and slave dataset would automatically be unfiltered when DisableControls is used.
But, what I saw is a nasty thing that the detail dataset remains filtered(!), it just does not accomodate when you iterate through master dataset.
This is quite inconsistent, I think.

No its the other way around, if it become unfiltered ee the detail dataset's state changes, then disablecontrols has failed to do its job and forced an update instead of stopping them not to mentioned that if the detail table has a couple of billion of records that will kill any benefits from calling it

Maybe applying Refresh to slave dataset would change this, but I didn't try, it was easier for me not to use DisableControls at all Flickering is less problematic than loosing control over master/detail filtration when I iterate through 4 levels master/detail datasets, I think.
However, I think this is incosistent behavior which can introduce unexpected bugs in a software. I'm convinced that most newbies would not think that DisableControls would destroy master/detail relationship of datasets.

No it can't introduce any bugs, you might introduce them though if you fail to test your assumptions. I do not think that flickering was part of specifications although it does solve that problem beautifully as well.

Maybe I'm wrong, but for me when you say "Control" I automatically consider something visual, not non-visual stuff (such as DataSource or Dataset)...
On other hand, if this is expected behavior, than the dataset should be automatically unfiltered when DisableControls is applied.

Depends on the context usually controls and objects are synonyms, the only one that makes a distinction between them, as far as I know, is the object pascal hierarchy which has Tcomponents to be everything design aware and TControls being able to draw on the screen as well. So yes in some cases Controls are visual while components are not and it might become a second nature after a while true, would make it easier if I would refer to them as components instead of controls? DisableControls naming can't be changed it will break delphi compatibility.