Page 1 of 1
Xhb February and latest fwh
Posted: Sun Mar 05, 2006 10:22 am
by Richard Chidiak
Antonio,
I have not yet upgraded my xhb to the latest february build. I still use jan build for Xhb and FWH
One of your posts concerning "C" code changes is worrying me. I use many third party libraries that contain C code almost all of them. Hernan's twbrowse (i saw you published a fix for this one), tsbuttons, tsbrowse,VRD ...
Do we have to make changes to all these c codes ? If so has anyone made these changes and can share them ?
Thanks in advance for clarifying,
Richard
Posted: Sun Mar 05, 2006 10:57 am
by Antonio Linares
Richard,
In the past two months there have been several changes in Harbour/xHarbour that required to modify FWH.
The first one was related with _hb_stack that can no longer be used.
The second one was with the PHB_ITEM that can not be directly managed (as a pointer to a structure).
It was not FWH desition to make these changes. We had to adapt to them, in order to keep compatibility with Harbour/xHarbour changes.
If you recompile your C source code, then you should not have any problems, except on those C functions where PHB_ITEMs are directly managed. In those cases several minor changes are required, like the ones we implemented in Hernan's browse as a sample.
Our advise is that you should start using FWH February build and see what problems you may have with third party utilities and together implement the fixes, if needed.
Posted: Sun Mar 05, 2006 12:18 pm
by Richard Chidiak
Antonio Linares wrote:Richard,
In the past two months there have been several changes in Harbour/xHarbour that required to modify FWH.
The first one was related with _hb_stack that can no longer be used.
The second one was with the PHB_ITEM that can not be directly managed (as a pointer to a structure).
It was not FWH desition to make these changes. We had to adapt to them, in order to keep compatibility with Harbour/xHarbour changes.
If you recompile your C source code, then you should not have any problems, except on those C functions where PHB_ITEMs are directly managed. In those cases several minor changes are required, like the ones we implemented in Hernan's browse as a sample.
Our advise is that you should start using FWH February build and see what problems you may have with third party utilities and together implement the fixes, if needed.
Antonio
If only HB_ITEM has to be changed, then there is nothing to change in TSBUTTON, TSBROWSE and VRD None of these are using HB_item
I am going to make tests this afternoon and report back.
Thanks for your help,
Richard
Posted: Sun Mar 05, 2006 1:31 pm
by Richard Chidiak
Richard Chidiak wrote:Antonio Linares wrote:Richard,
In the past two months there have been several changes in Harbour/xHarbour that required to modify FWH.
The first one was related with _hb_stack that can no longer be used.
The second one was with the PHB_ITEM that can not be directly managed (as a pointer to a structure).
It was not FWH desition to make these changes. We had to adapt to them, in order to keep compatibility with Harbour/xHarbour changes.
If you recompile your C source code, then you should not have any problems, except on those C functions where PHB_ITEMs are directly managed. In those cases several minor changes are required, like the ones we implemented in Hernan's browse as a sample.
Our advise is that you should start using FWH February build and see what problems you may have with third party utilities and together implement the fixes, if needed.
Antonio
If only HB_ITEM has to be changed, then there is nothing to change in TSBUTTON, TSBROWSE and VRD None of these are using HB_item
I am going to make tests this afternoon and report back.
Thanks for your help,
Richard
Antonio
Confirmed,
Tsbutton, Tsbrowse, VRD work OK with FWh march and XHB february without any change (just recompile).
Hernan's twbrowse recompiled with the c program changed work OK.
Just the dynsymsymbol error at link fixed by the following found on this forum.
#pragma BEGINDUMP
#include "hbapi.h"
#include "hbapiitm.h"
PHB_SYMB hb_dynsymSymbol( PHB_DYNS pDynSym )
{
return pDynSym->pSymbol;
}
Richard
Posted: Sun Mar 05, 2006 2:38 pm
by Antonio Linares
Richard,
glad to know it is ok