Hello Dimitri,
I added some steps in the scenario as I expect the things go:
1) vnc is started and creates an atom
2) the user does something and logs off
3) windows deletes the atom table
4) a user logs on again
5) a Delphi application is started
6) the Delphi window is hidden
7) when a window
Hello Dimitri,
I've also looked at this problem more than once.
Recently I've bought a Delphi package that put me on a trial that might lead
to a fix. This package is used to build windows services with Delphi. It put
a lot of time in finding a problem that relates to interactive services.
It tur
Hello,
I am experiencing the same problem using an application built with
Borland C++ Builder 4 or 5.
The last message on that topic was posted on June 20, 2001. I assume
that still there is no fix. I am using the latest copy of VNC for
Windows, release 3.3.3r9. The OS is Windows NT 4.0 SP6a.
T
This is an reaction to a discussion on Delphi apps that ended in February.
As far as I can track it down there never was a solution, was there?
Anyway, the problem is still bugging me.
My program writes a stack trace when this error occurs, so I know for a fact
that analysis that FindDragTraget c
> Could be that if you forget to remove the props, and the atom is removed,
> then Delphi could get the same atom number as VNC had when it starts up.
> However, the VNCHooks atom is only removed on WinVNC shutdown AFAIK, and
> I see no reason why we should have been restarting WinVNC.
The proper
>VNC Uses GlobalAddAtom to add two atoms to the atom table. It does this in
>the hook DLL, inside each hooked application. The atoms are used to SetProp
>and GetProp on hooked windows. It sounds like Delphi and VNC are somehow
>ending up using the same atom values.
Could be that if you forget
> I made some research about it, and realized that:
>
> The error comes from FindControl (in Controls.pas). Every time you move
> the mouse, the active application - the Delphi app - is notified. In
> order to be able to send mouse move events to the control below (or for
> some other reason), Del
>Every control/hWnd has a property named "ControlOfs" plus the hInstance
>and the thread ID number. A global atom for this is created at program
>startup.
...and the data in this property is a pointer to the Delphi class
instance of the control.
>Therefore, FindControl calls the Win32 function
I just joined the mailing list to tell you about a bug that creates AV's
on Delphi apps. The AV address is in TControl.ScreenToClient. I searched
the mailing list archive as well and I saw that this bug has been
reported earlier.
But I saw nothing about a fix, so I guess it is still an open bu
