D3: Help needed: TControl/TWinControl
Rick Rogers (TeamB)
<sch...@itkompetenz.com> wrote:
> Are there any known incompatibilities between D3 (Release 3.01)
> and Windows 95 System DLLs
Not that I'm aware of.
> EAccessVialoation pointing to an address where the linker's
> map-file shows Delphi-Code belonging to TControl and
> TWinControl.
There are hosts of errors you can make in your application code which
would result in this observation. The most common are using an object
reference before the instance has been created, or after it has been
destroyed.
At this point you should assume that the error is caused in your code,
and you should use standard debugging techniques to find it.
--
Rick Rogers (TeamB) | Fenestra Technologies
http://www.fenestra.com/
Rick Rogers (TeamB)
<sch...@itkompetenz.com> wrote:
> I'm looking for reasons in the windows environment because
> the error appears even when you are just clicking in a normal TEdit
If you feel this is a productive approach, go for it. I suspect you'll
find the error is actually a latent bug in your application, which
only manifests itself after a specific sequence of events.
Mark Richter
I suspect Rick's suggestion is going to prove more fruitful.
We have an application written specifically for a paging company. One
client. Not a lot of motivation to test on every platform available.
Yet, on one of his machines, the printing "drops" invoices on
occassion. The application will suddenly generate dozens or hundreds of
services. And sometimes, when seeking to a customer's record, the
system will just appear to hang.
So far, we have determined that the printing issues are exacerbated by
their specific printer and driver. However, we suspect a memory leak
within the printing application. After a certain amount prints, the
printing "blows", and then seems okay for a while until things load up
again.
The issue of generating a bunch of records took us a long time to track
down. We still haven't figured out how to fix it, but we at last
reproduced it. It was an arduous task at best testing the patience of
our cleint.
Finally, the infrequent system hanging, we have yet to reproduce
inhouse, but we are working on it, suspecting our application rather
than the customer's platform. At first, we did expect their platform,
but after reloading the OS and the problem persisted, we have no other
alternative but to look inward...
I'm not suggesting that it is not the OS or some component therein, but
you may well find, as we did, that the root cause is hidden within the
code and is only activated by an "unusual" sequence of events on the
part of your customer. And my personal opinion in that area is that no
sequence of events should be able to cause unexpected results. That is
part of my responsibility in developing software.
If you do wish to persue the platform, you might want to see if you can
get your hands on a utility such as WPS.EXE which shipped many years ago
with VB 3. It shows you most of the DLL and DLL like modules that get
loaded. Using this, you can attempt to understand what files your
application depends on, and where to start looking. Armed with this
knowledge, you can then isolate one misbehaving PC and attempt to
"normalize" the specific modules that are involved. Bear in mind though
that "downgrading" a single DLL or other module can have a negative
impact on the operating system. So, roll up your sleeves, and settle in
for some serious combat. Also, be sure to somehow backup or preserve
the customer's original environment as it is amost a certainty that your
exploration will result in at least one iteration that really screws the
pooch.
I wish you the best of luck with your research.
--
Mark Richter
eMCee Software