bugs FWH64
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
bugs FWH64
Antonio,
In FWH64, class Twebcam is not included.
Also, testing samples\testrtf causes a GPF.
Thank you much.
In FWH64, class Twebcam is not included.
Also, testing samples\testrtf causes a GPF.
Thank you much.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
This is the hb_out.log when attemping to use RICHEDIT under FWH64:
Thanks.
This is the hb_out.log when attemping to use RICHEDIT under FWH64:
Code: Select all | Expand
Called from RESETOLECALLBACK(0)
Called from (b)TRICHEDIT(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:SETOLECALLBACK(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:DEFAULT(0) in .\source\classes\TRICHEDI.PRG
Called from (b)TRICHEDIT(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:INITIATE(0) in .\source\classes\TRICHEDI.PRG
Called from __OBJSENDMSG(0)
Called from OSEND(0) in .\source\function\HARBOUR.PRG
Called from ASEND(0) in .\source\function\HARBOUR.PRG
Called from TDIALOG:INITIATE(0) in .\source\classes\DIALOG.PRG
Called from TDIALOG:HANDLEEVENT(0) in .\source\classes\DIALOG.PRG
Called from DIALOGBOX(0)
Called from TDIALOG:ACTIVATE(0) in .\source\classes\DIALOG.PRG
Called from MAIN(41) in demo.prg
Thanks.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
Thanks for the feedback, I am going to review it asap.
I am currently completing my tests on the printer preview enhancements that Armando and Elvira requested and we have implemented
Thanks for the feedback, I am going to review it asap.
I am currently completing my tests on the printer preview enhancements that Armando and Elvira requested and we have implemented

- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
This seems to be the fix
the WIN64 part was missing. You can test it adding it to the PRG in a #pragma BEGINDUMP ENDDUMP section
This seems to be the fix

Code: Select all | Expand
HB_FUNC( REGETOLEINTERFACE )
{
#ifdef _WIN64
hb_retl( SendMessage( ( HWND ) hb_parnll( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#else
hb_retl( SendMessage( ( HWND ) hb_parnl( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#endif
}
the WIN64 part was missing. You can test it adding it to the PRG in a #pragma BEGINDUMP ENDDUMP section
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
I tested this:
#pragma BEGINDUMP
#include "windows.h"
#include "wininet.h"
#include "hbapi.h"
#include "richedit.h"
#include <richole.h>
HB_FUNC( REGETOLEINTERFACE )
{
#ifdef _WIN64
hb_retl( SendMessage( ( HWND ) hb_parnll( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#else
hb_retl( SendMessage( ( HWND ) hb_parnl( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#endif
}
#pragma ENDDUMP
But I can´t compile:
msvc64.prg(155) : error C2065: 'predoc' : undeclared identifier
msvc64.prg(155) : error C2227: left of '->preole' must point to class/struct/union/generic type
type is ''unknown-type''
Thanks!.
I tested this:
#pragma BEGINDUMP
#include "windows.h"
#include "wininet.h"
#include "hbapi.h"
#include "richedit.h"
#include <richole.h>
HB_FUNC( REGETOLEINTERFACE )
{
#ifdef _WIN64
hb_retl( SendMessage( ( HWND ) hb_parnll( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#else
hb_retl( SendMessage( ( HWND ) hb_parnl( 1 ),
EM_GETOLEINTERFACE, 0, ( LPARAM ) &predoc->preole ) );
#endif
}
#pragma ENDDUMP
But I can´t compile:
msvc64.prg(155) : error C2065: 'predoc' : undeclared identifier
msvc64.prg(155) : error C2227: left of '->preole' must point to class/struct/union/generic type
type is ''unknown-type''
Thanks!.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
Thank you. Also, please include class tWebcam.
I do the test and I will inform you.
Thank you. Also, please include class tWebcam.
I do the test and I will inform you.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
The bug you reported me regarding RichEdit made me realize that there is code in FWH that has not been properly adapted to 64 bits:
Everytime we use the extend system to send or receive a handle, we have to use hb_parnll() and hb_retnll(). This is due to the fact that handles in WIN64 can be larger than in WIN32, so I have started searching for all of them and checking that they are fine. Up to now I was most focused on made FWH 64 bits apps work properly and missed that important part too.
I have already modified many FWH C files to properly use hb_parnll() and hb_retnll(). I have not finished with all of them, but I prefer to make the changes progressively in case that some code could bring a problem. In fact, I think that everytime we supply a HWND, HDC, HBITMAP, HBRUSH, HFONT, etc (any handle) we could simply call hb_parnll() even for 32 bits apps, but I am not sure yet 100% if this could have any side effect. Same applies for hb_retnll().
So on a first stage the idea is to inspect all the code, locate places where those handles are not properly managed in 64 bits and once that process is completed, we could consider to call hb_parnll() always (though that just would simplify the source code but would not benefit our apps).
The bug you reported me regarding RichEdit made me realize that there is code in FWH that has not been properly adapted to 64 bits:
Everytime we use the extend system to send or receive a handle, we have to use hb_parnll() and hb_retnll(). This is due to the fact that handles in WIN64 can be larger than in WIN32, so I have started searching for all of them and checking that they are fine. Up to now I was most focused on made FWH 64 bits apps work properly and missed that important part too.
I have already modified many FWH C files to properly use hb_parnll() and hb_retnll(). I have not finished with all of them, but I prefer to make the changes progressively in case that some code could bring a problem. In fact, I think that everytime we supply a HWND, HDC, HBITMAP, HBRUSH, HFONT, etc (any handle) we could simply call hb_parnll() even for 32 bits apps, but I am not sure yet 100% if this could have any side effect. Same applies for hb_retnll().
So on a first stage the idea is to inspect all the code, locate places where those handles are not properly managed in 64 bits and once that process is completed, we could consider to call hb_parnll() always (though that just would simplify the source code but would not benefit our apps).
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
Once FWH 13.07 is published, I would appreciate to locate those places where calls to hb_parnll() and hb_retnll() are missing, in case we may be missing some of them.
Right now is useless as I have already modified many of them, that in 13.06 are unchanged.
Once FWH 13.07 is published, I would appreciate to locate those places where calls to hb_parnll() and hb_retnll() are missing, in case we may be missing some of them.
Right now is useless as I have already modified many of them, that in 13.06 are unchanged.
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
So can you please send me to my gmail email the fixed 13.06 libs to work with Richedit?.
We will continue testing the application and providing you feedback.
Bitmaps seems to be working fine.
And please, what about TWebCam class?.
Thank you.
So can you please send me to my gmail email the fixed 13.06 libs to work with Richedit?.
We will continue testing the application and providing you feedback.
Bitmaps seems to be working fine.
And please, what about TWebCam class?.
Thank you.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
Class TWebCam was simply missing from the FWH 64 makefile. I am rebuilding FWH 64 to include it and I will send it to you.
In the meantime, if you add the source code of the Class TWebCam to your PRG, then it should work fine.
Class TWebCam was simply missing from the FWH 64 makefile. I am rebuilding FWH 64 to include it and I will send it to you.
In the meantime, if you add the source code of the Class TWebCam to your PRG, then it should work fine.
- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
With the new libs you sent to me, TWebCam is fixed. It is neccesary to include Vfw32.lib, so build64.bat should be modified as:
echo %vcdir%\lib\vfw32.lib >> msvc.tmp
But the GPF with RichEdit is still happening.
samples\testrtf.prg causes this hb_out.log:
By the way, samples\winxp\WindowsXP.Manifest64 is missing.
Sorry about the bad news
Thank you.
With the new libs you sent to me, TWebCam is fixed. It is neccesary to include Vfw32.lib, so build64.bat should be modified as:
echo %vcdir%\lib\vfw32.lib >> msvc.tmp
But the GPF with RichEdit is still happening.
samples\testrtf.prg causes this hb_out.log:
Code: Select all | Expand
Application Internal Error - C:\FWH64\samples\testrtf.exe
Terminated at: 2013.07.22 22:41:28
Unrecoverable error 6005: Exception error:
Exception Code:C0000005
Exception Address:0x000007FEF4846D7C
RAX:0x0000000000000000 RBX:0x0000000002830A40 RCX:0x0000000000431F60 RDX:0x0000000000000000
RSI:0x0000000000000000 RDI:0x0000000000445520 RBP:0x0000000000431F60
R8 :0x0000000000000000 R9 :0x0000000000000000 R10:0x0000000000002353 R11:0x0000000000000001
R12:0x0000000080004005 R13:0x000000000025DDF8 R14:0x0000000000000004 R15:0x0000000000000001
CS:RIP:0033:0x000007FEF4846D7C SS:RSP:002B:0x000000000025DAC0
DS:002B ES:002B FS:0053 GS:002B
Flags:00010206
Modules:
0x000000013FCC0000 0x000000000030D000 C:\FWH64\samples\testrtf.exe
0x0000000077310000 0x00000000001A9000 C:\Windows\SYSTEM32\ntdll.dll
0x00000000770F0000 0x000000000011F000 C:\Windows\system32\kernel32.dll
0x000007FEFD220000 0x000000000006B000 C:\Windows\system32\KERNELBASE.dll
0x0000000077210000 0x00000000000FA000 C:\Windows\system32\USER32.dll
0x000007FEFDA80000 0x0000000000067000 C:\Windows\system32\GDI32.dll
0x000007FEFDBD0000 0x000000000000E000 C:\Windows\system32\LPK.dll
0x000007FEFDBE0000 0x00000000000C9000 C:\Windows\system32\USP10.dll
0x000007FEFE2D0000 0x000000000009F000 C:\Windows\system32\msvcrt.dll
0x000007FEF9D60000 0x0000000000071000 C:\Windows\system32\WINSPOOL.DRV
0x000007FEF9F40000 0x00000000000A0000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_a4d6a923711520a9\COMCTL32.dll
0x000007FEFE170000 0x00000000000DB000 C:\Windows\system32\ADVAPI32.dll
0x000007FEFE2A0000 0x000000000001F000 C:\Windows\SYSTEM32\sechost.dll
0x000007FEFE370000 0x000000000012D000 C:\Windows\system32\RPCRT4.dll
0x000007FEFE4A0000 0x0000000000097000 C:\Windows\system32\COMDLG32.dll
0x000007FEFD7D0000 0x0000000000071000 C:\Windows\system32\SHLWAPI.dll
0x000007FEFE890000 0x0000000000D88000 C:\Windows\system32\SHELL32.dll
0x000007FEFD520000 0x0000000000203000 C:\Windows\system32\ole32.dll
0x000007FEFC250000 0x000000000000C000 C:\Windows\system32\VERSION.dll
0x000007FEFA100000 0x0000000000007000 C:\Windows\system32\MSIMG32.dll
0x000007FEF9FE0000 0x0000000000023000 C:\Windows\system32\oledlg.dll
0x00000000774D0000 0x0000000000007000 C:\Windows\system32\PSAPI.DLL
0x000007FEFDAF0000 0x00000000000D7000 C:\Windows\system32\OLEAUT32.dll
0x000007FEFDF40000 0x000000000002E000 C:\Windows\system32\IMM32.DLL
0x000007FEFE700000 0x0000000000109000 C:\Windows\system32\MSCTF.dll
0x000007FEF4830000 0x000000000009E000 C:\Windows\system32\Riched20.dll
0x000007FEFAC80000 0x0000000000056000 C:\Windows\system32\uxtheme.dll
0x000007FEFA7C0000 0x0000000000018000 C:\Windows\system32\dwmapi.dll
0x000007FEFD020000 0x000000000000F000 C:\Windows\system32\CRYPTBASE.dll
0x000007FEFC9C0000 0x0000000000017000 C:\Windows\system32\CRYPTSP.dll
0x000007FEFC6C0000 0x0000000000047000 C:\Windows\system32\rsaenh.dll
0x000007FEFB3A0000 0x00000000001F4000 C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_fa396087175ac9ac\comctl32.DLL
Called from RESETOLECALLBACK(0)
Called from (b)TRICHEDIT(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:SETOLECALLBACK(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:DEFAULT(0) in .\source\classes\TRICHEDI.PRG
Called from TRICHEDIT:NEW(0) in .\source\classes\TRICHEDI.PRG
Called from NEW(250) in testrtf.prg
Called from (b)SETMENU(65) in testrtf.prg
Called from TMENU:COMMAND(0) in .\source\classes\MENU.PRG
Called from TWINDOW:COMMAND(0) in .\source\classes\WINDOW.PRG
Called from TMDIFRAME:COMMAND(0) in .\source\classes\MDIFRAME.PRG
Called from TMDIFRAME:HANDLEEVENT(0)
Called from _FWH(0) in .\source\classes\WINDOW.PRG
Called from WINRUN(0)
Called from TMDIFRAME:ACTIVATE(0) in .\source\classes\WINDOW.PRG
Called from MAIN(36) in testrtf.prg
------------------------------------------------------------------------
By the way, samples\winxp\WindowsXP.Manifest64 is missing.
Sorry about the bad news

Thank you.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
thanks for your feedback, I was expecting it, as I did not include in the libs that I sent you all the changes that I did later on on richedit.
I am solving an issue with FWH 64 (testing on Windows 8, as there are some internal changes between Windows 7 and 8 ) and then I will be ready to send you a more recent libs that should work fine
thanks for your feedback, I was expecting it, as I did not include in the libs that I sent you all the changes that I did later on on richedit.
I am solving an issue with FWH 64 (testing on Windows 8, as there are some internal changes between Windows 7 and 8 ) and then I will be ready to send you a more recent libs that should work fine

- lucasdebeltran
- Posts: 1303
- Joined: Tue Jul 21, 2009 8:12 am
- Contact:
Re: bugs FWH64
Antonio,
Any news please?.
Thanks.
Any news please?.
Thanks.
Muchas gracias. Many thanks.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
Un saludo, Best regards,
Harbour 3.2.0dev, Borland C++ 5.82 y FWH 13.06 [producción]
Implementando MSVC 2010, FWH64 y ADO.
Abandonando uso xHarbour y SQLRDD.
- Antonio Linares
- Site Admin
- Posts: 42833
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Has thanked: 157 times
- Been thanked: 121 times
- Contact:
Re: bugs FWH64
Lucas,
I have succesfully built Harbour and FWH 64 using VS2012 and it is working fine
Could you upgrade to VS2012 C Express ? For us it is much more complex to support multiple versions, and I think VS2012 is a very good version to use. I can email the libs to you and you try it on VS2010 (I don't know yet if they are compatible, probably), thanks
I have succesfully built Harbour and FWH 64 using VS2012 and it is working fine

Could you upgrade to VS2012 C Express ? For us it is much more complex to support multiple versions, and I think VS2012 is a very good version to use. I can email the libs to you and you try it on VS2010 (I don't know yet if they are compatible, probably), thanks