I've edited the VCL, recompiled, and added some debugging tests in the
TDataSource.SetDataSet procedure, but that procedure is never fired as
the DataSet property goes to nil. This appears to happen between
compiling and linking. The property is not being lost in the
Notification procedure either, because I've checked for that also. I've
greped through my code, and nowhere do I set the DataSet property in
code, so it must be happening in code that I didn't write (though it's
still likely my error). My descendant DataSource doesn't contain any
code at all, except debugging to check for the Notification removal of
the DataSet. Any ideas? Is it something strange because I separated
the DataSource and DataSet on different owners? Is it a
FreeNotification issue? Is there anywhere else I could look for a
solution? Why would this only happen the first time I compile in a
Delphi session?
Maybe I'll just wait till Delphi 4 on this one, in hopes it is a
known/fixed Delphi problem.
Erik
I've seen it, and I don't know why it happens, but I did code the
parent-class of all my forms to explicitly check to see if the data
source pointer is gone. From time to time it pops up -- only with the
master datasets -- and it occurs even in design-time at the point when
you save the form. I do not know why it occurs and have had to program
tests for it. I have to go through each and every form before releasing
a new version of the application in question.
Are you using descendant TDataSource or TTable/TQuery classes? I'm
actually using a descendant of TDataSource, and a descendant of TwwTable
(from InfoPower). I've been unable to replicate the problem with the
standard Delphi components, or when my modified components are used with
the datasource and dataset on the same module. The problem does occur,
though, when the TMyDataSource is on the form, and the datamodule holds
the TMyTable.
> master datasets -- and it occurs even in design-time at the point when
> you save the form. I do not know why it occurs and have had to program
> tests for it. I have to go through each and every form before releasing
> a new version of the application in question.
What a mess. This project will likely end up with a few hundred
forms, and checking all of them manually for every product release will
be hell. I guess doing it in the descendant form would be better, but
I'd still have to show/view all the forms at runtime to look for the
error message. Of, I guess we could write some Perl routies to convert
all the DFMs to text and scan for datasources without DataSet properties
set. Does anyone else suspect this might be a Delphi/VCL bug? Maybe I
should try testing in other versions of Delphi and see what happens.
Erik
Yes ;-( This is Delphi 2/3 bug, the Standard "Data Access components have
the same problem. This happen when you open a form with TDataSource
components linked with a TDataSet in a DataModule that DON'T open in IDE,
then Delphi think that the link doesn't exists a lost the reference.
I hope in D4 the solution for this problem ...
Bye,
Jean Ferreira
Erik B. Berry wrote in message <358015...@sync-link.com.I.HEART.SPAM>...
>I'm having a longstanding problem with the DataSet property of a
>DataSource. I have created a descendant TTable and TDataSource.
>Sometimes, when compiling my project (it only happens the first time I
>compile in a
>Delphi 3.02 session) the DataSet property of the DataSource (which is on
>a form) goes blank. The DataSet for the DataSource is on an
>accompanying DataModule.
>
> I've edited the VCL, recompiled, and added some debugging tests in the
>TDataSource.SetDataSet procedure, but that procedure is never fired as
>the DataSet property goes to nil. This appears to happen between
>compiling and linking. The property is not being lost in the
>Notification procedure either, because I've checked for that also. I've
>greped through my code, and nowhere do I set the DataSet property in
>code, so it must be happening in code that I didn't write (though it's
>still likely my error). My descendant DataSource doesn't contain any
>code at all, except debugging to check for the Notification removal of
>the DataSet. Any ideas? Is it something strange because I separated
>the DataSource and DataSet on different owners? Is it a
>FreeNotification issue? Is there anywhere else I could look for a
>solution? Why would this only happen the first time I compile in a
>Delphi session?
>
> Maybe I'll just wait till Delphi 4 on this one, in hopes it is a
>known/fixed Delphi problem.
>
>Erik
You seem to state that this happens to you as you load the project
into the IDE. In my case, it happens the first time I compile (and only
the first time), not when I open the project. Could these be two
different/related issues? I lose the property right after the compiling
is done, and either before/during/right after the linking.
Erik
I think that I have found the source of this probable "bug". The
problem, for lurkers, is that the DataSource.DataSet property is
disappearing (being set to nil) during compilation when the DataSource
is on the form, and the DataSet is on a DataModule. Borland might
already know of this bug, but if you change the order (in the
project.dsk file) that the modules load (the moduleX= lines), It fixes
this. I just re-started Delphi 4 times. Both times where the
DataModule was created first in the moduleX= order, it worked fine upon
compiling, and both times the form was listed first, the DataSet
property disappeared upon compiling. This definitely smells like a
Delphi IDE (or FixUps from classes.pas) bug to me, especially since it
happens both in my components and in the standard Delphi components.
I don't have a good solution yet, but at least now I know the source
of the problem. Has anyone reported this bug to Borland? If not, I
will do it tomorrow. Sadly, I'm sure it is too late to fix it for
Delphi 4.00, but maybe for 4.01 they can fix it. Does anyone else have
another workaround (other than manually editing the dsk each time I run
Delphi <G>)?
Erik