Hi Pritpal,
> ---
> Application Internal Error - Z:\demowvg.exe
> Called from WVG_STATUSBARCREATEPANEL(0)
> Called from WVGSTATUSBAR:ADDITEM(0) in .\wvgstatb.prg
> Called from WVGSTATUSBAR:CREATE(0) in .\wvgstatb.prg
> Called from EXECUTEACTIVEX(2382) in demowvg.prg
> Called from (b)EVAL(1430)
> ---
> >>>>
>
> So to be sure that all other components are working or not,
> except Statusbar control, attached is modified demowvg.prg.
> Please do the above test with it and click only first prompt of
> Active-X menu <Pure Xbase++>.
Here are the results:
---
Application Internal Error - Z:\demowvg6.exe
Terminated at: 2009.02.22 07:28:10
Unrecoverable error 6005: Exception error:
Exception Code:C0000005
Exception Address:0x00000000400E2D70
RAX:0x0000000077C43ABC RBX:0x0000000000000000 RCX:0x0000000000000000
RDX:0x0000000000000001
RSI:0x000000000000000C RDI:0x0000000000000000 RBP:0x000000000241F980
R8 :0x0000000000000000 R9 :0x000000014012F8CC R10:0x000000000241F9F0
R11:0x0000000077C20000
R12:0x000000014012F8CC R13:0x00000000004E0110 R14:0x00000000004E0110
R15:0x0000000000000000
CS:RIP:0033:0x00000000400E2D70 SS:RSP:002B:0x000000000241F950
DS:002B ES:002B FS:0053 GS:002B
Flags:00010246
Modules:
0x0000000140000000 0x00000000001B2000 Z:\demowvg6.exe
0x0000000077EC0000 0x0000000000139000 C:\WINDOWS\system32\ntdll.dll
0x0000000077D40000 0x0000000000173000 C:\WINDOWS\system32\kernel32.dll
0x000007FF76200000 0x00000000000EF000
C:\WINDOWS\WinSxS\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.3959_x-ww_AB06DEB0\COMCTL32.dll
0x000007FF7FEE0000 0x0000000000105000 C:\WINDOWS\system32\ADVAPI32.dll
0x000007FF7FD30000 0x0000000000199000 C:\WINDOWS\system32\RPCRT4.dll
0x000007FF7E9C0000 0x0000000000022000 C:\WINDOWS\system32\Secur32.dll
0x000007FF7FC90000 0x000000000009C000 C:\WINDOWS\system32\GDI32.dll
0x0000000077C20000 0x000000000010C000 C:\WINDOWS\system32\USER32.dll
0x000007FF7D540000 0x0000000000077000 C:\WINDOWS\system32\COMDLG32.dll
0x000007FF7FC00000 0x0000000000086000 C:\WINDOWS\system32\msvcrt.dll
0x000007FF7EF60000 0x000000000009B000 C:\WINDOWS\system32\SHLWAPI.dll
0x000007FF7F190000 0x0000000000A0B000 C:\WINDOWS\system32\SHELL32.dll
0x000007FF57140000 0x0000000000285000 C:\WINDOWS\system32\ole32.dll
0x000007FF7EBC0000 0x0000000000116000 C:\WINDOWS\system32\OLEAUT32.dll
0x000007FF7D500000 0x0000000000039000 C:\WINDOWS\system32\IMM32.DLL
0x000007FF7F000000 0x0000000000187000
C:\WINDOWS\WinSxS\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.3959_x-ww_0A7B2435\comctl32.dll
0x000007FF7D310000 0x0000000000006000 C:\WINDOWS\system32\msimg32.dll
0x000007FF7A410000 0x000000000009F000 C:\WINDOWS\system32\MSCTF.dll
0x000007FF7CE50000 0x0000000000041000 C:\WINDOWS\system32\apphelp.dll
0x000007FF58AF0000 0x000000000005C000 C:\WINDOWS\system32\msctfime.ime
Called from WIN_SENDMESSAGETEXT(0)
Called from WVGSTATIC:SETCAPTION(0) in .\wvgstatc.prg
Called from WVGSTATIC:CREATE(0) in .\wvgstatc.prg
Called from DEMOXBP(3044) in demowvg.prg
Called from (b)EVAL(1437)
------------------------------------------------------------------------
> I tried Przemek's code. It works but it is not that elegant
> solution. May be he comes up with more sophisticated way
> as is employed in xhb. Till then...
Did you try the other method?
Surely they are both much more elegant than xhb cstructs,
as this latter passes binary structures around in _strings_,
so all it takes is a silly .prg level mistake to corrupt C level
data.
BTW I used this kind of method for a few structures in Clipper,
since it had no other way, but since, all those had been
converted to Harbour GC collected pointers.
BTW I did not see any memory corruption if I use xhb
> implementation of structures. I am using it since ages.
> To be very sure I retested all my routines using xhb
> structures in MT environmrnt and I could not find even
> a single hb_out.log entry. But I may be wrong...
Yes, such MT problems are notoriously difficult to find,
so just because you didn't see them doesn't mean
they aren't there, all it takes is some MT app which does
some things actually in parallel + bad luck and the app
crashes / corrupts memory or data. The structure code
simply isn't obeying some basic MT programming rules,
see my NOTE in the ChangeLog:
---
; TOFIX: - hbwhat/wincore.prg
- xhb/cstruct.prg
Needs reviewing and either mutex protection
for STATICs or conversion to THREAD STATIC.
---
> <<<<
> The callback support also needs to be solved, you
> didn't address that part.
> >>>>
>
> I told before, it is extremely gray area for me.
> I just implemented Andy Wos code. He is better equipped
> to refine it. He is not available online these days, may be
> on vacations, otherwise I must have requested him.
IMO a better solution would be to recode these in a non-generic
way (each CALLBACK gets a separate wrapper), instead of
using this generic callback solution which isn't portable. Since
the code uses heavy hacks, I'm not sure it would be trivial
to port to amd64/IA64/ARM even for Andy himself, and what
is really annoying and non-efficient here, is that he'd need
to add code _for each CPU separately_, test them separately,
which is for sure not very efficient and error prone.
These two parts make GTWVG a minefield to walk upon.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
