Converting Clipper Summer 87 to Harbour. Getting errors........
mmj0426
the Summer'87 version and would like to convert using Harbour2.0.0. I
am using the linker hbmk2 and receiving all these errors when trying
to compile and link!!! Can someone please help shine some light on
this???? I am very confused at this point. I normally program using
object oriented but was asked to convert this old system. Maybe this
cannot be done this way?? Thanks in advance!!
C:\CONFR>set path=c:\hrbour\bin
C:\CONFR>hbmk2 co_main.prg co_index.prg co_rept.prg co_nod.prg
co_sal.prg co_lis
t.prg co_pend.prg co_proc.prg clipper.lib dgs_util.lib dor_util.lib
overlay.lib
-oConfr.exe
hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
Harbour 2.0.0 (Rev. 13372)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'co_main.prg'...
Cannot open VAR_INIT.prg, assumed external
Cannot open BORDERS.prg, assumed external
Cannot open SAV_SCRN.prg, assumed external
Cannot open RST_SCRN.prg, assumed external
Cannot open DISP_MSG.prg, assumed external
Cannot open U_SCROLL.prg, assumed external
Cannot open SCRL_RET.prg, assumed external
Cannot open DIS_SCRN.prg, assumed external
Cannot open DISP_MSG2.prg, assumed external
Cannot open WRIT_REC.prg, assumed external
Cannot open SCRL_TOS.prg, assumed external
Cannot open PRLETTER.prg, assumed external
Cannot open MEMLETLOG.prg, assumed external
Cannot open READ_REC.prg, assumed external
Cannot open SCRL_DRW.prg, assumed external
Cannot open CLR_GETS.prg, assumed external
Cannot open U_GET.prg, assumed external
Cannot open READ_SAY.prg, assumed external
Cannot open GET_KEYS.prg, assumed external
Lines 1687, Functions/Procedures 28
Generating C source output to 'co_main.c'... Done.
Compiling 'co_index.prg'...
Lines 1717, Functions/Procedures 1
Generating C source output to 'co_index.c'... Done.
Compiling 'co_rept.prg'...
co_rept.prg(231) Error E0002 Unterminated string ''
Cannot open BORDERS.prg, assumed external
Cannot open DISP_MSG.prg, assumed external
Cannot open SAV_SCRN.prg, assumed external
Cannot open RST_SCRN.prg, assumed external
Compiling 'CO_LIST.prg'...
Compiling 'CO_PEND.prg'...
Compiling 'CO_NOD.prg'...
Compiling 'CO_SAL.prg'...
Cannot open U_REP2.prg, assumed external
Cannot open U_SCROLL.prg, assumed external
Cannot open PRLETTER.prg, assumed external
Cannot open VAR_INIT.prg, assumed external
Cannot open SCRL_RET.prg, assumed external
Cannot open DIS_SCRN.prg, assumed external
Cannot open DISP_MSG2.prg, assumed external
Cannot open WRIT_REC.prg, assumed external
Cannot open SCRL_TOS.prg, assumed external
Cannot open READ_REC.prg, assumed external
Cannot open SCRL_DRW.prg, assumed external
Cannot open CLR_GETS.prg, assumed external
Cannot open U_GET.prg, assumed external
1 error
No code generated.
hbmk2: Error: Running Harbour compiler (embedded). 1
(c:\hrbour\bin\harbour.exe) -n2 co_main.prg co_index.prg co_rept.prg
co_nod.prg
co_sal.prg co_list.prg co_pend.prg co_proc.prg -ic:/hrbour/include
Angel Pais
Pbly you don't have a main procedure and subroutines are called via a
DO command and some other things like that.
I've done a couple of convertions from Summer87 and there was not much
to change to make them compile well and run fast in 32 bits.
First you have to list all prg files in an .hbp file and call hbmk2
project.hbp
Then there is also the chance that the old developper had used 3rd
party libraries non available in harbour...
Without sources is very difficult to point the errors.
HTH
Angel
On 22 jun, 12:10, mmj0426 <mmj0...@aol.com> wrote:
> Hello, I am VERY new to Clipper. I have an old application written in
> the Summer'87 version and would like to convert using Harbour2.0.0. I
> am using the linker hbmk2 and receiving all these errors when trying
> to compile and link!!! Can someone please help shine some light on
> this???? I am very confused at this point. I normally program using
> object oriented but was asked to convert this old system. Maybe this
> cannot be done this way?? Thanks in advance!!
>
> C:\CONFR>set path=c:\hrbour\bin
>
> C:\CONFR>hbmk2 co_main.prg co_index.prg co_rept.prg co_nod.prg
> co_sal.prg co_lis
> t.prg co_pend.prg co_proc.prg clipper.lib dgs_util.lib dor_util.lib
> overlay.lib
> -oConfr.exe
> hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
> Harbour 2.0.0 (Rev. 13372)
Przemysław Czerpak
Hi,
> Summer'87 is an older and a bit different dialect than 5.0 and above.
> Pbly you don't have a main procedure and subroutines are called via a
> DO command and some other things like that.
Current Harbour versions supports nicely such syntax in the same way
as Clipper. It's not fully supported by xHarbour.
> I've done a couple of convertions from Summer87 and there was not much
> to change to make them compile well and run fast in 32 bits.
> First you have to list all prg files in an .hbp file and call hbmk2
> project.hbp
It's not strictly necessary but for sure it makes life much easier.
> Then there is also the chance that the old developper had used 3rd
> party libraries non available in harbour...
> Without sources is very difficult to point the errors.
First it's necessary to clenup the code:
> > Compiling 'co_rept.prg'...
> > co_rept.prg(231) Error E0002 Unterminated string ''
This is the only one error message reported by Harbour compiler
and it's the problem in source code which should be fixed.
best regards,
Przemek
Viktor Szakáts
mmj0426
they seem to have compiled. I'm not sure what the last part means
though. It still would not link. My new errors are below.
Also, I'm sorry to ask such dumb questions but to be quite honest, I'm
so lost that I'm not sure what you need me to tell you so you can even
help me fix these errors. So, my question is how do I recompile from
the source? Do you mean the libraries source directory??
C:\CONFR>hbmk2 -l -m co_main.prg co_index.prg co_rept.prg co_nod.prg
co_sal.prg
co_list.prg co_pend.prg co_proc.prg extend.lib dgs_util.lib
dor_util.lib -oConfr
hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
Harbour 2.0.0 (Rev. 13372)
Generating C source output to 'co_main.c'... Done.
Compiling 'co_index.prg'...
Lines 1717, Functions/Procedures 1
Generating C source output to 'co_index.c'... Done.
Compiling 'co_rept.prg'...
Generating C source output to 'co_rept.c'... Done.
Compiling 'co_nod.prg'...
Lines 3468, Functions/Procedures 10
Generating C source output to 'co_nod.c'... Done.
Compiling 'co_sal.prg'...
Lines 4106, Functions/Procedures 10
Generating C source output to 'co_sal.c'... Done.
Compiling 'co_list.prg'...
Lines 5454, Functions/Procedures 12
Generating C source output to 'co_list.c'... Done.
Compiling 'co_pend.prg'...
Lines 5564, Functions/Procedures 2
Generating C source output to 'co_pend.c'... Done.
Compiling 'co_proc.prg'...
Lines 6288, Functions/Procedures 14
Generating C source output to 'co_proc.c'... Done.
c:/hrbour/comp/mingw/bin/../lib/gcc/mingw32/4.4.1/../../../../mingw32/
bin/ld.exe
: cannot find -lextend
collect2: ld returned 1 exit status
hbmk2: Error: Running linker. 1
c:\hrbour\comp\mingw\bin\gcc.exe co_main.o co_index.o co_rept.o
co_nod.o co_sal.
o co_list.o co_pend.o co_proc.o hbmk_guugle.o -mconsole -Wl,--start-
group -le
xtend -ldgs_util -ldor_util -lhbextern -lhbdebug -lhbvm -lhbrtl -
lhblang -lhbcpa
ge -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -
lhbusrrdd
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro
-lhbcplr
-lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -
lwinspool -lc
omctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -
lmapi32 -l
imm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -
oConfr.exe -Lc:/hr
bour/lib/win/mingw
mmj0426
libraries or not and do not know how to find out to tell you. I'm
going to assume dor_util is just by the name it has but the other one
probably not??
>
> - Show quoted text -
Viktor Szakáts
On Wednesday, June 22, 2011 8:37:01 PM UTC+2, mmj0426 wrote:
Hi and thanks for responding! I added -l and -m for the programs and
they seem to have compiled. I'm not sure what the last part means
though. It still would not link. My new errors are below.
Also, I'm sorry to ask such dumb questions but to be quite honest, I'm
so lost that I'm not sure what you need me to tell you so you can even
help me fix these errors. So, my question is how do I recompile from
the source? Do you mean the libraries source directory??
Maurizio Faccio adinet
Best regards
Maurizio
--
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users
Klas Engwall
> I'm not sure if he had used third party
> libraries or not and do not know how to find out to tell you. I'm
> going to assume dor_util is just by the name it has but the other one
> probably not??
I suppose that the original programmer is no longer available to help
you understand what he did?
As Viktor already mentioned, extend.lib came with Clipper. You will need
Harbour compiled versions of whatever the Clipper application used from
that lib. With a little luck all you need from there already exists in
Harbour.
Overlay.lib was a workaround for the 640KB barrier in DOS and is not
needed in Harbour. But you will have to remove whatever calls to
overlay.lib functions that exist in the prg files.
Clipper.lib is of course the Clipper runtime, and it is replaced with
functions of the same name in the Harbour runtime.
I searched the comp.lang.clipper newsgroup and the Oasis (the-oasis.net)
for "dgs" and "dor" and found nothing, unfortunately.
I have a vague recollection of dgs being a commercial graphics library
for S87, but I could be wrong. If you do not have any source code other
than the prg files you have already managed to compile, then I suspect
that you may have a bumpy road in front of you.
Maybe someone in the comp.lang.clipper newsgroup remembers what
dgs_util.lib and dor_util.lib are. That might help in your detective
work ... or maybe not. It is worth a shot, though.
Anyway, what you need to do is first of all to remove all the *.lib
references from the hbmk2 command line. That will stop the linker from
halting on the first .lib it encounters. Instead, you will get a list of
all the functions it tries to link but cannot find.
Post that list here if you want. Next, look for those references in the
source code to get an idea of what they are supposed to do. Then you
will have a better basis for understanding what is missing, what can be
replace with other things that already exist in Harbour and what you
might have to reinvent.
Regards,
Klas
mmj0426
the dgs and dor_util lib. I have a feeling this road is going to be
more than bumpy. Something tells me I am going to be in an accident!
LOL!
How I compiled in Summer 87 was by using a .bat file with this code:
clipper @confr -l
clipper co_main.prg -l -m
clipper co_index.prg -l -m
clipper co_rept.prg -m -l
clipper co_nod.prg -m -l
clipper co_sal.prg -m -l
clipper co_list.prg -m -l
clipper co_pend.prg -m -l
clipper co_proc.prg -m -l
plink86 @confr
This generates an object file for each .prg and and .exe named
Confr.exe.
When I compile in Harbour taking all libraries out, I get this:
C:\CONFR>hbmk2 -l -m co_main.prg co_index.prg co_rept.prg co_nod.prg
co_sal.prg
co_list.prg co_pend.prg co_proc.prg -oconfr.exe
Harbour 2.0.0 (Rev. 13372)
Generating C source output to 'co_main.c'... Done.
Compiling 'co_index.prg'...
Lines 1717, Functions/Procedures 1
Generating C source output to 'co_index.c'... Done.
Compiling 'co_rept.prg'...
Compiling 'co_nod.prg'...
Lines 3468, Functions/Procedures 10
Generating C source output to 'co_nod.c'... Done.
Compiling 'co_sal.prg'...
Lines 4106, Functions/Procedures 10
Generating C source output to 'co_sal.c'... Done.
Compiling 'co_list.prg'...
Lines 5454, Functions/Procedures 12
Generating C source output to 'co_list.c'... Done.
Compiling 'co_pend.prg'...
Lines 5564, Functions/Procedures 2
Generating C source output to 'co_pend.c'... Done.
Compiling 'co_proc.prg'...
Lines 6288, Functions/Procedures 14
co_main.o:co_main.c:(.data+0x78): undefined reference to
`HB_FUN_USE_DBFS'
co_main.o:co_main.c:(.data+0xb8): undefined reference to
`HB_FUN_VAR_INIT'
co_main.o:co_main.c:(.data+0x138): undefined reference to
`HB_FUN_BORDERS'
co_main.o:co_main.c:(.data+0x158): undefined reference to
`HB_FUN_YES_TO'
co_main.o:co_main.c:(.data+0x168): undefined reference to
`HB_FUN_SAV_SCRN'
co_main.o:co_main.c:(.data+0x188): undefined reference to
`HB_FUN_RST_SCRN'
co_main.o:co_main.c:(.data+0x268): undefined reference to
`HB_FUN_U_MENU'
co_main.o:co_main.c:(.data+0x2b8): undefined reference to
`HB_FUN_DISP_MSG'
co_main.o:co_main.c:(.data+0x308): undefined reference to
`HB_FUN_U_SCROLL'
co_main.o:co_main.c:(.data+0x338): undefined reference to
`HB_FUN_SCRL_MNU'
co_main.o:co_main.c:(.data+0x348): undefined reference to
`HB_FUN_SCRL_RET'
co_main.o:co_main.c:(.data+0x3a8): undefined reference to
`HB_FUN_DIS_SCRN'
co_main.o:co_main.c:(.data+0x468): undefined reference to
`HB_FUN_DISP_MSG2'
co_main.o:co_main.c:(.data+0x488): undefined reference to
`HB_FUN_U_READ'
co_main.o:co_main.c:(.data+0x4a8): undefined reference to
`HB_FUN_REC_APPEND'
co_main.o:co_main.c:(.data+0x4d8): undefined reference to
`HB_FUN_REC_LOCK'
co_main.o:co_main.c:(.data+0x5b8): undefined reference to
`HB_FUN_WRIT_REC'
co_main.o:co_main.c:(.data+0x5c8): undefined reference to
`HB_FUN_SCRL_TOS'
co_main.o:co_main.c:(.data+0x688): undefined reference to
`HB_FUN_READ_REC'
co_main.o:co_main.c:(.data+0x6b8): undefined reference to
`HB_FUN_SCRL_DRW'
co_main.o:co_main.c:(.data+0xdb8): undefined reference to
`HB_FUN_CLR_GETS'
co_main.o:co_main.c:(.data+0xdc8): undefined reference to
`HB_FUN_U_GET'
co_main.o:co_main.c:(.data+0xde8): undefined reference to
`HB_FUN_READ_SAY'
co_main.o:co_main.c:(.data+0x12c8): undefined reference to
`HB_FUN_USE_DBF'
co_main.o:co_main.c:(.data+0x12d8): undefined reference to
`HB_FUN_USE_NDX'
co_main.o:co_main.c:(.data+0x1458): undefined reference to
`HB_FUN_GET_KEYS'
co_main.o:co_main.c:(.data+0x14e8): undefined reference to
`HB_FUN_ZTRIM'
co_main.o:co_main.c:(.data+0x14f8): undefined reference to
`HB_FUN_CSTR'
co_index.o:co_index.c:(.data+0x48): undefined reference to
`HB_FUN_INDEX_DBF'
co_rept.o:co_rept.c:(.data+0x38): undefined reference to
`HB_FUN_BORDERS'
co_rept.o:co_rept.c:(.data+0x148): undefined reference to
`HB_FUN_DISP_MSG'
co_rept.o:co_rept.c:(.data+0x168): undefined reference to
`HB_FUN_U_MENU'
co_rept.o:co_rept.c:(.data+0x188): undefined reference to
`HB_FUN_SAV_SCRN'
co_rept.o:co_rept.c:(.data+0x1b8): undefined reference to
`HB_FUN_RST_SCRN'
co_rept.o:co_rept.c:(.data+0x2a8): undefined reference to
`HB_FUN_USE_DBFS'
co_rept.o:co_rept.c:(.data+0x338): undefined reference to
`HB_FUN_U_REP2'
co_rept.o:co_rept.c:(.data+0x3e8): undefined reference to
`HB_FUN_U_REP_PRN'
co_rept.o:co_rept.c:(.data+0x9c8): undefined reference to
`HB_FUN_U_SCROLL'
co_rept.o:co_rept.c:(.data+0xad8): undefined reference to
`HB_FUN_PRN_READY'
co_rept.o:co_rept.c:(.data+0xc08): undefined reference to
`HB_FUN_U_USERINFO'
co_nod.o:co_nod.c:(.data+0x78): undefined reference to
`HB_FUN_USE_DBFS'
co_nod.o:co_nod.c:(.data+0x88): undefined reference to
`HB_FUN_VAR_INIT'
co_nod.o:co_nod.c:(.data+0xf8): undefined reference to
`HB_FUN_BORDERS'
co_nod.o:co_nod.c:(.data+0x118): undefined reference to
`HB_FUN_YES_TO'
co_nod.o:co_nod.c:(.data+0x128): undefined reference to
`HB_FUN_SAV_SCRN'
co_nod.o:co_nod.c:(.data+0x148): undefined reference to
`HB_FUN_RST_SCRN'
co_nod.o:co_nod.c:(.data+0x218): undefined reference to
`HB_FUN_U_MENU'
co_nod.o:co_nod.c:(.data+0x268): undefined reference to
`HB_FUN_DISP_MSG'
co_nod.o:co_nod.c:(.data+0x2b8): undefined reference to
`HB_FUN_U_SCROLL'
co_nod.o:co_nod.c:(.data+0x2e8): undefined reference to
`HB_FUN_SCRL_MNU'
co_nod.o:co_nod.c:(.data+0x2f8): undefined reference to
`HB_FUN_SCRL_RET'
co_nod.o:co_nod.c:(.data+0x348): undefined reference to
`HB_FUN_DIS_SCRN'
co_nod.o:co_nod.c:(.data+0x3a8): undefined reference to
`HB_FUN_DISP_MSG2'
co_nod.o:co_nod.c:(.data+0x3c8): undefined reference to
`HB_FUN_U_READ'
co_nod.o:co_nod.c:(.data+0x3e8): undefined reference to
`HB_FUN_REC_APPEND'
co_nod.o:co_nod.c:(.data+0x418): undefined reference to
`HB_FUN_WRIT_REC'
co_nod.o:co_nod.c:(.data+0x428): undefined reference to
`HB_FUN_SCRL_TOS'
co_nod.o:co_nod.c:(.data+0x458): undefined reference to
`HB_FUN_REC_LOCK'
co_nod.o:co_nod.c:(.data+0x468): undefined reference to
`HB_FUN_READ_REC'
co_nod.o:co_nod.c:(.data+0x478): undefined reference to
`HB_FUN_SCRL_DRW'
co_nod.o:co_nod.c:(.data+0x618): undefined reference to
`HB_FUN_CLR_GETS'
co_nod.o:co_nod.c:(.data+0x628): undefined reference to `HB_FUN_U_GET'
co_nod.o:co_nod.c:(.data+0x6a8): undefined reference to
`HB_FUN_U_REP2'
co_nod.o:co_nod.c:(.data+0x748): undefined reference to
`HB_FUN_U_REP_PRN'
co_nod.o:co_nod.c:(.data+0x788): undefined reference to `HB_FUN_ZTRIM'
co_nod.o:co_nod.c:(.data+0x798): undefined reference to `HB_FUN_CSTR'
co_sal.o:co_sal.c:(.data+0x38): undefined reference to
`HB_FUN_BORDERS'
co_sal.o:co_sal.c:(.data+0xa8): undefined reference to
`HB_FUN_DISP_MSG'
co_sal.o:co_sal.c:(.data+0xc8): undefined reference to `HB_FUN_U_MENU'
co_sal.o:co_sal.c:(.data+0xe8): undefined reference to
`HB_FUN_SAV_SCRN'
co_sal.o:co_sal.c:(.data+0x118): undefined reference to
`HB_FUN_RST_SCRN'
co_sal.o:co_sal.c:(.data+0x178): undefined reference to
`HB_FUN_USE_DBFS'
co_sal.o:co_sal.c:(.data+0x188): undefined reference to
`HB_FUN_VAR_INIT'
co_sal.o:co_sal.c:(.data+0x1f8): undefined reference to
`HB_FUN_YES_TO'
co_sal.o:co_sal.c:(.data+0x338): undefined reference to
`HB_FUN_U_SCROLL'
co_sal.o:co_sal.c:(.data+0x368): undefined reference to
`HB_FUN_SCRL_MNU'
co_sal.o:co_sal.c:(.data+0x378): undefined reference to
`HB_FUN_SCRL_RET'
co_sal.o:co_sal.c:(.data+0x3b8): undefined reference to
`HB_FUN_DIS_SCRN'
co_sal.o:co_sal.c:(.data+0x3f8): undefined reference to
`HB_FUN_DISP_MSG2'
co_sal.o:co_sal.c:(.data+0x418): undefined reference to
`HB_FUN_U_READ'
co_sal.o:co_sal.c:(.data+0x428): undefined reference to
`HB_FUN_REC_APPEND'
co_sal.o:co_sal.c:(.data+0x458): undefined reference to
`HB_FUN_WRIT_REC'
co_sal.o:co_sal.c:(.data+0x468): undefined reference to
`HB_FUN_SCRL_TOS'
co_sal.o:co_sal.c:(.data+0x488): undefined reference to
`HB_FUN_REC_LOCK'
co_sal.o:co_sal.c:(.data+0x498): undefined reference to
`HB_FUN_READ_REC'
co_sal.o:co_sal.c:(.data+0x4b8): undefined reference to
`HB_FUN_SCRL_DRW'
co_sal.o:co_sal.c:(.data+0x6b8): undefined reference to
`HB_FUN_CLR_GETS'
co_sal.o:co_sal.c:(.data+0x6c8): undefined reference to `HB_FUN_U_GET'
co_sal.o:co_sal.c:(.data+0x748): undefined reference to `HB_FUN_ZTRIM'
co_sal.o:co_sal.c:(.data+0x758): undefined reference to `HB_FUN_CSTR'
co_list.o:co_list.c:(.data+0x58): undefined reference to
`HB_FUN_BORDERS'
co_list.o:co_list.c:(.data+0x128): undefined reference to
`HB_FUN_DISP_MSG'
co_list.o:co_list.c:(.data+0x148): undefined reference to
`HB_FUN_U_MENU'
co_list.o:co_list.c:(.data+0x168): undefined reference to
`HB_FUN_SAV_SCRN'
co_list.o:co_list.c:(.data+0x198): undefined reference to
`HB_FUN_RST_SCRN'
co_list.o:co_list.c:(.data+0x278): undefined reference to
`HB_FUN_USE_DBFS'
co_list.o:co_list.c:(.data+0x348): undefined reference to
`HB_FUN_U_REP2'
co_list.o:co_list.c:(.data+0x408): undefined reference to
`HB_FUN_U_REP_PRN'
co_list.o:co_list.c:(.data+0x6f8): undefined reference to
`HB_FUN_PRN_READY'
co_list.o:co_list.c:(.data+0x808): undefined reference to
`HB_FUN_USE_DBF'
co_list.o:co_list.c:(.data+0x8e8): undefined reference to
`HB_FUN_REC_APPEND'
co_pend.o:co_pend.c:(.data+0x88): undefined reference to
`HB_FUN_USE_DBFS'
co_pend.o:co_pend.c:(.data+0x98): undefined reference to
`HB_FUN_BORDERS'
co_pend.o:co_pend.c:(.data+0xa8): undefined reference to
`HB_FUN_DISP_MSG'
co_pend.o:co_pend.c:(.data+0x238): undefined reference to
`HB_FUN_U_REP2'
co_pend.o:co_pend.c:(.data+0x308): undefined reference to
`HB_FUN_U_REP_PRN'
co_proc.o:co_proc.c:(.data+0x108): undefined reference to
`HB_FUN_USE_DBF'
co_proc.o:co_proc.c:(.data+0x118): undefined reference to
`HB_FUN_USE_NDX'
co_proc.o:co_proc.c:(.data+0x128): undefined reference to
`HB_FUN_REC_APPEND'
co_proc.o:co_proc.c:(.data+0x288): undefined reference to
`HB_FUN_SAV_SCRN'
co_proc.o:co_proc.c:(.data+0x328): undefined reference to
`HB_FUN_DISP_MSG'
co_proc.o:co_proc.c:(.data+0x378): undefined reference to
`HB_FUN_WRITE_LINE'
co_proc.o:co_proc.c:(.data+0x4f8): undefined reference to
`HB_FUN_RST_SCRN'
co_proc.o:co_proc.c:(.data+0x5d8): undefined reference to
`HB_FUN_U_SCROLL'
hbmk2: Error: Running linker. 1
c:\hrbour\comp\mingw\bin\gcc.exe co_main.o co_index.o co_rept.o
co_nod.o co_sal.
group -lh
bextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -
lgtstd -lgt
lkernel32 -l
user32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -
lshell32 -l
uuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -
lwininet -lhbp
I know that is a mess to read. Now, HB_FUN???? I understand HB is
probably for Harbour, but FUN?? I'm not having any right now. LOL
Thanks for helping and I want to research the dgs_util and dor_util
lib. I'm thinking the original programmer created these but is there
a way to open these libraries and see what is coded in them? I've
tried to download a few programs that are supposed to open .lib files
but got an error when trying to download them. My company may have
blocked these? I don't know.
Thank you so much for the help!! Off to research now!!
mmj0426
overlay, extend, dor_util and dgs_util were stored in the system's
working directory and so was Plink.exe.
On Jun 23, 9:52 am, mmj0426 <mmj0...@aol.com> wrote:
> No, the original programmer is long gone. I will do more research on
> the dgs and dor_util lib. I have a feeling this road is going to be
> more than bumpy. Something tells me I am going to be in an accident!
> LOL!
>
> How I compiled in Summer 87 was by using a .bat file with this code:
>
> clipper @confr -l
> clipper co_main.prg -l -m
> clipper co_index.prg -l -m
> clipper co_rept.prg -m -l
> clipper co_nod.prg -m -l
> clipper co_sal.prg -m -l
> clipper co_list.prg -m -l
> clipper co_pend.prg -m -l
> clipper co_proc.prg -m -l
> plink86 @confr
>
> This generates an object file for each .prg and and .exe named
> Confr.exe.
>
> When I compile in Harbour taking all libraries out, I get this:
>
> C:\CONFR>hbmk2 -l -m co_main.prg co_index.prg co_rept.prg co_nod.prg
> co_sal.prg
> co_list.prg co_pend.prg co_proc.prg -oconfr.exe
> hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
> Harbour 2.0.0 (Rev. 13372)
>
> read more »
Angel Pais
reverse ingeneer them.
Most probably the old programmer took them with him.
I can deduct this software is using ndx indexes.
They are very old and I don't know if Harbour support them.
Maybe someone can jump on the topic.
HTH
Angel
>
> leer más »
Klas Engwall
> No, the original programmer is long gone. I will do more research on
> the dgs and dor_util lib. I have a feeling this road is going to be
> more than bumpy. Something tells me I am going to be in an accident!
> LOL!
So fasten your seat belt :-)
> How I compiled in Summer 87 was by using a .bat file with this code:
>
> clipper @confr -l
> clipper co_main.prg -l -m
> clipper co_index.prg -l -m
> clipper co_rept.prg -m -l
> clipper co_nod.prg -m -l
> clipper co_sal.prg -m -l
> clipper co_list.prg -m -l
> clipper co_pend.prg -m -l
> clipper co_proc.prg -m -l
> plink86 @confr
>
> This generates an object file for each .prg and and .exe named
> Confr.exe.
OK, no big secrets there
> When I compile in Harbour taking all libraries out, I get this:
I took all your undefined references, removed the distractions, sorted
the function names and removed the duplicates. The list is included
below. 34 function names were left. If that is good or bad depends on
whether you are an optimistic or a pessimistic person. :-)
> I know that is a mess to read. Now, HB_FUN???? I understand HB is
> probably for Harbour, but FUN?? I'm not having any right now. LOL
For the moment, all you need to know about "HB_FUN_" is that it is how
Harbour refers to functions. It is the part after the second underscore
that is interesting.
> Thanks for helping and I want to research the dgs_util and dor_util
> lib. I'm thinking the original programmer created these but is there
> a way to open these libraries and see what is coded in them? I've
> tried to download a few programs that are supposed to open .lib files
> but got an error when trying to download them. My company may have
> blocked these? I don't know.
There are several decompilers for Clipper code that were quite popular
back then. And as long as the application's exe file is not compressed
(which Plink86 did _not_ do), decompiling should be possible. I friend
of mine who still jumps in sometimes in the comp.lang.clipper newsgroup
used to do that kind of thing for a living. I don't know about general
lib file decompilers, though. I suppose they will be of no help with
pcode (And I think that all your missing functions are pcode). But
decompiling the exe file might be useful.
Here are your unresolved functions:
BORDERS
CLR_GETS
CSTR
DISP_MSG
DISP_MSG2
DIS_SCRN
GET_KEYS
INDEX_DBF
PRN_READY
READ_REC
READ_SAY
REC_APPEND
REC_LOCK
RST_SCRN
SAV_SCRN
SCRL_DRW
SCRL_MNU
SCRL_RET
SCRL_TOS
USE_DBF
USE_DBFS
USE_NDX
U_GET
U_MENU
U_READ
U_REP2
U_REP_PRN
U_SCROLL
U_USERINFO
VAR_INIT
WRITE_LINE
WRIT_REC
YES_TO
ZTRIM
REC_LOCK, for example, was included in extend.lib. It is a wrapper for
the USE command that retries the USE several times if the first attempt
fails. It is easily replaced with a few lines of code (or a copy of the
source code that was actually included with Clipper).
My guess is that USE_DBF, USE_DBFS and USE_NDX do similar things (the
latter with index files). The arguments in the function calls will
probably give an indication. BTW, Angel noted that the application
probably uses .NDX indexes. Those are not supported by Harbour, but you
can switch to .NTX indexes quite easily unless you have to continue
running the old Clipper exe on the same data files as the converted
Harbour app ... in which case you will be in trouble.
SAV_SCRN and RST_SCRN should be easily replaced with SaveScreen() and
RestScreen(). CLR_GETS probably does the same thing as the CLEAR GETS
command, but with some kind of twist. PRN_READY checks the printer
status and is of limited use under a modern OS. CSTR probably centers a
string of text on the screen, ZTRIM might be a trimming function for
redundant zeros when a number is converted to a string. And so on ...
I suspect that the trickiest parts to reinvent are the U_* functions,
which possibly belong to a subsystem that is first initialized with the
VAR_INIT function.
If you are unable to find the original source code for the 34 functions,
then investigate the calling code in the CO_*.PRG files to get an idea
of what the functions do, and try to reinvent them.
Good luck with the bumps :-)
Regards,
Klas
mmj0426
directories at work and so far I have found nothing on dor_util but I
found a dgs_util file with no extension. Here is just a sample of
what is inside:
SCROLL.OBJ: u_skip_b.prg scrl_fnd.prg
clipper @scroll -l
lib dgs_util -+scroll;
REPORT.OBJ: report.clp u_report.prg u_print2.prg u_rep2.prg
lj_setup.prg printer.prg psq_file.prg
clipper @report -l
lib dgs_util -+report;
KEYNAMES.OBJ: keynames.prg
clipper keynames -m -l
lib dgs_util -+keynames;
SCREEN.OBJ: screen.prg
clipper screen -m -l
lib dgs_util -+screen;
So.....I'm thinking the programmer did something with this file and
made it into a library???? I'm scared because there are quite a bit
of .prgs listed in this file and this stuff mostly means nothing to
me. I've got the general idea but that's it.
I'm still digging for dor_util. These searches take forever because
our drives are loaded with folders, files and goodies.
>
> read more »- Hide quoted text -
mmj0426
does use .ndx files but I only see 2. It also uses 12 .ntx files. It
could be possible that the .ndx files are not being used anymore but I
am not sure and will look into the programs. Of the .prgs that are
listed in that dgs_util file, I found SAV_SCR and a couple of others
within those programs. I'm hoping I can still use these that are
already out there. I guess there is no way to use the existing
dgs_util library??? I will be out of the office until Monday so I
will do more research then. Again, thank you all for the help and
have a great weekend!!
Klas Engwall
> directories at work and so far I have found nothing on dor_util but I
> found a dgs_util file with no extension. Here is just a sample of
> what is inside:
>
> SCROLL.OBJ: u_skip_b.prg scrl_fnd.prg
> clipper @scroll -l
> lib dgs_util -+scroll;
>
> REPORT.OBJ: report.clp u_report.prg u_print2.prg u_rep2.prg
> lj_setup.prg printer.prg psq_file.prg
> clipper @report -l
> lib dgs_util -+report;
>
> KEYNAMES.OBJ: keynames.prg
> clipper keynames -m -l
> lib dgs_util -+keynames;
>
> SCREEN.OBJ: screen.prg
> clipper screen -m -l
> lib dgs_util -+screen;
>
> So.....I'm thinking the programmer did something with this file and
> made it into a library???? I'm scared because there are quite a bit
> of .prgs listed in this file and this stuff mostly means nothing to
> me. I've got the general idea but that's it.
So, the dgs_util file with no extension is his makefile for a bunch of
utilities that he had prepared separately. And that indicates that the
project could be a lot bigger than we have been aware of so far (and
also that all or a lot of the missing stuff once was available in source
code).
Here you get the file names of a number of additional prg files. It
might help in your chase for the missing parts. report.clp is a list of
additional prg files that were compiled into report.obj together with
u_report.prg and the other ones on that line. Or maybe he just means
that the clp file should be included in the check for updated
dependencies but that the list included in it is the same list of prg
files mentioned after report.clp. I have used clp files a lot, but his
use of it on this line puzzles me. When he says "clipper @report -l" he
tells Clipper to compile the prg files listed in report.clp (that is
what the @ means), but he drops the other file names listed in the
dependency check.
> I'm still digging for dor_util. These searches take forever because
> our drives are loaded with folders, files and goodies.
What you need now is a search for *.prg everywhere. If you find any, you
might find more useable info at the same places. If you find nothing,
the decompile route looks more and more like the way to go. Some of the
missing 34 functions might be entry points to entire subsystems with
tons of code. This sounds like fun :-)
Regards,
Klas
Klas Engwall
> does use .ndx files but I only see 2. It also uses 12 .ntx files. It
> could be possible that the .ndx files are not being used anymore but I
> am not sure and will look into the programs.
Using both ndx and ntx files in the same program is rare and requires
extra coding (I don't even remember how that was done in S87 and am
unable to find it in the Norton Guide). So there is a higher probability
that he switched from ndx to ntx indexes at one point, abandoning the
two files you found, and leaving USE_NDX.PRG as a slightly misleading
name of the source code file. No big deal, if that is what happened.
> Of the .prgs that are
> listed in that dgs_util file, I found SAV_SCR and a couple of others
> within those programs. I'm hoping I can still use these that are
> already out there. I guess there is no way to use the existing
> dgs_util library???
No, the internal format is different from what Harbour needs.
Regards,
Klas
mmj0426
Ok, I've finally got back to doing this today and WOW.....what an
adventure!!
I searched for all of those functions that are missing and found that
most of them are stored in 11 different programs. There are 7 that
are actually programs and not a function stored in a program......if
that makes sense because I'm not sure I'm explaining this right since
I'm even more lost!!
Klas, I found several .CLP files that had that same exact list that
you sorted out for me!!! No more and no less and all sorted in alpha
order like you had it. What could that possibly mean?
After researching inside my programs, it seems they are not using
the .ndx files but i'm not positive.
Angel, I will research how to do an .hbp file. I know I am doing it
the hard way now but it's more to help me understand for the
moment.......even though the .hbp file makes more sense.
I'm thinking I need to take all the functions and put it into one .prg
file. The remaining 7 programs are very small and I believe I can use
the code to make functions out of them and add it to the one
program??? I think it would be too many programs to add to my working
directory. I've got a lot of work to do. I just hope that this is
all doable.
Tim Stone
http://www.the-oasis.net/pbmake01.htm
Clipper worked best with smaller files. The .clp allowed you to combine
several .prg's together. It was a compiler script file.
I think the Oasis article above will help a lot in understanding what you
are seeing.
Tim
mmj0426
looking forward to it. I was just asked to take care of something
else for the next 2 days.
On Jun 28, 4:08 pm, "Tim Stone" <timst...@masterlinksoftware.com>
wrote:
Klas Engwall
> Thank you all for the information!!
You're welcome. It looks like you are making progress. That's great.
> Ok, I've finally got back to doing this today and WOW.....what an
> adventure!!
>
> I searched for all of those functions that are missing and found that
> most of them are stored in 11 different programs. There are 7 that
> are actually programs and not a function stored in a program......if
> that makes sense because I'm not sure I'm explaining this right since
> I'm even more lost!!
Yes, it makes sense. Functions can exist in separate _prg files_ for
each one (let's call them that and reserve the word "program" for the
entire executable (exe file), or there can be several of them in the
same prg file. In the latter case they can be related to each other and
one of them is probably the entry point to all the others, or they can
be separate utility functions that are just collected in one single prg
file for convenience. Or both.
In the old S87 coding style, a function does not have to have the
keyword "function" or "procedure" at the top, provided that the name of
the prg file can be used to find the function instead. If you change the
name of the prg file, or if you stuff a number of those functions in one
single prg file (as you mention below), then you have to provide the
function or procedure name, with that keyword, at the top of each
function. BTW, I use "function" and "procedure" side by side here. Which
to use depends on the code that follows. Functions return a value
(RETURN "abc", for example) while procedures do not (just RETURN on a
line for itself), in case that is also new for you.
What is not entirely clear to me at this point is if you have managed to
find all the missing parts or just some of them. But you are definitely
a big step further now compared to last week.
> Klas, I found several .CLP files that had that same exact list that
> you sorted out for me!!! No more and no less and all sorted in alpha
> order like you had it. What could that possibly mean?
The list I sorted was the list of missing function or procedure names
that the linker had problems with. What you find in a clp file is a list
of names of prg files (with or without the prg extension). So with "no
more and no less" identical lists, we know that the functions the linker
complained about (my list) are all in prg files (listed in the clp file)
with identical names. If you also find the 34 (?) prg files of those
names, then you are in business. The alphabetical sorting is just
coincidential.
> After researching inside my programs, it seems they are not using
> the .ndx files but i'm not positive.
As I mentioned, using ntx and ndx in the same application is very rare,
so I think we can put that subject to the side for now.
> Angel, I will research how to do an .hbp file. I know I am doing it
> the hard way now but it's more to help me understand for the
> moment.......even though the .hbp file makes more sense.
Allow me :-). Here is a simple example. Let's call it myapp.hbp. Your
command line to compile the application will then be "hbmk2 myapp.hbp"
(without the quotes, of course).
#----------------------
#
# myapp.hbp (this is just a comment)
#
# output file
-omyapp
# source files
myprg.prg
..\neighbourdirectory\someother.prg
#----------------------
It says that the output file name will be myapp.exe, and two prg files
are needed to build it: myprg.prg in the current directory and
someother.prg in another directory. I will return to the latter in the
next section, but all you have to do here is to list all the prg files
you need to include, similar to what the clp file did. You don't even
have to specify the .prg extension, it works anyway. Include all the
eight or ten prg files you specified in your previous attempts plus the
list from the clp file.
> I'm thinking I need to take all the functions and put it into one .prg
> file. The remaining 7 programs are very small and I believe I can use
> the code to make functions out of them and add it to the one
> program???
Sure, you can do that. That will force you to add missing (if any)
procedure or function names at the beginning of each function (and that
will be a good programming practice). But it is not entirely necessary.
You can still use the original prg files and add a compiler switch to
the hbp file if necessary. Or (I would probably do this) you can add the
missing function/procedure name before the actual code of each existing
file but otherwise keep them intact.
> I think it would be too many programs to add to my working
> directory. I've got a lot of work to do. I just hope that this is
> all doable.
Don't worry about that. You can have hundreds of prg files in the
working directory if you want. Just list them all in the hbp file. Or,
if you want to preserve the original programmer's structure, you can put
certain files in other directories and refer to them in the hbp file
like on the last line of my example. If there are other projects that
you plan to revive after this one, and those also need the prg files
that were originally missing here, then it could be a good idea to keep
those separated from the ones that specifically belong to this project,
say, in a neighboring directory called "commonstuff" or something like that.
In the next lesson :-) we can talk about creating new lib files (or "a"
files, depending on your C compiler's conventions) just like the
original programmer did, and then include those lib file names in the
hbp file. That will probably save some time when you recompile your
project. On the other hand, the compile will be ready long before you
are back from the coffee machine, anyway :-)
Regard,
Klas
mmj0426
add) I will get started. This may take me a while! LOL! Hopefully,
I won't have TOO MANY more questions but I know I will have some later
on.
As far as the .hbp file, it seems like it works similarly like a .bat
file if I'm understanding right.
Ok, so off I go!! Thanks and have a great weekend!!
Klas Engwall
> Thank you Klas! With this information (explained very well I might
> add) I will get started. This may take me a while! LOL!
The LOL is a big step forward from your comment about "HB_FUN_" and not
having any just one week ago :-)
> Hopefully,I won't have TOO MANY more questions but I know I will have
> some later on.
We'll all be here waiting for your return :-)
> As far as the .hbp file, it seems like it works similarly like a .bat
> file if I'm understanding right.
No, a hbp file is a project file and an option file where you tell the
project manager hbmk2.exe how you want it to handle the project, what
files should be includes, what flags to forward to the compiler, etc.
You use the name of the hbp file as argument to hbmk2 instead of listing
all the file names, compiler flags and other options after "hbmk2" on
the commandline. For example, some things that can be included in the
hbp file are ...
-ofilename is the name of the exe file you want hbmk2 to create
-lfilename is a name of a library file you want hbmk2 to include
in the link
-w2 is one of the available warning levels (a "medium"
one) that makes harbour.exe report certain things in
your code that are not really errors but you should
probably improve anyway
-workdir=dirname tells Harbour to put temporary files in the directory
specified instead of under Documents and Settings
firstfile
secondfile
thirdfile are three (in this case) prg files you want to include
in the compile
... just to mention a few picked at random from a list of options as
long as your arm. If you put all these things in, say, myproject.hbp,
then you invoke hbmk2 on the commandline with "hbmk2 myproject.hbp"
(without the quotes) just like you can invoke Notepad with "notepad
mytextfile.txt". Then you can of course take it one step further and put
"hbmk2 myproject.hbp" (without the quotes, again) in a batch file called
x.bat, for example, and run the whole shebang by just typing an x on the
commandline. A much simpler and quicker solution than the original
commandline in your first post, don't you agree?
You can even put the names of a bunch of hbp files for different
sub-projects into one hbp file for the main project and then give hbmk2
the name of the main hbp file at one compile session and the name of one
of the sub-project hbp files at another compile session if it suits your
needs at that moment. There are a zillion different ways you can handle
your projects.
I think we will stop here for today and take the hbc files another time :-)
Regards,
Klas
mmj0426
Tim, thanks for the site info in reference to the .clp files. It was
a good one and helped me understand them and even more. It seems I
don't need them in my conversion but now I know why they were
there.
After much research, it seems my system uses the .ntx files,
not .ndx. I think that's good news?
I found most of those functions but also found that as I added them,
some functions called for even more needed functions. Long story
short, I found all but four. I went into the programs that called
these and commented them out for now until I do more searching. They
didn't seem to be that highly needed at the moment.
This system is larger than I thought. I put all of the smaller
functions I found into one program called "Functions.prg" and the
larger functions that were actually programs I added to my working
directory. This is what my .hbp file looks like:
#----------------------
#
# confr.hbp
#
#----------------------
# output file
-oconfr
# source files
confr.prg
co_index.prg
co_rept.prg
co_nod.prg
co_sal.prg
co_list.prg
co_pend.prg
co_proc.prg
get.prg
menu.prg
security.prg
u_rep2.prg
borders.prg
disp_msg.prg
std_init.prg
std_clrs.prg
std_msgs.prg
std_sets.prg
get_keys.prg
keynames.prg
scrl_drw.prg
scrl_ret.prg
scrl_tos.prg
u_scroll.prg
u_skip_b.prg
u_skip.prg
lj_setup.prg
menud.prg
whoami.prg
------------------------------------------------------------
Wow!! Look at all those programs! Then I compiled using "hbmk2
confr.hbp" and the compiler switch -m. This is an example of what I
got for each program:
hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
Harbour 2.0.0 (Rev. 13372)
Compiling 'co_main.prg'...
Lines 1797, Functions/Procedures 28
I went into confr.exe to test. The system came up but anything I tried
to do that needed to access the tables (which are MS Access DBs) would
just freeze when I hit enter and then the system would close when I
hit enter again. So.......I'm thinking I need those libraries now
Klas? Or is there something else?
Now, when I removed the compiler switch -m I got A LOT of these:
co_sal.o:co_sal.c:(.text+0x1a0): multiple definition of
`HB_FUN_V_TAX_TYPE'
confr.o:confr.c:(.text+0xc0): first defined here
Should I be using the -m or not??
Thanks in advance!
Klas Engwall
> I'm back!!!!!! LOL!
:-)
> After much research, it seems my system uses the .ntx files,
> not .ndx. I think that's good news?
Yes
> I found most of those functions but also found that as I added them,
> some functions called for even more needed functions. Long story
> short, I found all but four. I went into the programs that called
> these and commented them out for now until I do more searching. They
> didn't seem to be that highly needed at the moment.
OK
> This system is larger than I thought. I put all of the smaller
> functions I found into one program called "Functions.prg" and the
> larger functions that were actually programs I added to my working
> directory. This is what my .hbp file looks like:
{...}
> ------------------------------------------------------------
> Wow!! Look at all those programs!
Only thirtyone prg files? :-)
> Then I compiled using "hbmk2
> confr.hbp" and the compiler switch -m. This is an example of what I
> got for each program:
>
> hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
> Harbour 2.0.0 (Rev. 13372)
> Copyright (c) 1999-2010, http://www.harbour-project.org/
> Compiling 'co_main.prg'...
> Lines 1797, Functions/Procedures 28
> Generating C source output to 'co_main.c'... Done.
So far so good
> The programs compiled with no errors. I was just oh so happy. Then,
> I went into confr.exe to test. The system came up but anything I tried
> to do that needed to access the tables (which are MS Access DBs) would
> just freeze when I hit enter and then the system would close when I
> hit enter again. So.......I'm thinking I need those libraries now
> Klas? Or is there something else?
Hold on for a minute! Where did those MS Access DBs come from? This used
to be a Clipper S87 application (and, additionally, one that the
original programmer moved from ndx indexes to ntx indexes, as we have
established before). S87 could not handle MS Access DBs. So there is
something funny going on here. To fit into the general picture those
files should be standard Clipper dbf files. Are you sure they are not?
About the closing after hitting <Enter>, are you running the application
from the commandline or by double-clicking it in a window? In the first
case you should be able to see some kind of error message when it dies.
That would be useful for analysis of your problem. The application
probably does not produce an error log, but that would be a useful addition.
> Now, when I removed the compiler switch -m I got A LOT of these:
>
> co_sal.o:co_sal.c:(.text+0x1a0): multiple definition of
> `HB_FUN_V_TAX_TYPE'
> confr.o:confr.c:(.text+0xc0): first defined here
>
> Should I be using the -m or not??
Well, the -m switch is the way you tell the compiler to only compile
each module (prg file) separately and not include any other modules at
the same time. Apparently, the structure of your prg files is such that
other modules are included, again and again, in the ones you compile. I
suspect that you have lines saying "set procedure to <something>" in the
code. As long as that is the case, you should tell the compiler not to
include those other modules/procedures/prg files by supplying the -m switch.
"set procedure to" was the way that dBase could know how to jump from
one prg file to the next in the program flow, and Clipper inherited that
behaviour as it was originally targeted at being a dBase compiler. But
Clipper also introduced the more modern way to handle the program flow
by having a procedure or function name at the top or the "other" prg
file (instead of relying on the file name for finding where to go next)
and by making a call to that function from the first prg file instead of
the "set procedure to" line.
So keep -m for now, and return to the question of cleaning up when you
have solved the immediate show stoppers. First we need to know why the
application freezes.
Regards,
Klas
matt johnson
Put altd() function in code before crash point, step thru line by line. Remember to compile in debugger support with -g. Good luck
--- On Tue, 7/12/11, Klas Engwall <har...@engwall.com> wrote:
mmj0426
Access. Maybe thinking of the other project. Sorry for the
confusion.
I should have explained the "closing after hitting <enter>" part
better. When my application comes up, it shows a menu where you can
either select to browse all cases (rows), select to look at reports
(which are not stored in a db), re-index the dbs or pack them. All
works except when I select to browse all cases which should access the
db and show all the cases stored in the db. When I try to make that
selection, instead of showing me all the cases, it does nothing. The
system will not allow me to try to select anything else or get out.
It just sits at that selection and no error message shows. Not
knowing what to do, I hit <enter> again and that is when the whole
application just closes down.
Klas Engwall
> Hi Klas, I'm sorry. They are .dbf. I don't know what made me say
> Access. Maybe thinking of the other project. Sorry for the
> confusion.
OK, no problem.
> I should have explained the "closing after hitting<enter>" part
> better. When my application comes up, it shows a menu where you can
> either select to browse all cases (rows), select to look at reports
> (which are not stored in a db), re-index the dbs or pack them. All
> works except when I select to browse all cases which should access the
> db and show all the cases stored in the db. When I try to make that
> selection, instead of showing me all the cases, it does nothing. The
> system will not allow me to try to select anything else or get out.
> It just sits at that selection and no error message shows. Not
> knowing what to do, I hit<enter> again and that is when the whole
> application just closes down.
Yes, I have no problem with that. What I am interested in is whether you
are still in the console window when that happens and if there are any
error messages from the application left in the window. Something like:
Error <type>/<number> <description>
Called from ...
Called from ...
It is very seldom that an application just vanishes without any trace.
But you have to be in a window that does not close itself when the
application dies. That is why I asked if you were running it from the
commandline (by typing the exe name) or double-clicking the application
icon.
Regards,
Klas
mmj0426
I have yet to compile in Clipper and have no clue where to start. I
can research that now and so I can find out where this actually
happens but apparently I need something more so my application can
compile correctly.
Hi Klas, no, I'm not still in the console window when that happens and
this occurs when running it by double clicking the application.
But.......I tried running it from the commandline and got this:
C:\Confr in Harbour>hbmk2 confr -run
hbmk2: Processing configuration: c:\hrbour\bin\hbmk.cfg
Harbour 2.0.0 (Rev. 13372)
Copyright (c) 1999-2010, http://www.harbour-project.org/
Compiling 'CO_PROC.prg'...
Compiling 'STD_INIT.prg'...
Cannot open SEC_CHEK.prg, assumed external
Compiling 'BORDERS.prg'...
Compiling 'DISP_MSG.prg'...
Compiling 'CO_REPT.prg'...
Compiling 'CO_INDEX.prg'...
Compiling 'STD_SETS.prg'...
Compiling 'STD_CLRS.prg'...
Compiling 'STD_MSGS.prg'...
Compiling 'KEYNAMES.prg'...
Compiling 'LJ_SETUP.prg'...
Compiling 'SCRL_TOS.prg'...
Cannot open U_GET.prg, assumed external
Cannot open READ_SAY.prg, assumed external
Compiling 'CO_PEND.prg'...
Compiling 'CO_NOD.prg'...
Compiling 'CO_SAL.prg'...
Compiling 'U_SKIP.prg'...
Compiling 'U_SKIP_B.prg'...
Lines 7901, Functions/Procedures 133
Generating C source output to 'confr.c'... Done.
confr.o:confr.c:(.data+0x118): undefined reference to
`HB_FUN_GET_USERID'
confr.o:confr.c:(.data+0x138): undefined reference to
`HB_FUN_U_ACCESS'
confr.o:confr.c:(.data+0x158): undefined reference to `HB_FUN_DOR_LOG'
confr.o:confr.c:(.data+0x168): undefined reference to
`HB_FUN_SEC_CHEK'
confr.o:confr.c:(.data+0x248): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x268): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x298): undefined reference to `HB_FUN_YES_TO'
confr.o:confr.c:(.data+0x2f8): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x308): undefined reference to
`HB_FUN_PACK_DBFS'
confr.o:confr.c:(.data+0x328): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x418): undefined reference to `HB_FUN_USE_DBF'
confr.o:confr.c:(.data+0x428): undefined reference to `HB_FUN_USE_NDX'
confr.o:confr.c:(.data+0x438): undefined reference to
`HB_FUN_REC_APPEND'
confr.o:confr.c:(.data+0x598): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x678): undefined reference to
`HB_FUN_WRITE_LINE'
confr.o:confr.c:(.data+0x7f8): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0xe58): undefined reference to
`HB_FUN_CLR_FNAME'
confr.o:confr.c:(.data+0xe68): undefined reference to
`HB_FUN_LOAD_CLRS'
confr.o:confr.c:(.data+0x1078): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x10b8): undefined reference to
`HB_FUN_VAR_INIT'
confr.o:confr.c:(.data+0x1148): undefined reference to `HB_FUN_YES_TO'
confr.o:confr.c:(.data+0x1158): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x1178): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x1248): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x1318): undefined reference to
`HB_FUN_SCRL_MNU'
confr.o:confr.c:(.data+0x1388): undefined reference to
`HB_FUN_DIS_SCRN'
confr.o:confr.c:(.data+0x1438): undefined reference to `HB_FUN_U_READ'
confr.o:confr.c:(.data+0x1458): undefined reference to
`HB_FUN_REC_APPEND'
confr.o:confr.c:(.data+0x1488): undefined reference to
`HB_FUN_REC_LOCK'
confr.o:confr.c:(.data+0x1528): undefined reference to
`HB_FUN_WRIT_REC'
confr.o:confr.c:(.data+0x15c8): undefined reference to
`HB_FUN_READ_REC'
confr.o:confr.c:(.data+0x1b38): undefined reference to
`HB_FUN_CLR_GETS'
confr.o:confr.c:(.data+0x1b48): undefined reference to `HB_FUN_U_GET'
confr.o:confr.c:(.data+0x1b68): undefined reference to
`HB_FUN_READ_SAY'
confr.o:confr.c:(.data+0x2018): undefined reference to
`HB_FUN_USE_DBF'
confr.o:confr.c:(.data+0x2028): undefined reference to
`HB_FUN_USE_NDX'
confr.o:confr.c:(.data+0x2218): undefined reference to `HB_FUN_ZTRIM'
confr.o:confr.c:(.data+0x2228): undefined reference to `HB_FUN_CSTR'
confr.o:confr.c:(.data+0x2358): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x2378): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x2388): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x2448): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x2ad8): undefined reference to
`HB_FUN_PRN_READY'
confr.o:confr.c:(.data+0x2af8): undefined reference to
`HB_FUN_U_USERINFO'
confr.o:confr.c:(.data+0x2b28): undefined reference to
`HB_FUN_INDEX_DBF'
confr.o:confr.c:(.data+0x2f28): undefined reference to
`HB_FUN_U_INKEY'
confr.o:confr.c:(.data+0x2fb8): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x2fd8): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x3768): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x3788): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x3798): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x3838): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x3bf8): undefined reference to
`HB_FUN_PRN_READY'
confr.o:confr.c:(.data+0x3cb8): undefined reference to
`HB_FUN_USE_DBF'
confr.o:confr.c:(.data+0x3d68): undefined reference to
`HB_FUN_REC_APPEND'
confr.o:confr.c:(.data+0x3f38): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x4148): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x4158): undefined reference to
`HB_FUN_VAR_INIT'
confr.o:confr.c:(.data+0x41b8): undefined reference to `HB_FUN_YES_TO'
confr.o:confr.c:(.data+0x41c8): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x41e8): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x42a8): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x4318): undefined reference to
`HB_FUN_SCRL_MNU'
confr.o:confr.c:(.data+0x4378): undefined reference to
`HB_FUN_DIS_SCRN'
confr.o:confr.c:(.data+0x43d8): undefined reference to `HB_FUN_U_READ'
confr.o:confr.c:(.data+0x43f8): undefined reference to
`HB_FUN_REC_APPEND'
confr.o:confr.c:(.data+0x4428): undefined reference to
`HB_FUN_WRIT_REC'
confr.o:confr.c:(.data+0x4458): undefined reference to
`HB_FUN_REC_LOCK'
confr.o:confr.c:(.data+0x4468): undefined reference to
`HB_FUN_READ_REC'
confr.o:confr.c:(.data+0x45b8): undefined reference to
`HB_FUN_CLR_GETS'
confr.o:confr.c:(.data+0x45c8): undefined reference to `HB_FUN_U_GET'
confr.o:confr.c:(.data+0x46a8): undefined reference to `HB_FUN_ZTRIM'
confr.o:confr.c:(.data+0x46b8): undefined reference to `HB_FUN_CSTR'
confr.o:confr.c:(.data+0x4728): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x4738): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x4748): undefined reference to
`HB_FUN_RST_SCRN'
confr.o:confr.c:(.data+0x4788): undefined reference to
`HB_FUN_USE_DBFS'
confr.o:confr.c:(.data+0x4798): undefined reference to
`HB_FUN_VAR_INIT'
confr.o:confr.c:(.data+0x47d8): undefined reference to `HB_FUN_YES_TO'
confr.o:confr.c:(.data+0x48e8): undefined reference to
`HB_FUN_SCRL_MNU'
confr.o:confr.c:(.data+0x4938): undefined reference to
`HB_FUN_DIS_SCRN'
confr.o:confr.c:(.data+0x4978): undefined reference to `HB_FUN_U_READ'
confr.o:confr.c:(.data+0x4988): undefined reference to
`HB_FUN_REC_APPEND'
confr.o:confr.c:(.data+0x49b8): undefined reference to
`HB_FUN_WRIT_REC'
confr.o:confr.c:(.data+0x49e8): undefined reference to
`HB_FUN_REC_LOCK'
confr.o:confr.c:(.data+0x49f8): undefined reference to
`HB_FUN_READ_REC'
confr.o:confr.c:(.data+0x4a98): undefined reference to
`HB_FUN_CLR_GETS'
confr.o:confr.c:(.data+0x4aa8): undefined reference to `HB_FUN_U_GET'
confr.o:confr.c:(.data+0x4ae8): undefined reference to `HB_FUN_ZTRIM'
confr.o:confr.c:(.data+0x4af8): undefined reference to `HB_FUN_CSTR'
confr.o:confr.c:(.data+0x4c98): undefined reference to
`HB_FUN_SAV_SCRN'
confr.o:confr.c:(.data+0x4d28): undefined reference to `HB_FUN_U_MENU'
confr.o:confr.c:(.data+0x4d38): undefined reference to
`HB_FUN_RST_SCRN'
hbmk2: Error: Running linker. 1
rn -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd
-lgtwin -
lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -
lrddnsx -lrddfpt
-lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -
lkernel32 -luser3
2 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -
lshell32 -luuid
-lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -
lhbpcre -
What I noticed is that the reason I'm getting all of those "undefined
references" is because it did not compile 6 of my programs for some
reason. Functions.prg is one of them and that's the program that
stores most of these undefined functions. I'm wondering if I did
something wrong with the .hbp file???
Thanks for the help!!
Alain AUPEIX
> Cannot open SEC_CHEK.prg, assumed external
> Cannot open WRIT_REC.prg, assumed external
> Cannot open U_GET.prg, assumed external
> Cannot open READ_SAY.prg, assumed external
> `HB_FUN_DOR_LOG' ?
> `HB_FUN_GET_USERID' display a box and ask for userid ?
> `HB_FUN_U_ACCESS' ?
> `HB_FUN_SEC_CHEK' ?
> `HB_FUN_U_MENU' display menu ?
> `HB_FUN_SAV_SCRN' save part of the screen ?
> `HB_FUN_YES_TO' ?
> `HB_FUN_USE_DBFS' set dbf file to zone (select) ?
> `HB_FUN_PACK_DBFS' pack dbf
> `HB_FUN_RST_SCRN' restore part of the screen
> `HB_FUN_USE_DBF' select zone ?
> `HB_FUN_USE_NDX' set n
> `HB_FUN_REC_APPEND' append record
> `HB_FUN_WRITE_LINE' write a line in a text file ?
> `HB_FUN_CLR_FNAME' clear a text file ?
> `HB_FUN_LOAD_CLRS' ?
> `HB_FUN_VAR_INIT' variables init (global?)
> `HB_FUN_SCRL_MNU' scroll a menu box ?
> `HB_FUN_DIS_SCRN' disable output to screen ?
> `HB_FUN_U_READ' ?
> `HB_FUN_REC_APPEND' append a record ?
> `HB_FUN_REC_LOCK' lock a record ?
> `HB_FUN_WRIT_REC' write a record ?
> `HB_FUN_READ_REC' read a record ?
> `HB_FUN_CLR_GETS' initialize a get sequence
> `HB_FUN_U_GET' ?
> `HB_FUN_READ_SAY' initialize a read sequence
> `HB_FUN_ZTRIM' truncate end and/or beginning of a string ?
> `HB_FUN_CSTR' ?
> `HB_FUN_PRN_READY' check for printer state
> `HB_FUN_U_USERINFO' ?
> `HB_FUN_INDEX_DBF' recreate index (ndx/ntx) ?
> `HB_FUN_U_INKEY' check for inkey() ?
her is the list of missing functions
> What I noticed is that the reason I'm getting all of those "undefined
> references" is because it did not compile 6 of my programs for some
> reason. Functions.prg is one of them and that's the program that
> stores most of these undefined functions.
Sure, but it ought not be too much difficult for some of the undefined
functions
> I'm wondering if I did something wrong with the .hbp file???
I don't think so
Concerning functions:
For exemple, SAV_SCRN anr REST_SCRN are probably functions which receive
coordinates and save screen parts and restore them using these
coordinates. As it's not destructive, except form screen info, it's not
important and you will be able then to recreate it. It's probably used
before and after a menu display or a box display
In fact a great part of the functions seems to be obvious, and could be
easy to rewrite.
U_MENU probably display a menu at given coordinates with or without
shadow ...
report here some syntax for these three functions, and we will have a
better idea of what it does ...
Finally, you will have a very small number of functions where you will
have to search with more difficults.
You can also comment all these calls, and see what appens on the screen,
errors and also database problems that will occur
A+
Klas Engwall
> Hi Klas, no, I'm not still in the console window when that happens and
> this occurs when running it by double clicking the application.
> But.......I tried running it from the commandline and got this:
So, always run both the compile and the resulting exe from the
commandline until you have figured everything out.
> C:\Confr in Harbour>hbmk2 confr -run
Your hbp file is called confr.hbp and your main prg file is called
confr.prg, and you tell hbmk2 to just compile "confr". You are confusing
the project manager, and it only tries to compile confr.prg. Hbmk2 never
sees the hbp file.
The reason that you see a long list of other files that are actually
being compiled is that you removed the -m compiler switch. As I said
yesterday, you probably have a whole lot of "set procedure to
<something>" lines in your code, and without the -m switch those lines
will force Harbour to compile all the other prg files into the same
object file as confr.prg ... except six that are not referenced in any
of the other files with "set procedure to ...".
Look at this line in the log:
> Lines 7901, Functions/Procedures 133
This is the only line of its kind instead of the expected 31 similar
lines in the log if you specifly confr.hbp instead of just "confr".
When all those other prg files are included in the compile of confr.prg
they will add up to one single virtual confr.prg of size 7901 lines with
133 functions/procedures included.
> What I noticed is that the reason I'm getting all of those "undefined
> references" is because it did not compile 6 of my programs for some
> reason. Functions.prg is one of them and that's the program that
> stores most of these undefined functions. I'm wondering if I did
> something wrong with the .hbp file???
Yes, you forgot to tell hbmk2 to use it :-)
Regards,
Klas
Viktor Szakáts
> confr.prg, and you tell hbmk2 to just compile "confr". You are confusing
> the project manager, and it only tries to compile confr.prg. Hbmk2 never
> sees the hbp file.
Klas Engwall
Thanks for the reminder. The version in action here, however, is pretty
old: 2.0.0 (Rev. 13372).
Regards,
Klas
mmj0426
system comes up, when I select A.Cases and hit enter one time, nothing
happens. I hit enter again, the system stays up (not like before when
it closed) and I get this:
Error DBFNTX/1003 Open error:CAS_NAME.ntx (DOS Error 2)
Called from ORDLISTADD (0)
Called from USE_NDXS (782)
Called from USE_DBFS (187)
Called from CO_MAIN (18)
Called from CONFR (86)
C:\ConfrSys
Cas_name.ntx is the database name. I cannot find 'ORDLISTADD' but I'm
assuming it's a function?? Use_ndxs and Use_dbfs are functions,
co_main is a program and I'm assuming that Confr is the program and
not the .exe or .hbp.
I do not know what the numbers mean next to them. I assumed they were
line numbers but when I went searching,
it didn't look like any relation to me.
Alain Aupeix
> Thanks everyone! After I compiled using 'hbmk2 confr.hbp -run', the
> system comes up, when I select A.Cases and hit enter one time, nothing
> happens. I hit enter again, the system stays up (not like before when
> it closed) and I get this:
>
> Error DBFNTX/1003 Open error:CAS_NAME.ntx (DOS Error 2)
> Called from ORDLISTADD (0)
> Called from USE_NDXS (782)
> Called from USE_DBFS (187)
> Called from CO_MAIN (18)
> Called from CONFR (86)
> C:\ConfrSys
>
> Cas_name.ntx is the database name.
lowcased ou upcased field name.
A+
mmj0426
to my object oriented world!! LOL!
I've been searching this error message on the internet and basically,
DOS Error 2 means the file isn't found, but the file is there. I
don't understand. One site said to use just letters and numbers in
the file name so I took out the underscore in cas_name.ntx and changed
the programs.....same error message. I added 'Files=225' in the
config.nt and 'Clipper=F225' in the autoexec.nt, which was another
suggestion, and still received the same error. Another suggestion was
to rebuild the index. That's what I'm going to try next but I have to
research to learn how to do that..........
Klas Engwall
> Ok, I'm getting this stuff mixed up! I can't wait to go back
> to my object oriented world!! LOL!
"Just" rewrite your application OO-style and you are there :-)
> I've been searching this error message on the internet and basically,
> DOS Error 2 means the file isn't found, but the file is there. I
> don't understand. One site said to use just letters and numbers in
> the file name so I took out the underscore in cas_name.ntx and changed
> the programs.....same error message.
No, underscores are quite OK. And in Harbour you are also not limited to
8.3 style file names (unless a DOS application needs to open the same
files).
> I added 'Files=225' in the
> config.nt and 'Clipper=F225' in the autoexec.nt, which was another
> suggestion, and still received the same error.
It matters for Clipper and DOS (and for Clipper in the NTVDM) but not
for Harbour. You can open all the files you want simultaneously.
> Another suggestion was
> to rebuild the index. That's what I'm going to try next but I have to
> research to learn how to do that..........
The error message means "File not found", so have you checked that it is
there?
>>> Error DBFNTX/1003 Open error:CAS_NAME.ntx (DOS Error 2)
>>> Called from ORDLISTADD (0)
>>> Called from USE_NDXS (782)
>>> Called from USE_DBFS (187)
>>> Called from CO_MAIN (18)
>>> Called from CONFR (86)
>>> C:\ConfrSys
[I am cutting and pasting from your previous message here]
> Cas_name.ntx is the database name. I cannot find 'ORDLISTADD'
> but I'm assuming it's a function?? Use_ndxs and Use_dbfs are
> functions, co_main is a program and I'm assuming that Confr
> is the program and not the .exe or .hbp.
As Alain said, CAS_NAME.ntx is an index file. You might be thinking of a
file called CAS_NAME.DBF? If it exists, then _it_ is the database file.
I do not know what the numbers mean next to them. I assumed they
> were line numbers but when I went searching, it didn't look like
> any relation to me.
They _are_ line numbers. Start at the bottom: Confr.prg is your main prg
file. It does not seem to have a Main() function but one that is named
after the prg file itself (but possibly not declared). On line 86 it
calls CO_MAIN. CO_MAIN.prg is also a prg file (and also the name of a
function in it, whether explicitly declared or not). On line 18 it
(CO_MAIN, that is) calls USE_DBFS, which in turn calls USE_NDXS. Judging
from the lists of files and functions you have posted before, those two
are not separate prg files but functions in (probably) your newly
created prg file called functions.prg. The line numbers (187 and 782
respectively) are the line numbers in the prg file in which the
functions exist, not the "internal" line numbers of the separate
functions in the file.
Finally, the USE_NDXS() function calls the ORDLISTADD() Harbour
function. If you look at line 782 in functions.prg you will not see
"ORDLISTADD()" but something like "SET INDEX TO CAS_NAME". The
preprocessor converts it to "ORDLISTADD( CAS_NAME )".
So what is the actual problem, then? Well, the error message says that
ORDLISTADD() is unable to find the index file. Does CAS_NAME.NTX exist?
Does it exist in the directory where the application expects it to be?
If not, then you have to create it. There probably is a function
somewhere that does that, my guess is in co_index.prg. And I suppose
that somewhere in the application's menu system there is an option to do
the indexing.
As usual, good luck :-)
Regards,
Klas
matt johnson
Maybe looking for .NDX file instead on .NTX ?
Maybe a user defined function in the index expression?
Maybe a capitalization issue?
Yes, you should be able to re-build the indexes somewhere in the app?
maybe there is a memo field and you are missing the .dbt file?
--- On Mon, 7/18/11, mmj0426 <mmj...@aol.com> wrote:
mmj0426
the databases in the app and I tried it. It seemed to have worked but
I want to look more into that because I'm thinking that the app is
reindexing according to the old Clipper and not the Harbour way?? I
really don't understand these index files so I need to research that
some more. Cas_Name.ntx is stored in my working directory (C:
\ConfrSys) which is why I am confused as to why it cannot find it.
USE_NDXS and USE_DBFS are stored in my Functions.prg.
Line (782) shows this:
set index to &NDX_1., &NDX_2., &NDX_3., &NDX_4., &NDX_5., &NDX_6.,
&NDX_7.,
I'm pasting the function USE_NDXS (which includes line 782). Does
this function do something with an .ndx file? I thought the app
didn't use .ndx files but I may be wrong:
*-----------------------------------------------------------------------------
*
* USE_NDXS() Open a list of indices
*-----------------------------------------------------------------------------
*
function USE_NDXS
parameter NDX_LIST, DBF
local I, K, P
private S, NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
NDX_9, NDX_10
store "" to NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
NDX_9, NDX_1
if( type( "SEE_OPENS")<>"U", DISP_MSG( "Opening index "+ NDX_LIST),
NIL)
I = 0
do while len( NDX_LIST) <> 0
* Parse out an index name
*------------------------
K = at( [,], NDX_LIST)
I = I + 1
S = ltrim( str( I))
if K = 0
NDX_&S = NDX_LIST
NDX_LIST = ""
else
NDX_&S = left( NDX_LIST, K-1)
NDX_LIST = right( NDX_LIST, len( NDX_LIST)-K)
endif
enddo
if rddsetdefault() = "DBFMDX"
K = rat( [\], NDX_1)
if K = 0
K = rat( [:], NDX_1)
endif
if K <> 0
P = left( NDX_1, K)
NDX_1 = substr( NDX_1, K+1)
endif
set index to (DBF)
set order to tag (ltrim( NDX_1))
else
set index to &NDX_1., &NDX_2., &NDX_3., &NDX_4., &NDX_5., &NDX_6.,
&NDX_7., (line 782)
endif
if( type( "SEE_OPENS")<>"U", DISP_MSG( ""), NIL)
return .T.
Thanks to all for your help!
On Jul 18, 7:32 pm, matt johnson <mattfrien...@yahoo.com> wrote:
> what exactly is at line: Called from USE_NDXS (782)
> Maybe looking for .NDX file instead on .NTX ?
> Maybe a user defined function in the index expression?
> Maybe a capitalization issue?
> Yes, you should be able to re-build the indexes somewhere in the app?
> maybe there is a memo field and you are missing the .dbt file?
>
mmj0426
Alain AUPEIX
> I forgot to mention..................I do not have a Case_Name.dbf
A+
Klas Engwall
> Hi! I should have mentioned this..........there is a way to reindex
> the databases in the app and I tried it. It seemed to have worked but
> I want to look more into that because I'm thinking that the app is
> reindexing according to the old Clipper and not the Harbour way??
Except that the support for the ndx and mdx file formats were not
carried forward to Harbour, there is no old Clipper way that is
incompatible with Harbour. And we have already established that all
index files you have found, except two, are of the ntx type (and the two
ndx files are assumed abandoned). So I see no problem there.
If you look at the file list after indexing you should see a number of
ntx files with fresh file dates and two ndx files with old dates, right?
The index file opening routine in USE_NDXS() supports two kinds of index
files, 1) mdx files (several index orders in the same file) and 2) ntx
_or_ ndx files (but not both ntx _and_ ndx simultaneously, as far as I
can see). And all the evidence points to ntx being the index type used.
Incidentally, Clipper S87 did not support mdx files and did not have the
rddsetdefault() function, so although the source code is S87 style, some
of it was written with Clipper 5.x in mind and could not have been
compiled with S87. Not that it makes any difference, though ...
> I really don't understand these index files so I need to research that
> some more. Cas_Name.ntx is stored in my working directory (C:
> \ConfrSys) which is why I am confused as to why it cannot find it.
And all the dbf files and other ntx files are also in that directory, I
suppose?
> USE_NDXS and USE_DBFS are stored in my Functions.prg.
>
> Line (782) shows this:
> set index to&NDX_1.,&NDX_2.,&NDX_3.,&NDX_4.,&NDX_5.,&NDX_6.,
> &NDX_7.,
>
> I'm pasting the function USE_NDXS (which includes line 782). Does
> this function do something with an .ndx file? I thought the app
> didn't use .ndx files but I may be wrong:
In this case, the use of "ndx" in the function name and different
variable names is just shorthand for "index file", so we need not worry
about that.
> *-----------------------------------------------------------------------------
> *
> * USE_NDXS() Open a list of indices
> *-----------------------------------------------------------------------------
> *
> function USE_NDXS
> parameter NDX_LIST, DBF
If you look at line 18 of CO_MAIN() you will see the call to USE_DBFS()
with the dbf file name and the index file names specified. USE_DBFS()
then passes the index file names here (in the NDX_LIST parameter)
together with the dbf file name (in the DBF parameter). The latter is
only of interest in applications where mdx type index files are used.
And that is not the case here.
> local I, K, P
> private S, NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
> NDX_9, NDX_10
> store "" to NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
> NDX_9, NDX_1
There is a typo here. the last part of the last line should read NDX_10
instead of NDX_1 to match the line above it.
>
> if( type( "SEE_OPENS")<>"U", DISP_MSG( "Opening index "+ NDX_LIST),
> NIL)
If you want do see the list of the names of the index files that
USE_NDXS() is supposed to open, there is a debug setting called
SEE_OPENS somewhere else in the source code that, if turned on, will
make that happen. This is the same list of index files that you can find
on line 18 of CO_MAIN().
> I = 0
> do while len( NDX_LIST)<> 0
The NDX_LIST parameter passed from the calling code is a string of
comma-separated index file names. USE_NDXS() supports between one and
ten names in that string. The following code section parses the string
and assigns each file name to one of the NDX_<number> variables. At the
end of the function those variables are passed to the "set index to"
command.
> * Parse out an index name
> *------------------------
> K = at( [,], NDX_LIST)
> I = I + 1
> S = ltrim( str( I))
> if K = 0
> NDX_&S = NDX_LIST
> NDX_LIST = ""
> else
> NDX_&S = left( NDX_LIST, K-1)
> NDX_LIST = right( NDX_LIST, len( NDX_LIST)-K)
> endif
>
> enddo
The first alternative below handles mdx files, or more precisely one
single mdx file with possibly several index orders in it (we are now in
Clipper 5.x land, not in S87 land). But you have never mentioned any mdx
files, so it is not applicable.
> if rddsetdefault() = "DBFMDX"
> K = rat( [\], NDX_1)
> if K = 0
> K = rat( [:], NDX_1)
> endif
> if K<> 0
> P = left( NDX_1, K)
> NDX_1 = substr( NDX_1, K+1)
> endif
> set index to (DBF)
> set order to tag (ltrim( NDX_1))
> else
Instead we jump here and pass the names of the ntx files to "set index to"
> set index to&NDX_1.,&NDX_2.,&NDX_3.,&NDX_4.,&NDX_5.,&NDX_6.,
> &NDX_7., (line 782)
Did you lose the end of that line? It should go all the way up to &NDX_10.
> endif
>
> if( type( "SEE_OPENS")<>"U", DISP_MSG( ""), NIL)
> return .T.
Again, if the SEE_OPENS setting is turned on, there will be a message
displayed. This time it will be empty. Or maybe it will just remove a
message box that was created by the first call and was sitting on the
screen while USE_NDXS() was working.
Except that the code is not very elegant by Clipper 5 and Harbour
standards, and that there is a typo and half a line missing, I see no
problems here.
So the mystery remains, why is USE_NDXS() unable to open CAS_NAME.NTX?
Did the indexing routine create a new copy of it (look at the file
date)? Is the corresponding dbf located in the same directory (look at
line 18 of CO_MAIN() to find out what that file should be)? If the dbf
file is in a different directory, then we have to find out why the ntx
file is not there also. Maybe the original programmer never properly
tested reindexing and we have a bug in how directories are handled. But
if both the dbf file and the ntx file are in the same directory (and the
ntx file is a fresh one), then I am out of ideas for the moment...
Regards,
Klas
mmj0426
I found where someone else had gotten this same error because they
were missing a dbt file so I checked more into that but I do not have
a memo field.....so that was out.
I checked those lines and everything was there. I made the mistake of
cutting them off when I copied and pasted. There are no mdx files.
The dates are old on the ndx files but not the ntx files that would
change to the current date when I reindexed in the app. The dbf and
ntx files were all in the correct directory. But then I took a good
look at this when I opened CO_MAIN and looked at line 18:
if .not. USE_DBFS( "CASES, CAS_NAME, CAS_PEND, CAS_SS, CAS_TVAL,
CAS_CDT, CAS_TTYP, CAS_NAM2",;
"TAXTYPE, TAXTYPE",;
"SALUTATN")
return
endif
Not knowing the Clipper language, I just assumed these were dbf files.
I started by taking out CAS_NAME from the code and guess what....the
error changed to: Error DBFNTX/1003 Open error:CAS_PEND.ntx (DOS Error
2). I took out CAS_PEND and then the error showed CAS_SS and so forth
until there were only 3 left. Then, I realized that there were
no .dbf files of these names. I was confused because the error stated
that an .ntx file was not found, not a .dbf file.
I'm slow but I'm getting there. LOL!
Now, when I want to see a list of cases, they are all listed. I'm
VERY happy about that.
My question is why does the Harbour compiler pick up on this and not
the older version's compiler??
So, of course, there is more fun to follow. I can scroll to whatever
row I want, select "Update", that screen comes up just fine but the
cursor will not move to any other field. You should be able to select
"ESC" to get out of that screen without saving or select "F10" to save
the updated information and it will not allow me to do either one.
It's just.....stuck there. I have to click on the "X" to get out of
the system.
> > * USE_NDXS() Open a list of indices
Klas Engwall
> Hello! Well, with everyone's help, that problem has been solved!!
Great!
> I checked those lines and everything was there. I made the mistake of
> cutting them off when I copied and pasted. There are no mdx files.
> The dates are old on the ndx files but not the ntx files that would
> change to the current date when I reindexed in the app. The dbf and
> ntx files were all in the correct directory. But then I took a good
> look at this when I opened CO_MAIN and looked at line 18:
>
> if .not. USE_DBFS( "CASES, CAS_NAME, CAS_PEND, CAS_SS, CAS_TVAL,
> CAS_CDT, CAS_TTYP, CAS_NAM2",;
> "TAXTYPE, TAXTYPE",;
> "SALUTATN")
> return
> endif
My interpretation of this function call is that the original programmer
created a string consisting of both the name of the dbf file (CASES) and
all the corresponding index files (CAS_*) and that USE_DBFS() strips off
CASES for its own use and passes the rest of the string to USE_NDXS(). A
pretty confusing practice! I don't know what he means with the final
arguments "TAXTYPE, TAXTYPE","SALUTATN" but maybe it is not important.
> Not knowing the Clipper language, I just assumed these were dbf files.
> I started by taking out CAS_NAME from the code and guess what....the
> error changed to: Error DBFNTX/1003 Open error:CAS_PEND.ntx (DOS Error
> 2). I took out CAS_PEND and then the error showed CAS_SS and so forth
> until there were only 3 left. Then, I realized that there were
> no .dbf files of these names. I was confused because the error stated
> that an .ntx file was not found, not a .dbf file.
>
>I'm slow but I'm getting there. LOL!
Yes, all the CAS_* files are index files. So, what did you do to get
over the "File not found" problem? You say that all the files are in the
correct directory, but last time we talked you had the dbf file opened
(apparently) but the first index file could not be found. And that
problem then moved through the list of index file names as you took
names out of the string. But you say the problem is solved now. I don't
see how you did that. Are you running the application without the index
files?
> Now, when I want to see a list of cases, they are all listed. I'm
> VERY happy about that.
>
> My question is why does the Harbour compiler pick up on this and not
> the older version's compiler??
There really should be no difference. Finding a file with Harbour is not
different from finding a file with Clipper. What exactly do you mean
with "all" the files being in the correct directory? Does that include
CAS_NAME.NTX, CAS_PEND.NTX, CAS_SS.NTX, CAS_TVAL.NTX, CAS_CDT.NTX,
CAS_TTYP.NTX and CAS_NAM2.NTX? Harbour knows that the files referred to
as "CAS_NAME" etc, with no extension, are ntx files (the error message
says so), so the correct driver is in place. I cannot think of a good
reason for the files not being found if they are in the same directory
as the dbf file CASES.DBF, but I am still not sure where we stand on the
issue of files existing or not.
> So, of course, there is more fun to follow. I can scroll to whatever
> row I want, select "Update", that screen comes up just fine but the
> cursor will not move to any other field. You should be able to select
> "ESC" to get out of that screen without saving or select "F10" to save
> the updated information and it will not allow me to do either one.
> It's just.....stuck there. I have to click on the "X" to get out of
> the system.
If you did not put the index file names back in the USE_DBFS() call,
then anything can happen. And of course, there may be other
peculiarities in the code that depend on something else not working. You
will have to examine the code and try to debug what happens one line of
code at a time.
Regards,
Klas
Chris Gonnerman
there isn't a .deb for it; but I'm getting a failure on building hbqt,
saying that it can't find qapplication.h. What package do I need to
install? Or how do I get it to work? I have the dev packages for both
qt3 and qt4 installed, and both came with that file (in different
locations, of course).
Dmitry Oleynikov
There you can find complete list of packages to compile Harbour.
2011/7/22 Chris Gonnerman <ch...@gonnerman.org>:
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
> Unsubscribe: harbour-user...@googlegroups.com
> Web: http://groups.google.com/group/harbour-users
>
--
C уважением,
Дмитрий Олейников
Chris Gonnerman
> First you need to read the INSTALL file in your source directory.
> There you can find complete list of packages to compile Harbour.
rightly assumed I'd need it. But I still got the error, even though I'd
confirmed there was a qapplication.h in /usr/include/qt4. Turned out,
as far as I can tell, it had detected the QT3 packages I had installed
and tried to use them (but that won't work). SO, I removed them, and
one "make clean" later, it builds.
Summary: Fixed.
mmj0426
Well, I'm moving right along with this project but still getting some
errors that need to be fixed.
What I did to fix this error (file not found) was to remove the names
of the .dbf files from the program files since the system was no
longer using them. I don't understand why the programmer had the same
table name twice in certain areas either like:
"TAXTYPE, TAXTYPE",;
I found that in several places in different programs.
I found that the system was not using some of these tables and removed
the names but I'm not sure why the error in the first place since it
appeared that it was looking for an .ntx file, not a .dbf. I don't
know what made me look at the .dbf files to see that there were no dbf
files named cas_nam, cas_pend and so forth. There are however, .ntx
files with these names. Of course, I can delete them but when i go
into the system and reindex the databases, new ones appear. That is
coding that I need to change. This application's coding is messy and
I believe there are quite a few files that were just "left" in the
directory and not cleaned up when it was all said and done.
By removing these .dbf file names from the programs, it seems that
most of the application is running well. I'm able to add and save new
records, update and do mostly everything. My new error now is:
error dbfntx 1201 workarea not indexed
Klas Engwall
> Well, I'm moving right along with this project but still getting some
> errors that need to be fixed.
>
> What I did to fix this error (file not found) was to remove the names
> of the .dbf files from the program files since the system was no
> longer using them. I don't understand why the programmer had the same
> table name twice in certain areas either like:
> "TAXTYPE, TAXTYPE",;
No, I think you are cheating :-)
The list of "CAS_*" names (the ones with the underscores) are not dbf
file names but index (ntx) file names, and by removing them you are now
running the application without the indexes. That is why you get the
error "dbfntx 1201 workarea not indexed". Removing them is no solution,
so you have to put them back exactly as they were.
As I mentioned in my previous message, the original programmer created a
string of comma-separated file names and passed it to USE_DBFS(). The
first name in that string is the name of the dbf file and all the other
names are index file names (the ones with underscores after "CAS".
USE_DBFS() takes the dbf file name out of the string and passes the
other names to USE_NDXS(), which opens the index files if it can find
them. You still have the problem of finding out why USE_NDXS() cannot
find the files.
After the long string of file names there are two additional arguments
to USE_DBFS(). If you take a closer look at the original source code
line you will see that "CASES" and the list of "CAS_*" names make one
single argument (see the quotes before CASES and after CAS_NAM2).
Following that one there are two more arguments, "TAXTYPE, TAXTYPE"
(both instances of the word are in the same argument, see the
surrounding quotes!) and "SALUTATN". I don't know what those arguments
are, but my guess is that they have something to do with selecting the
controlling order after opening all the index files.
> I found that in several places in different programs.
Yes, that is the way he uses index files throughout the application.
> I found that the system was not using some of these tables and removed
> the names but I'm not sure why the error in the first place since it
> appeared that it was looking for an .ntx file, not a .dbf. I don't
> know what made me look at the .dbf files to see that there were no dbf
> files named cas_nam, cas_pend and so forth. There are however, .ntx
> files with these names. Of course, I can delete them but when i go
> into the system and reindex the databases, new ones appear.
OK, so then we know that the index files referenced in the USE_DBFS()
call do exist and that the indexing routine creates new copies if you
delete them. The question remains why USE_NDXS() cannot find them, and
that is where the key to your problem lies. Put the index file names
back in the USE_DBFS() call and put all your efforts into finding out
why USE_NDXS() fails. For example, is the application actually pointing
to the directory where you see those files? Are you still running it by
double-clicking the exe file? What happens if you open a command prompt,
go to the directory in question and run the application by typing the
name of the exe file? Does it make any difference?
> That is coding that I need to change.
No, don't do that! :-)
> This application's coding is messy
Yes, I agree, based on the small samples you have posted.
> and I believe there are quite a few files that were just "left" in the
> directory and not cleaned up when it was all said and done.
That goes for the two old ndx files that are not refreshed when you run
the indexing routine, but we have no evidence so far that any other
files are redundant. The CAS_*.NTX files are definitely needed.
> By removing these .dbf file names from the programs, it seems that
> most of the application is running well. I'm able to add and save new
> records, update and do mostly everything.
No, I don't think so :-)
> My new error now is:
>
> error dbfntx 1201 workarea not indexed
And now you know why, right?
Regards,
Klas
mmj0426
something else.
Yes Klas, I guess I was trying to cheat.......but not on purpose.
LOL! I really thought I was doing something good. Oh well.
I understand all that you wrote and I put everything back the way it
was. Now I'm back to the original error that it cannot find the ntx
file. I am stumped!! I've been searching and searching and cannot
figure out why I'm getting that error message.
When I run the application, I use the command prompt. If I just click
on the .exe itself the application comes up but does not give me an
error. It just quickly closes.
Here's the strange thing. I don't know what I'm doing wrong and this
may be nothing but I wanted take a look inside of my Functions.prg but
when I try to bring it up using the PE.EXE tool and type "PE
FUNCTIONS" from the command prompt, it will not come up. It shows the
file name functions.prg at the bottom of the PE tool but the PE stays
blank, yet I can bring up any other program. Functions.prg is the
program that I stuffed all of those functions into. Everything is in
the same directory. It's like the PE can't find the Functions.prg and
I'm wondering if this is where the problem lies. USE_DBFS() and
USE_NDXS() functions are stored in Functions.prg. So..........I have
a feeling I did not save this program correctly after adding all those
functions?? When I added them I used the PE.EXE tool to do so and
saved using Ctrl + W.
mmj0426
it's Function without the S....forgot to add the s) recompiled. Now
it comes up when I use the PE tool but I'm still getting that error.
Back to the drawing board.
Klas Engwall
> Thanks! I'm sorry I'm just getting back now. I needed to work on
> something else.
No problem. It is your project, I am just trying to push when you feel
like you need to be pushed. :-)
> Yes Klas, I guess I was trying to cheat.......but not on purpose.
> LOL! I really thought I was doing something good. Oh well.
The original programmer did not write the prettiest code I have seen
(the little that I actually have seen), but it has worked before, so use
a screwdriver rather than swinging an axe to fix it :-)
> I understand all that you wrote and I put everything back the way it
> was. Now I'm back to the original error that it cannot find the ntx
> file. I am stumped!! I've been searching and searching and cannot
> figure out why I'm getting that error message.
OK. One thing we have not touched in several weeks is the fact that you
were missing four or five functions and commented the calls to those
functions out to make the linker happy. For all I know, it could be one
of those missing functions that made the Clipper program work, so it is
time to revisit them and try to figure out what each of them is supposed
to do. Maybe you should replace them with temporary stubs that display a
message on screen so you can see "what you are missing". And then
uncomment the commented out calls.
What are the names of those functions, by the way? Maybe knowing the
names will ring a bell or two.
Secondly, let us analyze what you have in your working directory. First
of all, there is only one directory involved, right? And in that
directory you have the Harbour-compiled exe file. You also have
CASES.DBF and a bunch of CAS_<something>.NTX files including the one
that the error message mentions. And some other files not directly
related to the error. All of these are in one single directory, to which
you have navigated with the command prompt. Right?
Now you need to dive into the USE_DBFS() and USE_NDXS() functions and
check what they actually do. You posted USE_NDXS() some time ago, and it
looked simple enough. What about USE_DBFS()? The easiest way to check
them is perhaps to sprinkle them with comments that you can read on
screen, like ...
@ 24,0 say 'Step 1'
inkey(0)
... and so on. And then you can step through the code one comment at a
time and press any key to get to the next one. After the line where
USE_DBFS() opens the dbf file, you can add ...
@ 24,0 say '*' + alias() + '*'
inkey(0)
... and it will respond with *CASES* if all is well up to that point (if
the asterisks are displayed with nothing between them, then the file was
not opened). Then you need to analyze the code up to that point to see
how it might differ from the code in USE_NDXS() (which is supposed to
open the index files but is unsuccessful in finding them) regarding how
paths and file names are handled.
And, back to the missing functions, has the program execution this far
passed any point in the flow of code where any of the commented out
functions should have been called?
> When I run the application, I use the command prompt. If I just click
> on the .exe itself the application comes up but does not give me an
> error. It just quickly closes.
Good. Let's stay there :-).
> Here's the strange thing. I don't know what I'm doing wrong and this
> may be nothing but I wanted take a look inside of my Functions.prg but
> when I try to bring it up using the PE.EXE tool and type "PE
> FUNCTIONS" from the command prompt, it will not come up. It shows the
> file name functions.prg at the bottom of the PE tool but the PE stays
> blank, yet I can bring up any other program. Functions.prg is the
> program that I stuffed all of those functions into. Everything is in
> the same directory. It's like the PE can't find the Functions.prg and
> I'm wondering if this is where the problem lies. USE_DBFS() and
> USE_NDXS() functions are stored in Functions.prg. So..........I have
> a feeling I did not save this program correctly after adding all those
> functions?? When I added them I used the PE.EXE tool to do so and
> saved using Ctrl + W.
Wow, this is the first time ever that I have heard anyone mentioning the
old PE editor being used. Just throw it away and use any decent text
editor that you are familiar with. Even notepad.exe is better in the
Windows world.
But everything you put into functions.prg is in all probability still
there. If it were empty you would get linker errors. What is the size of
the file on disk?
There is a distinct possibility that there was an EOF marker, an ASCII
26 character, at the end of each of the source files that you imported
into functions.prg and that whatever comes ofter one of those chr(26)-es
in the file is blocked from view in PE. For editing your source files,
double-click on the prg file ( yes :-) ) and pick the editor of your
choice when Windows asks what to do (or just type NOTEPAD FUNCTIONS.PRG
on the commandline instead of PE FUNCTIONS.PRG). That should get you
going with your code review.
Regards,
Klas
mmj0426
do not remember which ones they were so I will dig.
Using notepad would be easier. I do NOT like PE at all.
Yes, there is only one directory involved but at the command prompt
and everything including the Harbour compiled exe. Now, when I first
open the command prompt I type:
cd c:\hrbour (That is my directory that stores all of
the harbour stuff)
c:\hrbour>set path=c:\hrbour\bin
c:\hrbour>cd \Confr (Which is my working directory).
Now, I need another big favor. How do I debug in Harbour. You'll
need to take baby steps with me on this one because I have never even
debugged in Clipper. I'm reading alot of Alt(D) and something about
switch -b but I have no clue of where to start or what the debugger is
even called.
Thanks!!
Klas Engwall
> Thanks Klas, I will look into those missing functions. As of now, I
> do not remember which ones they were so I will dig.
>
> Using notepad would be easier. I do NOT like PE at all.
PE was never meant to be a _real_ editor, just something that
Nantucket/CA could throw at people who were complaining that they could
not use Clipper because there was no editor included.
> Yes, there is only one directory involved but at the command prompt
> and everything including the Harbour compiled exe. Now, when I first
> open the command prompt I type:
>
> cd c:\hrbour (That is my directory that stores all of
> the harbour stuff)
> c:\hrbour>set path=c:\hrbour\bin
> c:\hrbour>cd \Confr (Which is my working directory).
Great. We have talked about that directory several times before, but I
was still not 100% sure that there was not an additional directory
involved that I was not aware of.
> Now, I need another big favor. How do I debug in Harbour. You'll
> need to take baby steps with me on this one because I have never even
> debugged in Clipper. I'm reading alot of Alt(D) and something about
> switch -b but I have no clue of where to start or what the debugger is
> even called.
I think it is called "the debugger" :-). I have never really used it
except very occasionally. Instead I have always used the method I
described in my previous message. Or, when using xHarbour (which used to
be one step ahead of Harbour for a number of years - but not anymore)
I use the TraceLog() function to write debug messages to a file. I
looked it up in Harbour a few minutes ago and found that it is a little
different than in xHarbour. You start with setting the name of the logfile:
hb_tracefile( 'logfile.txt' )
Then, wherever you want to write to the file, you add a line saying
something like:
hb_tracelog( "whatever" )
and Harbour will write the prg name, the line number, the function name
and the argument(s) to the file. The arguments can be a comma separated
list of literal strings or variable names or expressions (I think). Any
existing file of the same name will be deleted when you run your
application again. I have not yet used hb_tracelog() in Harbour except
for a quick test so I could tell you that it exists.
OK, then, the debugger ...
There are two things you have to do to use the debugger.
1) Add the -b (or /b) compiler switch to the hbmk2 call just like any
other compiler switches you already pass to it. This will add debugging
info to the executable. Take the switch away when you are done debugging
to save on the exe size.
2) Add a call to the altd() function where you want the debugger to kick
in. Or do it manually by pressing <Alt><D> at any wait state where you
want to start debugging. Then just use the function keys mentioned in
the debugger window to continue. For example, press <F8> to step through
the code one line at a time. Press <Alt><H> to get to the help screen.
The source code of the application you want to debug must be accessible
to the debugger. In your case, where everything is in the same
directory, this should work without any further configuration.
Regards,
Klas
mmj0426
I went ahead and started from scratch. This time I brought in all the
programs into a new directory, instead of just putting the functions
the linker called for into the FUNCTION.PRG, to make sure I wasn't
missing anything. Then, I uncommented the calls to those functions
that I had commented out earlier.
I have a feeling I might know what the problem is. One of the
function calls I had commented out was in a program named
SECURITY.PRG. This program tests whether the specified user has
rights to the specified application and I'm wondering if this is where
the hang up is. So, after trying to compile after uncommenting, I'm
getting "undefined reference to":
`HB_FUN_BIN2IU'
`HB_FUN_BIN2NS'
`HB_FUN_OL_YIELD'
`HB_FUN_SWPRUNCMD'
`HB_FUN_COM_DSR'
`HB_FUN_FILEDATE'
`HB_FUN_FILETIME'
`HB_FUN_FILECOPY'
`HB_FUN_DIRMAKE'
`HB_FUN_FT_ONTICK'
`HB_FUN_OL_AUTOYIELD'
`HB_FUN_PADLEFT'
`HB_FUN_POSREPL'
I've searched high and low in our directories with no luck of finding
anything so I went online to search and maybe found a couple of things
out......
It seems that SWPRUNCMD() is a command that was replaced with RUN().
I found a procedure for SHOWTIME() but it causes the linker to list
FT_ONTICK() which I haven't found much information obout.
I couldn't find anything on the rest of the functions that are
missing.
By any chance, are some of these functions replaced by Harbour like
the SWPRUNCMD()?
Viktor Szakáts
mmj0426
That got rid of some of them. Here is what is left:
`HB_FUN_BIN2IU'
`HB_FUN_BIN2NS'
`HB_FUN_OL_YIELD'
`HB_FUN_SWPRUNCMD'
`HB_FUN_COM_DSR'
The HB_FUN_OL_AUTOYIELD is missing because I found, while researching,
that I can use HB_IDLESTATE() in place of it but I haven't found
whether or not I can use it to replace OL_YIELD.
Lorenzo Fiorini
> The HB_FUN_OL_AUTOYIELD is missing because I found, while researching,
> that I can use HB_IDLESTATE() in place of it but I haven't found
> whether or not I can use it to replace OL_YIELD.
IIRC autoyield and yield were used to fix 100% cpu.
They are probably not needed with Harbour.
best regards,
Lorenzo
Viktor Szakáts
This is part of hboslib. I seem to remember you use
`HB_FUN_SWPRUNCMD'
`HB_FUN_COM_DSR'
mmj0426
Well then I can go ahead and comment those out. I did read where
someone else said the same thing but it really wasn't confirmed.
Does anyone know if it is ok to replace SWPRUNCMD() with RUN() without
any problems?
On Aug 9, 11:38 am, Lorenzo Fiorini <lorenzo.fior...@gmail.com> wrote:
mmj0426
got rid of the 'undefined reference to SHOWTIME()' which also got rid
of FT_ONTICK() since it was being called from there.
Klas Engwall
> I went ahead and started from scratch. This time I brought in all the
> programs into a new directory, instead of just putting the functions
> the linker called for into the FUNCTION.PRG, to make sure I wasn't
> missing anything. Then, I uncommented the calls to those functions
> that I had commented out earlier.
Sounds like a good (re)start
> I have a feeling I might know what the problem is. One of the
> function calls I had commented out was in a program named
> SECURITY.PRG. This program tests whether the specified user has
> rights to the specified application and I'm wondering if this is where
> the hang up is.
Possibly, but why would it still let you open the dbf if it denies you
the right to open the index files?
> So, after trying to compile after uncommenting, I'm
> getting "undefined reference to":
>
> `HB_FUN_BIN2IU'
> `HB_FUN_BIN2NS'
> `HB_FUN_OL_YIELD'
> `HB_FUN_SWPRUNCMD'
> `HB_FUN_COM_DSR'
> `HB_FUN_FILEDATE'
> `HB_FUN_FILETIME'
> `HB_FUN_FILECOPY'
> `HB_FUN_DIRMAKE'
> `HB_FUN_FT_ONTICK'
> `HB_FUN_OL_AUTOYIELD'
> `HB_FUN_PADLEFT'
> `HB_FUN_POSREPL'
>
> I've searched high and low in our directories with no luck of finding
> anything so I went online to search and maybe found a couple of things
> out......
The reason you cannot find the source code is that those are functions
from precompiled libraries: OsLib, Clipper Tools, The NanForum Toolkit.
But there are replacements of the same names in Harbour for most of them.
Viktor solved all but three of the missing functions, as far as I can
see. Add the three hbc files he mentioned to your hbp file together with
all the prg files and everything else that is already there. But I think
he missed one: hbnf.hbc (which will take care of FT_OnTick() ). Add that
one too.
Then there are two functions left in the list that neither Viktor nor I
can recognize: Bin2IU() and Bin2NS(). They are some kind of numeric
conversions, I am sure, but they are not from any of the libraries I
mentioned. Did you ever find any lib files in the old toolbox? Not that
you can use them with Harbour, but to give us an idea of where the two
functions came from. You will have to investigate what the arguments in
the calls to the two functions are and try to figure out from the
surrounding code what the expected result might be.
> It seems that SWPRUNCMD() is a command that was replaced with RUN().
Yes. It was originally RUN in Clipper too, but it was inefficient
memory-wise. So the Blinker folks came to the rescue with SwpRunCmd()
which swaps out almost the entire calling application to make room for
the other application. In a 32- or 64-bit environment we do not have
those memory restrictions, so Run() is back. Or hb_run(). But Viktor has
also written a SwpRunCmd() wrapper for hb_run(), so there are several
different choices.
> I found a procedure for SHOWTIME() but it causes the linker to list
> FT_ONTICK() which I haven't found much information obout.
As I mentioned above, FT_OnTick() is a function from the NanForum
Toolkit. It exists in Harbour in the hbnf lib. But it sounds funny that
ShowTime() would try to pull it in. ShowTime() is from Clipper Tools
(the hbct lib in Harbour). Unless, of course, we are talking about a
different ShowTime() that the original programmer wrote. Then it would
make sense to use FT_OnTick() to set the pace of the on-screen clock.
> I couldn't find anything on the rest of the functions that are
> missing.
>
> By any chance, are some of these functions replaced by Harbour like
> the SWPRUNCMD()?
A pretty good chance, I would say, except for two functions. Add the
names of the four hbc files to your hbp file and check that most of the
names in the list disappear. Then take a closer look at what the two
remaining functions are supposed to do.
Regards,
Klas
mmj0426
Ok, all are gone except for the BIN2* and the COM_DSR. Using the hbct
did not remove the COM_DSR unless I did something wrong. I added all
in my hbp file.
Is Harbour 3.0.0 free?
Meanwhile, I am going to try to find the BIN2*. Maybe I overlooked
them but I will look again. Since you all haven't heard about them,
they must be from the last programmer.
Good question in reference as to why it would let me open the dbf
files denying me the right to open the index files. I just remember
when I selected the menu choice to let me see all rows within the
table, I just get the error that it cannot find the file....naming
the .ntx file. Yet when I took out the names of the files (back when
I thought I was doing the right thing), the table would open. So,
once again, I'm probably wrong. But.....I'm hoping that once all of
these errors are corrected, I will find out more. I'm curious to see
what happens when all of the function calls are included again.
>
> - Show quoted text -
Klas Engwall
> Ok, all are gone except for the BIN2* and the COM_DSR. Using the hbct
> did not remove the COM_DSR unless I did something wrong. I added all
> in my hbp file.
>
> Is Harbour 3.0.0 free?
Sure. It is here:
Watch out for the wrapped line. 3.0.0 was released three weeks ago.
> Meanwhile, I am going to try to find the BIN2*. Maybe I overlooked
> them but I will look again. Since you all haven't heard about them,
> they must be from the last programmer.
In the meantime I searched my old Clipper archives and found nothing.
And Google did not come up with anything either, but I guess you already
tried that.
Regards,
Klas
Alain Aupeix
Possible signification for these functions ??
> `HB_FUN_BIN2IU' Converting bin to intel ?
> `HB_FUN_BIN2NS' Converting bin to ??
> `HB_FUN_OL_YIELD' ??
> `HB_FUN_SWPRUNCMD' swap run cmd ?
> `HB_FUN_COM_DSR' manage dsr from com port ?
> `HB_FUN_FT_ONTICK' ??
A+
mmj0426
I found out this for COM_DSR:
COM_DSR() Check "Data Set Ready" signal
This is the function that uses COM_DSR within my program:
*------------------------------------------------------------------------------
*
* Check whether the printer is ready
*------------------------------------------------------------------------------
*
function PRN_READY( PR_DEV)
private RET_VAL
if PR_DEV = NIL
PR_DEV = "LPT1"
endif
do SAV_SCRN
do DISP_MSG with "Please wait"
//RET_VAL = if( PR_DEV="COM1", COM1_READY(), isprinter())
RET_VAL = if( PR_DEV="COM1", COM_DSR( 1), isprinter())
do while .not. RET_VAL
if YES_TO( "The printer is not ready. Try again? ", "Y")
RET_VAL = if( PR_DEV="COM1", COM_DSR( 1), isprinter())
else
exit
endif
enddo
do RST_SCRN
I am searching for a replacement for this.
As for the BIN2*, I cannot find anything on these but they are used
quite often in my program. Here is an example of one of the functions
for BIN2IU:
FUNCTION DI_T_DATE
parameter AREA
if pcount() < 1
private AREA
AREA = alias()
endif
return str( BIN2IU( &AREA.->DIC_T_DATE, 3), 6)
and an example for BIN2NS:
FUNCTION DI_UNITS1
parameter AREA
if pcount() < 1
private AREA
AREA = alias()
endif
return BIN2NS( &AREA.->DIC_UNITS1, 2)
I see a rewrite for these two!! Oh well, all in all it hasn't been
the horrible trip I thought it was going to be....yet. Lol!
It's just been a very slow one.
Klas Engwall
> This is the function that uses COM_DSR within my program:
>
> *------------------------------------------------------------------------------
> *
> * Check whether the printer is ready
> *------------------------------------------------------------------------------
> *
> function PRN_READY( PR_DEV)
> private RET_VAL
> if PR_DEV = NIL
> PR_DEV = "LPT1"
> endif
> do SAV_SCRN
> do DISP_MSG with "Please wait"
> //RET_VAL = if( PR_DEV="COM1", COM1_READY(), isprinter())
> RET_VAL = if( PR_DEV="COM1", COM_DSR( 1), isprinter())
> do while .not. RET_VAL
> if YES_TO( "The printer is not ready. Try again? ", "Y")
> RET_VAL = if( PR_DEV="COM1", COM_DSR( 1), isprinter())
> else
> exit
> endif
> enddo
>
> do RST_SCRN
>
>
> I am searching for a replacement for this.
Are you planning to use a serial printer? If not, you can dump the if()
alternatives that are related to "COM1" and get rid of the COM_DSR()
function entirely. And, additionally, in a Windows environment a
PRN_READY() function is pretty useless. You print to the spooler. If the
physical printer is offline, the print job will sit in the spooler for a
while and then there will probably be a dialog box from Windows saying
that it could not be printed and ask if you would like to try again. You
could most likely replace the entire function with just:
function PRN_READY()
return .T.
> As for the BIN2*, I cannot find anything on these but they are used
> quite often in my program. Here is an example of one of the functions
> for BIN2IU:
>
> FUNCTION DI_T_DATE
> parameter AREA
>
> if pcount()< 1
> private AREA
> AREA = alias()
> endif
>
> return str( BIN2IU(&AREA.->DIC_T_DATE, 3), 6)
This looks suspiciously like conversion of a date in YYYYMMDD format
where the first two digits are skipped, so YYMMDD is used (I could be
wrong, of course :-) ). It is converted to a number which is then
stringified to six characters. For some odd reason :-). To verify this,
there are a few things you need to investigate:
1) Check the argument that is passed to the DI_T_DATE() function. This
will tell you which dbf to search.
2) Then check the DIC_T_DATE field in that dbf. What field type is it?
3) What is a typical value stored in that field (unless the field type
is "Date", which makes the answer obvious)?
4) What happens with the string that is returned from the DI_T_DATE()
function? What is it used for?
> and an example for BIN2NS:
>
> FUNCTION DI_UNITS1
> parameter AREA
>
> if pcount()< 1
> private AREA
> AREA = alias()
> endif
>
> return BIN2NS(&AREA.->DIC_UNITS1, 2)
1) Check the argument that is passed to the DI_UNITS1() function. This
will, again, tell you which dbf to search.
2) Then check the DIC_UNITS1 field in that dbf. What field type is it?
3) What is a typical value stored in that field?
4) What happens with the data that is returned from the function? What
is it used for? And what data type is it (based on how it is further
processed)?
You might have a tool called DBU.EXE in the same place where PE.EXE
exists. Use it to open the dbfs in question so you can take a look at
them. If you don't have it (or any similar tool), you could try Excel
instead, although the field type will not be shown. Just don't let Excel
save the file when you are done.
Regards,
Klas
Alain AUPEIX
>
> Are you planning to use a serial printer? If not, you can dump the
> if() alternatives that are related to "COM1" and get rid of the
> COM_DSR() function entirely. And, additionally, in a Windows
> environment a PRN_READY() function is pretty useless. You print to the
> spooler. If the physical printer is offline, the print job will sit in
> the spooler for a while and then there will probably be a dialog box
> from Windows saying that it could not be printed and ask if you would
> like to try again. You could most likely replace the entire function
> with just:
>
> function PRN_READY()
> return .T.
isprinter(), and directly use isprinter() in the source.
A+
mmj0426
I believe (I hope) that I am moving right along. I downloaded
Harbour3 and starting using it. Now, I am receiving errors that
variables do no exist as in the escape key, the enter key, the up key
and so forth. What should I be including in Harbour? It seems that
these values were stored in the "inkey.ch" file in Clipper but the
hb.ch file has the line to include that file so I don't know what I'm
missing or doing wrong???
mmj0426
been using just -run.
After trying the -hbrun, I receive the error: Error opening
hboslib.hbc and hbblink.hbc. I have these listed in my .hbp file
though. Is there a special way that these files need to be listed?
This might be why I'm getting the 'variables do not exist' error??
Thanks in advance!
Klas Engwall
> I believe (I hope) that I am moving right along. I downloaded
> Harbour3 and starting using it. Now, I am receiving errors that
> variables do no exist as in the escape key, the enter key, the up key
> and so forth. What should I be including in Harbour? It seems that
> these values were stored in the "inkey.ch" file in Clipper but the
> hb.ch file has the line to include that file so I don't know what I'm
> missing or doing wrong???
If there is code referencing K_ESC, K_ENTER, K_UP etc then the solution
is to #include "inkey.ch" just like in Clipper. The "hb.ch" file is just
a convenience so you do not need to specify all the files listed in it
over and over. So you can specify either of them (at least if we are
just talking about the key constant names). Is the hb.ch file #included
in every prg file where those constants exist?
Regards,
Klas
Klas Engwall
> I just read online to use -hbrun to run your target in Harbour. I've
> been using just -run.
>
> After trying the -hbrun, I receive the error: Error opening
> hboslib.hbc and hbblink.hbc. I have these listed in my .hbp file
> though. Is there a special way that these files need to be listed?
>
> This might be why I'm getting the 'variables do not exist' error??
You are trying to do two different things at the same time, which can be
confusing (to the human, not to the compiler :-) ). Dump -run and -hbrun
and just let Harbour create the exe file. Period. Then, when you are
satisfied that everything has been compiled and linked correctly (no
error messages), it is time to run the exe by typing its name on the
commandline.
You can either specify the lib files with -lhboslib etc or specify them
with hboslib.hbc etc instead. hbmk2 is happy with any way you specify
them, so that should not be your problem. As long as the files are at
their correct locations in the Harbour tree, hbmk2 knows where to find
them. And I doubt that there could be anything missing in the official
download of the binaries.
But the non-existing variables are K_ESC, K_ENTER etc, right? That
should still be a problem with "inkey.ch" or "hb.ch" not being #included
in the files where the errors occur. Check which prg files are mentioned
together with the errors.
Regards,
Klas
mmj0426
contained the values for the keys and that problem is now fixed. I am
back to my original error that the error cannot be found.
I don't remember why I did this but I started changing around the
order of my programs that are listed in my .hbp file and noticed that
the error messages change. I have to go back to the basics and
ask.........does it matter what order my source programs are listed in
the .hbp file and do I need to list the libraries as well? I did not
put them in there.
Klas Engwall
> Again, thank you very much! I found a program that I was missing that
> contained the values for the keys and that problem is now fixed. I am
> back to my original error that the error cannot be found.
Good
> I don't remember why I did this but I started changing around the
> order of my programs that are listed in my .hbp file
Ah, I was wondering why we were taking backwards steps inbetween the
forward ones :-)
> and noticed that
> the error messages change. I have to go back to the basics and
> ask.........does it matter what order my source programs are listed in
> the .hbp file
No, the error messages from the compiler change because the errors are
discovered in a different order when you move the file names around in
the hbp file. You will not get every error in every prg file listed in
sequence. When you fix the errors reported in one file, the errors in
the next file will be reported instead. It never ends :-)
I always put the main prg file at the top of the source file list, but
that is just for my own sense of order because the existence of the
Main() procedure in it is enough for the linker to create a correct exe
anyway. And the rest of the files I put in there in alphabetical order
... for the same reason :-)
> and do I need to list the libraries as well? I did not
> put them in there.
Yes. The contrib libs need to be specified in the hbp file. The core
libs are taken care of automatically.
Regards,
Klas
mmj0426
What would the contrib libs be? I looked into the Harbour3's contrib
directory but there wasn't any listed. I'm assuming that's what you
meant?
Also, for the life of me........I've tried and tried to debug but have
failed. I can get the program to come up, but cannot step through.
What I did was type AltD() in my program where I wanted to start
debugging. Then, at the command prompt within my working directory I
typed my program name which is Confr.prg with -g behind it. I bring
the program up in MS Word and I've tried Alt D, F9, F8......the cursor
doesn't move. I've researched and still cannot find anything that
helps. I don't know what I'm doing wrong......again. LOL!
Klas Engwall
> What would the contrib libs be? I looked into the Harbour3's contrib
> directory but there wasn't any listed. I'm assuming that's what you
> meant?
We talked about hbblink and hboslib the other day, and IIRC hbct and
hbnf earlier. The lib files, core and contribs, are all in the lib
directory (lib\win\mingw for mingw users) so you cannot determine which
are core and which are contrib by looking there. The names are prefixed
with "lib", so the files are called libhbblink.a etc. In the hbp file
you reference them with a -l switch, skip the "lib" prefix and the ".a"
extension, all in all -lhbblink for that particular one.
But the source code is in the contrib directory, each contrib in its own
subdirectory. So by looking at the directory names you can see that
hbblink (no prefixes or suffixes) is a contrib library.
> Also, for the life of me........I've tried and tried to debug but have
> failed. I can get the program to come up, but cannot step through.
> What I did was type AltD() in my program where I wanted to start
> debugging.
And nothing happened? Did you add the -b switch to the hbp file to
include debugging info? And just to be sure, you inserted the AltD()
function call line in your source code and then compiled it, right? (I
had to ask, sorry)
> Then, at the command prompt within my working directory I
> typed my program name which is Confr.prg with -g behind it.
After compiling (and fixing the bugs the compiler and linker complain
about) you will have a confr.exe to run. Confr.prg will never run. And
what is -g supposed to be?
> I bring
> the program up in MS Word and I've tried Alt D, F9, F8......the cursor
> doesn't move.
Why should it? MS Word knows nothing about those things. Are you just
trolling and testing how crazy questions I will attempt to answer?
> I've researched and still cannot find anything that
> helps. I don't know what I'm doing wrong......again. LOL!
Compile and link your sources with no -run or -hbrun switches. Check
that there are no error messages. Then run the resulting confr.exe.
That's all.
Regards,
Klas
mmj0426
sure what libraries you were referring to.
I had tried the -b switch first and received many errors in reference
to undefined functions so I had read somewhere in this forum to use -
g. Then, I realized after researching online that I didn't need to
use the hbmk2 in front of the program name in the command prompt.
When I took that out, the -b switch worked the same way as using the -
g.
I am using the AltD() function within my program right before where I
want it to break.
I'm sorry about the crazy question. I really am not testing you. I
had failed to tell you why MS Word was brought up.........
after typing confr.prg -b (or -g) the "windows cannot open this file"
dialog box came up and I didn't know what else to select to use.
Everything I'm doing in Harbour (and Clipper too) is brand new and I
do not know what to expect because I have nothing to compare it to
since I normally program using object oriented languages. I am having
a hard time understanding this language.........which is quite obvious
I'm afraid. Again, I apologize.
I would think that some sort of debugger should appear instead of the
"windows cannot open this file" dialog box but that's what happens. I
even read somewhere to use this coding within my program:
PROCEDURE debugger()
AltD( 1 ) // Enables the debugger. Press F5 to go
DISP_MSG( "debugger enabled" )
AltD() // Invokes the debugger
DISP_MSG( "debugger invoked" )
RETURN
Still........nothing happens.
Thanks again!
Klas Engwall
> Ok, those libs. I do have them in my .hbp file. I wanted to make
> sure what libraries you were referring to.
>
> I had tried the -b switch first and received many errors in reference
> to undefined functions so I had read somewhere in this forum to use -
> g. Then, I realized after researching online that I didn't need to
> use the hbmk2 in front of the program name in the command prompt.
> When I took that out, the -b switch worked the same way as using the -
> g.
But ... hbmk2 is the utility that creates your executable, confr.exe.
You still seem to be trying to run confr.prg, which is just your source
code, a text file. That will never work. Until you have successfully
created confr.exe and type that name on the commandline you will never
get anywhere.
> I am using the AltD() function within my program right before where I
> want it to break.
OK
> I'm sorry about the crazy question. I really am not testing you. I
> had failed to tell you why MS Word was brought up.........
> after typing confr.prg -b (or -g) the "windows cannot open this file"
> dialog box came up and I didn't know what else to select to use.
> Everything I'm doing in Harbour (and Clipper too) is brand new and I
> do not know what to expect because I have nothing to compare it to
> since I normally program using object oriented languages. I am having
> a hard time understanding this language.........which is quite obvious
> I'm afraid. Again, I apologize.
OK, no problem.
I am beginning to understand why you are calling the .prg files
"programs". You seem to think that they are runnable. They are not. Just
like a .c source file or .cpp source file or any other source code file
you cannot use them for anything but building your exe file. And hbmk2
is the tool that does the job.
It is even possible to compile a .txt file with hbmk2 if the code inside
it is valid Clipper code. You will get an "Invalid file format" error
(or something like that), but it will compile, and the resulting exe
file can be run. So the file name extension is really just a convention,
it does not make the file a runnable program. Building an .exe file with
hbmk2 is the key to that.
The -b switch should sit in the .hbp file together with the output file
name (-oconfr), the source code file names, the lib file names and
whatever other switches you use. Then when you finally get a confr.exe
from running hbmk2 over the .hbp file, and invoke that exe file, that is
when you will be able to use the debugger. Prg files by themselves
cannot be debugged, but they must be available for the debugger to read
when you run your confr.exe with debugging enabled. So the debugger is
useless for finding syntax errors and other errors that the compiler and
linker complain about. You cannot use it before the build process ends
successfully.
> I would think that some sort of debugger should appear instead of the
> "windows cannot open this file" dialog box but that's what happens. I
> even read somewhere to use this coding within my program:
>
> PROCEDURE debugger()
> AltD( 1 ) // Enables the debugger. Press F5 to go
> DISP_MSG( "debugger enabled" )
> AltD() // Invokes the debugger
> DISP_MSG( "debugger invoked" )
> RETURN
>
> Still........nothing happens.
It should, if you are running confr.exe after compiling it with -b, not
when dealing with confr.prg separately. But as long as there are
compiler errors or linker errors there will be no confr.exe, just error
messages that you will have to take care of first.
Regards,
Klas
mmj0426
different debugging world that is!!
Anyway, I hope I've found the problem. While stepping through, it
fails at this part of the code:
*--------------------------------------
* Parse out an index name
*--------------------------------------
K = at( [,], NDX_LIST)
I = I + 1
S = ltrim( str( I))
if K = 0
NDX_&S = NDX_LIST
NDX_LIST = ""
else
NDX_&S = left( NDX_LIST, K-1)
NDX_LIST = right( NDX_LIST, len( NDX_LIST)-K)
endif
For the variable "NDX_&S", the watchpoint gives a value of "syntax
error". Is it possible that I need to replace the "&" with something
else for Harbour?
matt johnson
From: mmj0426 <mmj...@aol.com>
To: Harbour Users <harbou...@googlegroups.com>
Sent: Thursday, August 18, 2011 12:03 PM
Subject: [harbour-users] Re: Converting Clipper Summer 87 to Harbour. Getting errors........
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Unsubscribe: harbour-users+unsub...@googlegroups.com
Web: http://groups.google.com/group/harbour-users
silvio falconi
Unsubscribe: harbour-user...@googlegroups.com
Web: http://groups.google.com/group/harbour-users
Falconi Silvio
Questo messaggio di posta elettronica e tutti i file allegati contengono informazioni confidenziali e riservate. Nel caso si sia venuti in possesso di tali informazioni senza averne l’autorizzazione o nel caso non foste i destinatari di tale messaggio si prega di avvertire il mittente e di non diffondere o comunicare a terzi di quanto si possa essere venuti a conoscenza.
This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system.
Informativa art. 13 D.lgs 196/2003 - Codice della Privacy
Ai sensi dell'articolo 13 del Codice in materia di dati personali si informa che il trattamento dei Suoi dati personali, anche sensibili, compreso l’indirizzo di posta elettronica, sono trattati nel rispetto del D.Lgs. 196/03.
I dati saranno trattati sia in forma scritta, sia elettronica da personale incaricato, che potrà avere acceso ai soli dati necessari alla gestione delle attività del servizio richiesto. Potranno venire a conoscenza dei Suoi dati personali gli incaricati di segreteria interni, commercializzazione di beni e servizi, incaricati della contabilità e fatturazione nonché gli incaricati della gestione e manutenzione dei sistemi di elaborazione. I dati non saranno oggetto di comunicazione o diffusione a terzi, se non per i necessari adempimenti contrattuali o per obblighi di legge. Le ricordiamo infine che Le sono riconosciuti i diritti di cui all’art. 7 del D.lgs.196/2003.
mmj0426
No, it still shows that it's a syntax error.
On Aug 18, 3:23 pm, matt johnson <mattfrien...@yahoo.com> wrote:
> try to put a "." at the end of the macro, to stop macro expansion. IE NDX_&S becomes NDX_&S.
>
> ________________________________
> Web:http://groups.google.com/group/harbour-users- Hide quoted text -
Fernando Yurisich
mmj0426
No, the compiler caught that one.
On Aug 18, 3:47 pm, Fernando Yurisich <fernando.yuris...@gmail.com>
wrote:
>
> NDX_&(S)
>
> Regards
> Fernando Yurisich
> Montevideo, Uruguay
>
> > > - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Harbour Users" group.
> > Unsubscribe: harbour-user...@googlegroups.com
> > Web:http://groups.google.com/group/harbour-users
>
> --
> Fernando Yurisich
Klas Engwall
> ndx not possible
> use cdx pls
If you really read the code you will see that "NDX" is just a part of a
variable name. It could have been "TEMP" instead. Or "SILVIO" :-). So
which RDD is used in the application is irrelevant in this code.
Regards,
Klas
Klas Engwall
> Thanks Klas, that explanation worked beautifully for me. What a
> different debugging world that is!!
:-)
> Anyway, I hope I've found the problem. While stepping through, it
> fails at this part of the code:
>
> *--------------------------------------
> * Parse out an index name
> *--------------------------------------
> K = at( [,], NDX_LIST)
> I = I + 1
> S = ltrim( str( I))
> if K = 0
> NDX_&S = NDX_LIST
> NDX_LIST = ""
> else
> NDX_&S = left( NDX_LIST, K-1)
> NDX_LIST = right( NDX_LIST, len( NDX_LIST)-K)
> endif
>
>
> For the variable "NDX_&S", the watchpoint gives a value of "syntax
> error". Is it possible that I need to replace the "&" with something
> else for Harbour?
What the original programmer does here is that he creates strings from
numbers. But what you are not showing here is the context, where
everything happens in a loop (we could see the complete function in your
post on July 19). When the loop interates, it increments I, which is
originally 0, to 1, 2, 3 etc. Then he stringifies I in the S variable to
"1", "2", "3" etc. Next he creates a bunch of new variables, NDX_1,
NDX_2, NDX_3 etc and assigns a piece of the NDX_LIST string to each of
those variables using a macro. That is where the "&" character comes in.
In the complete code for the function I can see that the S variable is a
private one, so the macro substitution (in NDX_&S) will work. If S were
a local variable like I and K are, you would get a "Macro of declared
symbol" error from the compiler, and you would not get an exe to run.
I wrapped the code above in a few additionan lines from what you posted
last time, and it works just fine as long as the file name variables
(NDX_1, NDX_2 etc) are correct.
Since we last talked about this particular function you have restarted
the project from scratch. This probably means that a couple of bugs that
I spotted in the code then are back. Here is the first one:
> local I, K, P
> private S, NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
> NDX_9, NDX_10
> store "" to NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
> NDX_9, NDX_1
There is a typo here. the last part of the last line should read NDX_10
instead of NDX_1 to match the line above it.
Later there is another problem:
> set index to&NDX_1.,&NDX_2.,&NDX_3.,&NDX_4.,&NDX_5.,&NDX_6.,
> &NDX_7.,
I don't remember what you said about it possibly being a cut and paste
problem, but there are three more variable names missing at the end:
&NDX_8,; &NDX_9,; &NDX_10.
These need to be fixed, but I am not sure that they are the real
problem. Take a look at all the NDX_<number> variables right before the
"set index to" line in my last quote, either in the debugger or by
temporarily adding a few more lines right before that same line:
? NDX_1
? NDX_2
<etc, up to>
? NDX_10
This should display the file names that were passed in the NDX_LIST
argument up to the point where there are no more names left, as this
function knows them at that moment. Then it will crash because there are
fewer than 10 index file names in NDX_LIST. But before it dies you
should see those names on screen. That will show you that the name
extraction loop works after all.
Do you know that the dbf file was actually opened? Have you checked that
there were no errors in the OPEN_DBFS() function? The debugger should be
able to show you that the alias of the opened dbf exists. Or add the
temporary lines I suggested with and extra
? alias()
before ? NDX_1, and the dbf name should show up before the list of index
file names.
Regards,
Klas
Klas Engwall
> For the variable "NDX_&S", the watchpoint gives a value of "syntax
> error".
In addition to what I said last night:
You probably typed NDX_&S into the debugger to inspect the value of a
variable of that name and got the syntax error message back. The error
is not referring to the code the debugger is running but to what you
typed while in the debugger, and the reason is that there is no such
variable and there cannot be a variable with a "&" character in its
name. "NDX_&S" is a macro.
If you type NDX_1 or NDX_2 etc instead you will see the value of those
variables. "NDX_&S" is a macro that means "the variable whose name
begins with NDX and an underscore and ends with whatever is in the S
variable at the moment". And the S variable holds a stringified version
of the number in the I variable, a "1" or a "2" etc. So you gave the
debugger a macro, and it did not know what to do with it.
That is what I think happened.
Regards,
Klas
mmj0426
this today.
You are right, I did type NDX_&S into the debugger and that is why I
got that error. After looking at this again and again (by debugging)
I'm still not exactly sure what happens because I never really get an
error message when I am debugging. I sure was hoping that the problem
was that "&". But since that's not the case.........
You spoke of those syntax errors. That was a cut and paste mistake on
my part so all of that was good.
I typed in the ?alias() and ?NDX_1 and so forth where you told me and
there are seven names that eventually pop up on the screen. Then, the
system freezes. I hit enter and that's when i get my original error
again. What I don't understand is that the first name that comes up
is a dbf but the other 6 are ntx file names. I am posting the code
for the function USE_DBFS()......
*----------------------------------------------------------------------
* USE_DBFS() Open a list of files & indices
*----------------------------------------------------------------------
function USE_DBFS
parameters P_1, P_2, P_3, P_4, P_5, P_6, P_7, P_8, P_9, P_10, P_11,
P_12, P_13, P_14, P_15, P_16, P_17, P_18, P_19, P_20
private I, S, P, DBF, NDX, K, USER_QUIT
USER_QUIT = .F.
I = 1
do while I <= pcount() .and. .not. USER_QUIT
* Get the parm
*-------------
S = ltrim( str( I))
* Parse out the database & index names
*-------------------------------------
K = at( [,], P)
if K = 0
DBF = P
else
DBF = left( P, K-1)
NDX = right( P, len( P)-K)
endif
* Try and open the files
*-----------------------
select &S
if .not. USE_DBF( DBF)
USER_QUIT = .T.
elseif K <> 0
if .not. USE_NDXS( NDX)
USER_QUIT = .T.
endif
endif
* Next database
*--------------
return .not. USER_QUIT
Now, this function also calls USE_DBF which is:
*----------------------------*
* USE_DBF
*----------------------------*
function USE_DBF
parameters DBF_NAME
private TRY_AGAIN, DONE, ALI, ALI_POS
DISP_MSG( "Opening database "+ DBF_NAME)
ALI_POS = at( " ALIAS ", upper( DBF_NAME))
if ALI_POS <> 0 .and. ALI_POS < len( DBF_NAME) <----It does
not hit here because ALI_POS = 0.
ALI = substr( DBF_NAME, ALI_POS+7)
DBF_NAME = left( DBF_NAME, ALI_POS)
use &DBF_NAME. alias &ALI
else
use &DBF_NAME
endif
DONE = .not. neterr()
if .not. DONE <-----
It does not go through this If statement.
TRY_AGAIN = "Y"
do SAV_SCRN
do while (.not. DONE) .and. (TRY_AGAIN = "Y")
do DISP_MSG with "Can't open "+ DBF_NAME +".DBF at this time. Try
again? "
@ row(), col() get TRY_AGAIN pict "!"
read
if TRY_AGAIN = "Y"
if ALI_POS <> 0 .and. ALI_POS < len( DBF_NAME)
use &DBF_NAME. alias &ALI
else
use &DBF_NAME
endif
DONE = .not. neterr()
endif
enddo
do RST_SCRN
endif
if type( "SEE_OPENS") <> "U"
DISP_MSG( "")
endif
return DONE
My screen does display the message "Opening database CASES" and I
notice that the "access date" changes so I believe that the database
does open.
All along, I never get an error message.
The actual point of death happens as soon as it reaches this line in
the function USE_NDXS:
set index to &NDX_1., &NDX_2., &NDX_3., &NDX_4., &NDX_5., &NDX_6.,
&NDX_7., &NDX_8., &NDX_9., &NDX_10.
It reaches this line, I hit F8 and then my main screen pops up. The
system just hangs until I hit enter to get the original error:
Error DBFNTX/1003 Open error: CAS_NAME.ntx (DOS Error 2)
Called from ORDLISTADD(0)
Called from USE_NDXS(787)
Called from USE_DBFS(189)
Called from CO_MAIN(19)
Called from CONFR(111)
I read somewhere that this error could also mean that there is a
security issue but i checked that and that was fine.
matt johnson
From: mmj0426 <mmj...@aol.com>
To: Harbour Users <harbou...@googlegroups.com>
Sent: Monday, August 22, 2011 12:56 PM
Subject: [harbour-users] Re: Converting Clipper Summer 87 to Harbour. Getting errors........
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Web: http://groups.google.com/group/harbour-users
mmj0426
*-----------------------------------------------------------------------------
*
* USE_NDXS() Open a list of indices
*-----------------------------------------------------------------------------
*
function USE_NDXS
parameter NDX_LIST, DBF
local I, K, P
private S, NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
NDX_9, NDX_10
store "" to NDX_1, NDX_2, NDX_3, NDX_4, NDX_5, NDX_6, NDX_7, NDX_8,
altd()
if( type( "SEE_OPENS")<>"U", DISP_MSG( "Opening index "+ NDX_LIST),
NIL)
I = 0
do while len( NDX_LIST) <> 0
* Parse out an index name
*------------------------
NDX_&S = NDX_LIST
NDX_LIST = ""
else
NDX_&S = left( NDX_LIST, K-1)
NDX_LIST = right( NDX_LIST, len( NDX_LIST)-K)
endif
if rddsetdefault() = "DBFMDX" <------It does not go
through this If statement.
K = rat( [\], NDX_1)
if K = 0
K = rat( [:], NDX_1)
endif
if K <> 0
P = left( NDX_1, K)
NDX_1 = substr( NDX_1, K+1)
endif
set index to (DBF)
set order to tag (ltrim( NDX_1))
else
death right after this line.
endif
if( type( "SEE_OPENS")<>"U", DISP_MSG( ""), NIL)
return .T.
On Aug 22, 4:14 pm, matt johnson <mattfrien...@yahoo.com> wrote:
> DOS error 2 is file not found. Maybe there is a capitalization issue .NTX instead of .ntx. Maybe a path issue. Maybe you could just replace the whole use_ntx() function with use file index ndx1,ndx2? The file name is 8 characters and the substr function looks for 7 chars? ALI = substr( DBF_NAME, ALI_POS+7) Perhaps you could post the actual use_ntx function?
>
> regards, Matt
>
> ________________________________
> Web:http://groups.google.com/group/harbour-users- Hide quoted text -
matt johnson
&NDX_7., &NDX_8., &NDX_9., &NDX_10. <----------Point of
From: mmj0426 <mmj...@aol.com>
To: Harbour Users <harbou...@googlegroups.com>
Sent: Monday, August 22, 2011 1:45 PM
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Web: http://groups.google.com/group/harbour-users
mmj0426
I finally found the problem. I should have noticed this before. I
tried different capitalizations and that made no difference. I tried
using:
set index to &NDX_1
set index to &NDX_2 and so forth and noticed all files were there and
even though I knew the .ntx files were in the directory I added SET
PATH TO command just to make sure. Then I noticed when I really
looked at the values of NDX_1 and so on that the value had a space in
front of it. I added the 'alltrim' function and all is well.
I'm not saying I won't be back, but I'm hoping there will be no more
issues. I see another error but I know how to fix this one.
I'm sorry I didn't notice the space issue earlier and wasted time.
I want to thank you all for helping me!! I REALLY do appreciate
it!!
On Aug 22, 6:10 pm, matt johnson <mattfrien...@yahoo.com> wrote:
> Have you checked that CAS_NAME.ntx is there?
>
> Instead of set index to &NDX_1., &NDX_2., &NDX_3., &NDX_4., &NDX_5., &NDX_6.,
> &NDX_7., &NDX_8., &NDX_9., &NDX_10. <----------Point of
>
> try
>
> set index to &NDX_1.
>
> set index to &NDX_1., &NDX_2.
>
> set index to &NDX_1., &NDX_2., &NDX_3.
>
> this could show which NDX_number is missing.
>
> ________________________________
> Subject: [harbour-users] Re: Converting Clipper Summer 87 to Harbour. Getting errors........
>
> Sure and thanks! The code for USE_NDXS() is:
>
> * USE_NDXS() Open a list of indices
> > Web:http://groups.google.com/group/harbour-users-Hide quoted text -
> > - Show quoted text -
>
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
Klas Engwall
> I finally found the problem.
[...]
> ... Then I noticed when I really
> looked at the values of NDX_1 and so on that the value had a space in
> front of it. I added the 'alltrim' function and all is well.
It had to be something simple :-)
> I'm not saying I won't be back, but I'm hoping there will be no more
> issues. I see another error but I know how to fix this one.
We all come back, and we all learn something from that.
> I'm sorry I didn't notice the space issue earlier and wasted time.
>
> I want to thank you all for helping me!! I REALLY do appreciate
> it!!
You're welcome. Time for cake now :-)
Regards,
Klas
matt johnson
From: mmj0426 <mmj...@aol.com>
To: Harbour Users <harbou...@googlegroups.com>
Sent: Tuesday, August 23, 2011 7:21 AM
> > Web:http://groups.google.com/group/harbour-users-Hide quoted text -
>
> > - Show quoted text -
>
> --
> You received this message because you are subscribed to the Google
> Groups "Harbour Users" group.
You received this message because you are subscribed to the Google
Groups "Harbour Users" group.
Web: http://groups.google.com/group/harbour-users