[DUG] Debugging on TS

Stephen Barker Steve at webdata.co.nz
Fri Jul 29 17:57:17 NZST 2005 

Maybe you could change the btnclick to not close the form but post a
wm_close message to it?

Steve 

> -----Original Message-----
> From: Rohit Gupta [mailto:rohit at cfl.co.nz] 
> Sent: Friday, 29 July 2005 4:47 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: RE: [DUG] Debugging on TS
> 
> After removing all instances of ProcessMessages in the chain 
> of execution the problem still happpens.  The only common thing is 
> that the last event is Buttonup....   Yes we have been here before.
> 
> One of the major flaws in windoze... where the btnclick 
> closes a form the btnup event can go to some other form.
> 
> If I alter the form so that a click on the panel closes the 
> form (just the same way the button would do) then everything 
> works fine.  If the button is pressed then we have this silly 
> exception.
> 
> I am still a bit dubious about multiple instances of 
> comctl32.  There are infact three copies on the TS server - 
> all different.
> 
> From:           	"Rohit Gupta" <rohit at cfl.co.nz>
> Organization:   	Computer Fanatics Ltd
> To:             	NZ Borland Developers Group - Delphi 
> List <delphi at ns3.123.co.nz>
> Date sent:      	Fri, 29 Jul 2005 09:34:30 +1200
> Subject:        	RE: [DUG] Debugging on TS
> Priority:       	normal
> Send reply to:  	rohit at cfl.co.nz,
>   	NZ Borland Developers Group - Delphi List <delphi at ns3.123.co.nz>
> 	<mailto:delphi-request at ns3.123.co.nz?subject=unsubscribe>
> 	<mailto:delphi-request at ns3.123.co.nz?subject=subscribe>
> 
> [ Double-click this line for list subscription options ] 
> 
> Max,
> 
> >From the name of function/procedure in ntdll it was obvious that it
> was context switch.  But I had not suspected 
> Reschedule_Thread.  I will try it out shortly.... bearing in 
> mind that if the problem disappears it doesnt prove anything.  :-)
> 
> In the meantime I have removed two threads created by the 
> coloured button components that we use.  It was a frivolous 
> use of the thread and its gone... but the problem remains.
> 
> Finally, if you look at this dump of dlls.  Why is comctl32 
> in twice - and two different versions ?  At present I suspect 
> this more.  For a normal environment I would say this is a no 
> no.... but TS... who knows.
> 
> 
> modules:
> 00400000 vetlink.exe                 c:\vl2\livedata
> 10000000 gds32.dll    6.3.0.4288     C:\WINDOWS\system32
> 4b750000 hhctrl.ocx   5.2.3790.2427  C:\WINDOWS\system32
> 5ccf0000 SAMLIB.dll   5.2.3790.1830  C:\WINDOWS\System32
> 5e9a0000 olepro32.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 5f120000 ntlanman.dll 5.2.3790.1830  C:\WINDOWS\System32 
> 5f270000 hnetcfg.dll  5.2.3790.1830  C:\WINDOWS\system32
> 5f860000 NETUI1.dll   5.2.3790.0     C:\WINDOWS\System32
> 5f8a0000 NETUI0.dll   5.2.3790.0     C:\WINDOWS\System32
> 71ae0000 wshtcpip.dll 5.2.3790.0     C:\WINDOWS\System32
> 71b20000 mswsock.dll  5.2.3790.1830  C:\WINDOWS\System32 
> 71b70000 uxtheme.dll  6.0.3790.1830  C:\WINDOWS\system32
> 71bb0000 wsock32.dll  5.2.3790.0     C:\WINDOWS\system32
> 71bc0000 rdpsnd.dll   5.2.3790.0     C:\WINDOWS\system32
> 71bd0000 mpr.dll      5.2.3790.0     C:\WINDOWS\system32
> 71bf0000 WS2HELP.dll  5.2.3790.1830  C:\WINDOWS\system32
> 71c00000 WS2_32.dll   5.2.3790.1830  C:\WINDOWS\system32
> 71c20000 tsappcmp.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 71c40000 NETAPI32.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 73070000 winspool.drv 5.2.3790.1830  C:\WINDOWS\system32
> 73440000 RICHED32.DLL 5.2.3790.0     C:\WINDOWS\system32
> 74b40000 oledlg.dll   5.2.3790.0     C:\WINDOWS\system32
> 74c40000 RICHED20.DLL 5.31.23.1224   C:\WINDOWS\system32
> 75e90000 drprov.dll   5.2.3790.1830  C:\WINDOWS\System32
> 75ea0000 davclnt.dll  5.2.3790.0     C:\WINDOWS\System32
> 76290000 imm32.dll    5.2.3790.1830  C:\WINDOWS\system32
> 762b0000 comdlg32.dll 6.0.3790.1830  C:\WINDOWS\system32 
> 767a0000 UNIDRVUI.DLL 0.3.3790.1830
> C:\WINDOWS\system32\spool\DRIVERS\W32X86\3
> 76aa0000 winmm.dll    5.2.3790.1830  C:\WINDOWS\system32
> 76b70000 PSAPI.DLL    5.2.3790.1830  C:\WINDOWS\system32
> 76ed0000 DNSAPI.dll   5.2.3790.1830  C:\WINDOWS\system32
> 76f00000 wtsapi32.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 76f10000 WLDAP32.dll  5.2.3790.1830  C:\WINDOWS\system32 
> 76f50000 Secur32.dll  5.2.3790.1830  C:\WINDOWS\system32
> 76f70000 winrnr.dll   5.2.3790.1830  C:\WINDOWS\System32
> 76f80000 rasadhlp.dll 5.2.3790.1830  C:\WINDOWS\system32
> 771f0000 WINSTA.dll   5.2.3790.1830  C:\WINDOWS\system32
> 77380000 user32.dll   5.2.3790.1830  C:\WINDOWS\system32
> 77420000 comctl32.dll 6.0.3790.1830
> C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-
> Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF
> 77530000 comctl32.dll 5.82.3790.1830
> C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-
> Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A
> 77670000 ole32.dll    5.2.3790.1830  C:\WINDOWS\system32
> 77b90000 version.dll  5.2.3790.1830  C:\WINDOWS\system32
> 77ba0000 msvcrt.dll   7.0.3790.1830  C:\WINDOWS\system32
> 77c00000 GDI32.dll    5.2.3790.1830  C:\WINDOWS\system32
> 77c50000 RPCRT4.dll   5.2.3790.1830  C:\WINDOWS\system32
> 77d00000 oleaut32.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 77da0000 SHLWAPI.dll  6.0.3790.2440  C:\WINDOWS\system32 
> 77e40000 kernel32.dll 5.2.3790.1830  C:\WINDOWS\system32 
> 77f50000 ADVAPI32.dll 5.2.3790.1830  C:\WINDOWS\system32
> 780c0000 MSVCP60.dll  6.5.2144.0     C:\WINDOWS\system32
> 7c800000 ntdll.dll    5.2.3790.1830  C:\WINDOWS\system32
> 7c8d0000 shell32.dll  6.0.3790.1830  C:\WINDOWS\system32
> 
> 
> From:           	"Max Nilson" <mnilson at xtra.co.nz>
> To:             	<rohit at cfl.co.nz>,
>   	"'NZ Borland Developers Group - Delphi List'" 
> <delphi at ns3.123.co.nz>
> Subject:        	RE: [DUG] Debugging on TS
> Date sent:      	Thu, 28 Jul 2005 19:30:38 +1200
> Organization:   	Profax International Limited
> Send reply to:  	mnilson at xtra.co.nz
> 
> Rohit asked:
> 
> > Heres a dump from madshit.   Any clues anyone ?  It appears 
> > to be inside ntdll.
> 
> Looks like your code is going reentrant. Your 
> Reschedule_Thread is causing it, and I'm assuming that you 
> want it to do this, but it has been a persistent source of 
> errors in our application for years now. Just when you damn 
> well know that there can be no pending events, you find out 
> that something like the mouse driver starts doing syncronous 
> SendMessage calls that are getting grabbed by a nested 
> ProcessMessages and all hell breaks loose.
> 
> I think that you should investigate removing the reentrancy 
> and seeing if TS likes this better.
> 
> Good luck,
> Max.
> Regards
> 
> Rohit
> 
> ======================================================================
> CFL - Computer Fanatics Ltd.  21 Barry's Point Road, AKL, New Zealand
> PH    (649) 489-2280 
> FX    (649) 489-2290
> email rohit at cfl.co.nz  or  r.gupta at xtra.co.nz 
> ======================================================================
> 
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> Regards
> 
> Rohit
> 
> ======================================================================
> CFL - Computer Fanatics Ltd.  21 Barry's Point Road, AKL, New Zealand
> PH    (649) 489-2280 
> FX    (649) 489-2290
> email rohit at cfl.co.nz  or  r.gupta at xtra.co.nz 
> ======================================================================
> 
> 
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
> 
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 
> 28/07/2005
>  
>

More information about the Delphi mailing list