[Harbour] Win 7 64-bit "hello world" simple compile error
Hi, I posted this question on the users- mailling list, with no replies. Perhaps it's a bit more developer suited. Hopefully I am not intruding by posting this here. 1. Why can't I compile my Hello World program on my Windows 7 x64 OS? C:\hb20\bin>hbmk2.exe hello.prg hbmk2: Processing configuration: C:\hb20\bin\hbmk.cfg Harbour 2.0.0 (Rev. 13372) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'hello.prg'... Lines 1, Functions/Procedures 1 Generating C source output to 'hello.c'... Done. C:/hb20/lib/win/mingw/libhbvm.a(hvmall.o):hvmall.c:(.text+0x2e23): undefined r eference to `__mingw_vprintf' C:/hb20/lib/win/mingw/libhbvm.a(hvmall.o):hvmall.c:(.text+0x359b): undefined r eference to `__mingw_vfprintf' collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc.exe hello.o hbmk_mn4kgp.o-mconsole -Wl,--start-group -lhbextern -lhbdebu g -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgt gui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -l hbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 - ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -lo leaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -W l,--end-group -ohello.exe -L"C:/hb20/lib/win/mingw" *Note: I also found and read the HARBOUR_README_MINGW64 file. The instructions were a bit vague, as the link it provides gives you many options of what to install and no hint as to which one you need. But with my brother's help, he picked out likely the one to use, and it didn't make any difference on this issue. Nor did reinstalling Harbour 2.0.0 with every option installed in the Wizard. *sad face** PS: If anyone knows the answer / solution, I will keep track of it on my Harbour blog: http://209.97.219.2/sjohnson . If anyone cares to look through it and answer some of the other questions, I'd be happy to put them in there too. If someone wants to go the extra mile and participate with me through email and answer all the questions or any simple ones I come up with in hopes to improve the documentation as quick as possible, I'd be very excited and motivated to do so. Thank you for reading. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Win 7 64-bit "hello world" simple compile error
I reinstalled Harbour and selected every checkbox during the install process, so I don't think I purposely chose to leave anything out. I also never have installed MinGW prior to trying Harbour on that machine... But I will probably take a trip down to work tomorrow (where the machine is) and post what I can, since I will be near there anyway. I appreciate the response! On Sun, Jan 24, 2010 at 1:29 AM, Viktor Szakáts wrote: > Hi Smu, > > > I posted this question on the users- mailling list, with no replies. > Perhaps it's a bit more developer suited. Hopefully I am not intruding by > posting this here. > > • Why can't I compile my Hello World program on my Windows 7 x64 > OS? > > C:\hb20\bin>hbmk2.exe hello.prg > > hbmk2: Processing configuration: C:\hb20\bin\hbmk.cfg > > Harbour 2.0.0 (Rev. 13372) > > Copyright (c) 1999-2010, http://www.harbour-project.org/ > > > > Compiling 'hello.prg'... > > > > Lines 1, Functions/Procedures 1 > > Generating C source output to 'hello.c'... Done. > > C:/hb20/lib/win/mingw/libhbvm.a(hvmall.o):hvmall.c:(.text+0x2e23): > undefined r > > eference to `__mingw_vprintf' > > > > C:/hb20/lib/win/mingw/libhbvm.a(hvmall.o):hvmall.c:(.text+0x359b): > undefined r > > > > eference to `__mingw_vfprintf' > > collect2: ld returned 1 exit status > > hbmk2: Error: Running linker. 1 > > gcc.exe hello.o hbmk_mn4kgp.o-mconsole -Wl,--start-group -lhbextern > -lhbdebu > > > > g -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin > -lgtwvt -lgt > > > > gui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt > -lhbrdd -l > > hbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 > -lgdi32 - > > > > ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid > -lole32 -lo > > > > leaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre > -lhbzlib -W > > l,--end-group -ohello.exe -L"C:/hb20/lib/win/mingw" > > It seems you opted to not install the embedded MinGW compiler, > which means it uses the one you have installed in PATH, and this > one isn't compatible with this Harbour build. > > Can you tell us which MinGW version is this? > > > Note: I also found and read the HARBOUR_README_MINGW64 file. The > instructions were a bit vague, as the link it provides gives you many > options of what to install and no hint as to which one you need. But with my > brother's help, he picked out likely the one to use, and it didn't make any > difference on this issue. Nor did reinstalling Harbour 2.0.0 with every > option installed in the Wizard. *sad face* > > MinGW64 is required only if want to create x64 binaries. > Instruction are vague because no one has time to update > the link every week, plus lately there is both x64 and > x86 native binaries as option (both can be used with > Harbour). MinGW64 is still is development phase and > hopefully they'll make it more obvious what to download > to use it. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Win 7 64-bit "hello world" simple compile error
Viktor, I am ecstatic that you helped me, and correctly guessed what was happening! I was ready to swear I didn't have gcc.exe on my computer, but as it turns out, I did. It comes bundled with Strawberry Perl, a win32 Perl environment, and sets it up for the %PATH% variable. Well I'll be! Actually, to find out what was happening prior to running C:\>path, I ran locate32 (freeware windows filesearch harddrive indexer) and found the problem right away. Again, many thanks for giving me a hint. I will add this to the FAQ page on my end, as hey! It could happen to anyone. On Sun, Jan 24, 2010 at 2:23 AM, Viktor Szakáts wrote: > > I reinstalled Harbour and selected every checkbox during the install > process, so I don't think I purposely chose to leave anything out. I also > never have installed MinGW prior to trying Harbour on that machine... But I > will probably take a trip down to work tomorrow (where the machine is) and > post what I can, since I will be near there anyway. I appreciate the > response! > > In this case I have no idea ATM, I unzipped the .7z > release (should be the same as installing with every > checkbox checked), typed the same thing (with -trace > and I left hello.prg in its original location), and > got this (on Win7 x64 EN): > --- > F:\hb20\bin>hbmk2.exe ..\tests\hello.prg -trace > hbmk2: Processing configuration: F:\hb20\bin\hbmk.cfg > hbmk2: Harbour compiler command (embedded): > (F:\hb20\bin\harbour.exe) -n2 ../tests/hello.prg -iF:/hb20/include > Harbour 2.0.0 (Rev. 13372) > Copyright (c) 1999-2010, http://www.harbour-project.org/ > Compiling '../tests/hello.prg'... > > Lines 11, Functions/Procedures 1 > Generating C source output to 'hello.c'... Done. > hbmk2: C compiler command: > F:\hb20\comp\mingw\bin\gcc.exe -c -O3 -march=i586 -mtune=pentiumpro > -fomit-frame-pointer -Wall -W -IF:/hb20/include hello.c > hbmk2: Linker command: > F:\hb20\comp\mingw\bin\gcc.exe hello.o-mconsole -Wl,--start-group > -lhbextern -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 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool > -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm > -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group > -ohello.exe -LF:/hb20/lib/win/mingw > --- > > Please post your 'set > log.txt' results, maybe we can > spot why hbmk2 chooses an external GCC compiler on your > system. > > Brgds, > Viktor > > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SIxDriver problem with sx_keyadd
Hi,
I heard that Przemek is the guru to ask about SixCDX questions from Viktor.
Well I think I have found a Clipper / Harbour incongruency. (or maybe I'm
going about it the wrong way)... :). In the case below, whenever I use 3
args for SX_KEYADD, and three args are present...
I have included the result, and the code. I had to get someone else who
knew Clipper better than I did to write a Hello World-sized app to reproduce
the error. Problem is, this never was an issue when using Clipper 5.2e.
I have found that if i just use two params instead of three, I get no
errors, (though I'm quite sure it is because something completely different
is being accomplished, that I wouldn't want).
The execution:
C:\hbm>hello.exe
Error DBFNTX/1052 Unknown error
Called from SX_KEYADD(0)
Called from HELLO(11)
My source code below:
#include "hbsix.ch"
USE DATBASE
INDEX ON SXCHAR(10) TAG "MIKEY" OF TEMP
DBGOTOP()
DO WHILE !EOF()
IF SX_KEYADD("mikey",1,padr("mike",10))
WAIT
ENDIF
DBSKIP()
ENDDO
---
By the way, the DATBASE is an arbitrary .dbf I picked. I picked some other
.dbf files I had handy, and the same thing occured.
Many thanks in advance. :)
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] -z switch seems to be overly anti-lazy
Hi! I noticed the -z switch allows to stop using shortcuts for .and. and .or. Clipper conditions. Without -z, if I do: eval(something) .or. .t. // will recognize that it's already true, and not make the eval When -z is enabled: .f. .and. eval(something) // will try to eval 'something', despite the fact that .f. already failed. ... If what I said is actually true, is there any sort of secondary -z switch that can be done to make it simply not be lazy, yet fail on first condition? ... If what I said is complete nonsense and complete BS, I will have to go through the code I'm trying to compile that someone else wrote and see what's up. By the way, I realize that the above examples are not the best way to do things... and I sure as heck wouldn't do it that way myself. Just trying to get some existing Clipper functioning code to behave the same way in Harbour. Thank you for your time. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SIxDriver problem with sx_keyadd
Hi Przemysław,
I appreciate the answer. I don't like hacks either, as I have found some
other hacks that I've had to try to work around. I wrote the EMPTY thing
(as we do use the .ch file) and it solved the problem! So thanks for that.
As far as the question of if you want to implement SIX3 defaults... you
would know a lot better than I would if it's a good idea. I will say one
thing though, it will help Clipper programmers who have had a hard time
getting SIX3 to work back 10 years ago and have stumbled upon it "just
working" back then...
Since Harbour seems to be 100% Clipper compliant, I would think it would be
a good idea. But then again, I don't like hacks either :( So it is really
your call.
One last question though, if I may. How often do I have to worry about this
EMPTY / CUSTOM addition? Is it just whenever I want to use sx_keyadd? Or
are there other pitfalls I should look out for.
Thanks for your quick answer!
2010/1/28 Przemysław Czerpak
> On Thu, 28 Jan 2010, smu johnson wrote:
>
> Hi,
>
> > I heard that Przemek is the guru to ask about SixCDX questions from
> Viktor.
> > Well I think I have found a Clipper / Harbour incongruency. (or maybe
> I'm
> > going about it the wrong way)... :). In the case below, whenever I use 3
> > args for SX_KEYADD, and three args are present...
> > I have included the result, and the code. I had to get someone else who
> > knew Clipper better than I did to write a Hello World-sized app to
> reproduce
> > the error. Problem is, this never was an issue when using Clipper 5.2e.
> > I have found that if i just use two params instead of three, I get no
> > errors, (though I'm quite sure it is because something completely
> different
> > is being accomplished, that I wouldn't want).
> > The execution:
> > C:\hbm>hello.exe
> > Error DBFNTX/1052 Unknown error
> > Called from SX_KEYADD(0)
> > Called from HELLO(11)
> > My source code below:
> > #include "hbsix.ch"
> > USE DATBASE
> > INDEX ON SXCHAR(10) TAG "MIKEY" OF TEMP
> > DBGOTOP()
> > DO WHILE !EOF()
> > IF SX_KEYADD("mikey",1,padr("mike",10))
> > WAIT
> > ENDIF
> > DBSKIP()
> > ENDDO
> > ---
> > By the way, the DATBASE is an arbitrary .dbf I picked. I picked some
> other
> > .dbf files I had handy, and the same thing occured.
>
> In this example you are using DBFNTX and the code you create use
> some hidden SIX3 SIXCDX feature.
> In SIX3 if index expression starts with "SXCHAR(", "SXDATE(", "SXNUM("
> or "SXLOG(" then it's automatically marked as TEMPLATE index which is
> EMPTY. It also means that above code in Clipper does not execute
> SX_KEYADD()
> even once because after:
>INDEX ON SXCHAR(10) TAG "MIKEY" OF TEMP
> empty index is created and it's set as controlling index.
> I intentionally haven't replicated this behavior in core RDD though
> in SIXCDX Harbour RDD there is inactive initial code which enables it
> (see src/rdd/dbfcdx/dbfcdx1[3497]). I simply do not like such hacks
> (some partial key expression analyzes to create completely different
> index) so in Harbour you have to explicitly use CUSTOM or EMPTY clause
> in INDEX ON command to create indexes where you can manually add and
> delete keys using sx_keyAdd()/sx_keyDel() or ordKeyAdd()/ordKeyDel():
> INDEX ON SXCHAR(10) TAG "MIKEY" OF TEMP EMPTY
> or is you do not use hbsix.ch:
> INDEX ON SXCHAR(10) TAG "MIKEY" TO TEMP CUSTOM
> otherwise above RTE is generated. 1052 is CL53 DBFCDX compatible error
> when user tries to execute key add or del operation on normal non custom
> index. If it's really big problem then I can change it in Harbour SIXCDX
> RDD to work like SIX3 RDD (without above RTE and with automatic TEMPLATE
> index attribute setting) but I cannot touch DBFCDX and other RDDs where
> I would like to keep more strict behavior which is also CL53 DBFCDX/COMIX
> compatible.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
Thanks for the reply. As far as I can tell, I have found a difference in Clipper and Harbour in terms of these evaluations. But as I said earlier, I could be completely mistaken. I have done a lot of little tests to check the -z flag but unfortunately I'm not that good at Clipper as one of my friends is. (I'm better at Perl, etc). But if I can demonstrate the problem in a small Hello World type example, I will post it, to try to figure out what is happening, with your help. :) The only reason I bring this up, is because I am trying to compile an old DOS16 app and it is behaving differently on these .or. lines. Thanks again for reading!!! I have read your informative reply, and will test what you said out for myself to try to figure out what is going on. 2010/1/28 Przemysław Czerpak > On Thu, 28 Jan 2010, smu johnson wrote: > > Hi! > > > I noticed the -z switch allows to stop using shortcuts for .and. and .or. > > Clipper conditions. > > Without -z, if I do: > > eval(something) .or. .t. // will recognize that it's already true, and > not > > make the eval > > When -z is enabled: > > .f. .and. eval(something) // will try to eval 'something', despite the > fact > > that .f. already failed. > > Exactly just like in Clipper. > > > ... If what I said is actually true, is there any sort of secondary -z > > switch that can be done to make it simply not be lazy, yet fail on first > > condition? > > It's default behavior. Just simply do not use -z or better use the same > switches as in Clipper. > > > ... If what I said is complete nonsense and complete BS, I will have to > go > > through the code I'm trying to compile that someone else wrote and see > > what's up. By the way, I realize that the above examples are not the > best > > way to do things... and I sure as heck wouldn't do it that way myself. > Just > > trying to get some existing Clipper functioning code to behave the same > way > > in Harbour. > > You mixed two different things which confuse you: > 1. compile time optimizations > 2. lazy boolean expression evaluation > > Both Harbour and Clipper support -z switch to control lazy expression > evaluation. It works in the same way. This code illustrate it: > > proc main() > local f:=.F., t:=.T. > ?; ?? .t. .or. f() > ?; ?? .f. .and. f() > ?; ?? f() .or. .t. > ?; ?? f() .and. .f. > ? > ?; ?? t .or. f() > ?; ?? f .and. f() > ?; ?? f() .or. t > ?; ?? f() .and. f > ? > return > func f() > ?? "[F()] " > return .T. > > compile it with and without -z switch using Harbour and Clipper and > compare results. Please note that when -z is not used then first 4 > expressions are optimized at compile time and next 4 ones are optimized > at runtime. Compile time optimization calculates final result and > replace the code with simple .F. or .T. so F() function is never > execute. It's also Clipper compatible behavior. > Anyhow Clipper does not optimize all expressions (i.e. it does not > optimize if message is send to it: :msg()) and cannot strip > parenthesis in optimization process. Harbour does not make any exceptions > here and optimize all end everywhere if it's possible what seems to be > correct behavior. You can add these lines to above test to see the > difference: > > ?; ?? (.t.) .or. f() > ?; ?? (.f.) .and. f() > ?; ?? f() .or. (.t.) > ?; ?? f() .and. (.f.) > ? > ?; ?? ( .t. .or. f() ):classname > ?; ?? ( .f. .and. f() ):classname > ?; ?? ( f() .or. .t. ):classname > ?; ?? ( f() .and. .f. ):classname > ? > > compile it without -z switch and compare Clipper and Harbour results. > If you want to replicate also this Clipper behavior then you can use > -kc switch which disables all Harbour extensions though I cannot promise > that we located all places were Clipper does not make compile time > optimization and added necessary protection for -kc switch. If you will > find sth then please inform us. We try to cover it by -kc switch or > document the difference. Such missing optimizations in chosen places > for me are bugs which should be eliminated to not create some hidden > and not understandable for users exception so I've never tried to make > precise test to detect all such Clipper anomalies. > If you want to read more about compile time optimizations then read > docs/cmpopt.txt > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SIxDriver problem with sx_keyadd
Thank you Przemek. When it is done, could you please post in this thread? I suppose then, I would have to figure out how to get this incorporated with the 2.0.0 version of Harbour I am using now on Windows. *many thanks* 2010/1/28 Przemysław Czerpak > On Thu, 28 Jan 2010, Szak�ts Viktor wrote:, > > Hi Viktor, > > > > INDEX ON SXCHAR(10) TAG "MIKEY" OF TEMP EMPTY > > > or is you do not use hbsix.ch: > > > INDEX ON SXCHAR(10) TAG "MIKEY" TO TEMP CUSTOM > > > otherwise above RTE is generated. 1052 is CL53 DBFCDX compatible error > > > when user tries to execute key add or del operation on normal non > custom > > > index. If it's really big problem then I can change it in Harbour > SIXCDX > > > RDD to work like SIX3 RDD (without above RTE and with automatic > TEMPLATE > > > index attribute setting) but I cannot touch DBFCDX and other RDDs where > > > I would like to keep more strict behavior which is also CL53 > DBFCDX/COMIX > > > compatible. > > I tend to agree to enable this (really not very good looking) > > hack in SIXCDX to make it more compatible. This way anyone > > can use it for initial port without modifying code, then can > > clean in a separate step and switch to hack-free DBFCDX. > > OK, I'll make such modifications soon. > > best regards, > Przemek > ___________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
It looks like I'm going to have to wait till my boss wakes up. I can't for the life of me figure out how to make an .EXE from an .OBJ from Clipper. Why couldn't they just make this easy, like hbmk2? *huge anger at software makers*. Oh well. I will have to wait about 3 hours until my boss comes to work... another sleepless night. 2010/1/28 Przemysław Czerpak > On Thu, 28 Jan 2010, smu johnson wrote: > > Hi! > > > I noticed the -z switch allows to stop using shortcuts for .and. and .or. > > Clipper conditions. > > Without -z, if I do: > > eval(something) .or. .t. // will recognize that it's already true, and > not > > make the eval > > When -z is enabled: > > .f. .and. eval(something) // will try to eval 'something', despite the > fact > > that .f. already failed. > > Exactly just like in Clipper. > > > ... If what I said is actually true, is there any sort of secondary -z > > switch that can be done to make it simply not be lazy, yet fail on first > > condition? > > It's default behavior. Just simply do not use -z or better use the same > switches as in Clipper. > > > ... If what I said is complete nonsense and complete BS, I will have to > go > > through the code I'm trying to compile that someone else wrote and see > > what's up. By the way, I realize that the above examples are not the > best > > way to do things... and I sure as heck wouldn't do it that way myself. > Just > > trying to get some existing Clipper functioning code to behave the same > way > > in Harbour. > > You mixed two different things which confuse you: > 1. compile time optimizations > 2. lazy boolean expression evaluation > > Both Harbour and Clipper support -z switch to control lazy expression > evaluation. It works in the same way. This code illustrate it: > > proc main() > local f:=.F., t:=.T. > ?; ?? .t. .or. f() > ?; ?? .f. .and. f() > ?; ?? f() .or. .t. > ?; ?? f() .and. .f. > ? > ?; ?? t .or. f() > ?; ?? f .and. f() > ?; ?? f() .or. t > ?; ?? f() .and. f > ? > return > func f() > ?? "[F()] " > return .T. > > compile it with and without -z switch using Harbour and Clipper and > compare results. Please note that when -z is not used then first 4 > expressions are optimized at compile time and next 4 ones are optimized > at runtime. Compile time optimization calculates final result and > replace the code with simple .F. or .T. so F() function is never > execute. It's also Clipper compatible behavior. > Anyhow Clipper does not optimize all expressions (i.e. it does not > optimize if message is send to it: :msg()) and cannot strip > parenthesis in optimization process. Harbour does not make any exceptions > here and optimize all end everywhere if it's possible what seems to be > correct behavior. You can add these lines to above test to see the > difference: > > ?; ?? (.t.) .or. f() > ?; ?? (.f.) .and. f() > ?; ?? f() .or. (.t.) > ?; ?? f() .and. (.f.) > ? > ?; ?? ( .t. .or. f() ):classname > ?; ?? ( .f. .and. f() ):classname > ?; ?? ( f() .or. .t. ):classname > ?; ?? ( f() .and. .f. ):classname > ? > > compile it without -z switch and compare Clipper and Harbour results. > If you want to replicate also this Clipper behavior then you can use > -kc switch which disables all Harbour extensions though I cannot promise > that we located all places were Clipper does not make compile time > optimization and added necessary protection for -kc switch. If you will > find sth then please inform us. We try to cover it by -kc switch or > document the difference. Such missing optimizations in chosen places > for me are bugs which should be eliminated to not create some hidden > and not understandable for users exception so I've never tried to make > precise test to detect all such Clipper anomalies. > If you want to read more about compile time optimizations then read > docs/cmpopt.txt > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SIxDriver problem with sx_keyadd
Wow, great answer. Maybe I should stop using SIX3 entirely. Any other
Harbour compatible database formats you would recommend for the transition,
to avoid all these bugs? Hopefully it isn't hard to convert SIX3 to
whatever you suggest. If I can keep using a file-based database instead of
having to connect to a Mysql server for example, that would obviously be
more convenient for what I am doing.
Also,
> It should be add only to INDEX ON command which create index with key
> expression starting with "sxChar(", "sxNum(", "sxDate(" or "sxLog(".
> That's all.
I changed:
index on sxChar(11) tag "Keyword" of (fTemp)
To:
index on sxChar(11) tag "Keyword" of (fTemp) EMPTY
... and the problem doesn't come back! :) I tried to follow your
instructions as best I could. Did I do it correctly? (I just want to
double check)
Thank you!!! By the way, you really know your stuff about Clipper!
2010/1/28 Przemysław Czerpak
> On Thu, 28 Jan 2010, smu johnson wrote:
>
> Hi,
>
> > I appreciate the answer. I don't like hacks either, as I have found some
> > other hacks that I've had to try to work around. I wrote the EMPTY thing
> > (as we do use the .ch file) and it solved the problem! So thanks for
> that.
> > As far as the question of if you want to implement SIX3 defaults... you
> > would know a lot better than I would if it's a good idea.
>
> Please only remember that it should not be used for normal indexes.
>
> > I will say one
> > thing though, it will help Clipper programmers who have had a hard time
> > getting SIX3 to work back 10 years ago and have stumbled upon it "just
> > working" back then...
> > Since Harbour seems to be 100% Clipper compliant, I would think it would
> be
> > a good idea. But then again, I don't like hacks either :( So it is
> really
> > your call.
>
> SIX3 RDDs are not Clipper part. I know that they are very popular and
> I also have SIX3.02 package but when I begin to make deeper tests with
> this library I've found such many serious bugs that in my opinion it
> was never fully production ready. Buffer overflows, memory corruptions,
> index file corruption, memo and data file corruptions, wrongly updated
> index files, problems with accessing some valid indexes files, etc.
> I can understand that someone make a mistake and the code should be
> fixed but in few cases they intentionally introduced hacks which cannot
> work and _HAVE_ to give wrong results and this causes that I stop to
> trust Successware and their products. This code quite well illustrate it:
>
> request SIXCDX
> proc main()
> field FINT
> rddSetDefault( "SIXCDX" )
> dbcreate( "_tst", { { "FINT", "V", 4, 0 } } )
> use _tst
> dbappend()
> FINT := 538976287; ? FINT
> FINT := 538976288; ? FINT
> FINT := 538976289; ? FINT
> return
>
> This code compiled by Clipper and linked with SIX3 SIXCDX RDD shows:
> 538976287
> 0
> 538976289
> Funny isn't it?
> What is amazing in 538976288 number that it cannot be stored in V4
> fields giving 0 as result?
> Its binary representation is equal to space(4) and spaces are used
> as default initialization value in DBF record. It means that someone
> hacked in SIX3 code that exactly this value (538976288) when read from
> DBF record is translated to 0. He had to know that such hack breaks
> this field usage and it's a bug which can cause very serious problems
> for users. But it is very hard to locate such bug for normal users who
> do not know what should be tested so it was not creating SIX3 selling
> problems and was accepted in the final product. Maybe they didn't have
> wrong motivation but in my opinion such things should never happen.
>
> Some anomalies which are not critical I replicated in SIXCDX and HBSIX
> library but for sure I cannot replicate hacks like above only to be
> bug compatible. In case of Clipper I usually try to document all anomalies
> but there are too much problems with SIX3 library to address all of them
> so it would be waste of time.
>
> > One last question though, if I may. How often do I have to worry about
> this
> > EMPTY / CUSTOM addition? Is it just whenever I want to use sx_keyadd?
> Or
> > are there other pitfalls I should look out for.
>
> It should be add only to INDEX ON command which create index with key
> expression starting with "sxChar(", "sxNum(", "sxDate(" or "sxLog(".
> That's all.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] hbct FILEATTR() function not working.
It appears the FILEATTR() function doesn't work.
According to http://www.ousob.com/ng/tools1-3/ng935ab.php , it says it
should return a bit-wise decimal number. I tried a few different ways...
absolute path, relative, and a piece of code my brother found from the
Harbour source files.
___Pre-test:
C:\hbm>attrib hello.prg
A HC:\hbm\hello.prg
___Result:
C:\hbm>hello.exe
0
0
0
___code
FUNCTION main()
? FILEATTR("hello.prg")
? FILEATTR("C:\hbm\hello.prg")
cFile := FILESEEK("hello.prg")
DO WHILE .NOT. EMPTY (cFile)
? cFile, FILEATTR()
cFile := FILESEEK()
ENDDO
return
// end
Have I found a bug? :3
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Possible bug: KSETNUM (hbct)
Clipper tools possible bug, KSETNUM. The syntax says: KSETNUM ([]) -> lOldSwitch But what really happens, is that ? KSETNUM(.T.) prints whether or not NUMLOCK is on or not, using .T. / .F.. It doesn't actually change Numlock, as the SYNOPSIS says it does. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbct FILEATTR() function not working.
Oh... the only reason I kept using these functions was because Norton Guides
lists them so nicely...
I will try to look through ChangeLog, but I have found that it is quite
difficult to grab functions from there, as it is not presented in a nice
list. But I will give it a shot.
Thanks
On Sat, Jan 30, 2010 at 3:42 AM, Viktor Szakáts wrote:
> Hi,
>
> Aside from the bug, I suggest to use Harbour core functions
> wherever they exist, in this case they are HB_FGETATTR() and
> HB_FSETATTR(). There is also HB_FGETDATETIME(), HB_FSETDATETIME().
>
> There is also HB_FSIZE(), etc.
>
> Many time these are documented in ChangeLog.
>
> Brgds,
> Viktor
>
> On 2010 Jan 30, at 10:19, smu johnson wrote:
>
> > It appears the FILEATTR() function doesn't work.
> >
> > According to http://www.ousob.com/ng/tools1-3/ng935ab.php , it says it
> should return a bit-wise decimal number. I tried a few different ways...
> absolute path, relative, and a piece of code my brother found from the
> Harbour source files.
> >
> > ___Pre-test:
> >
> > C:\hbm>attrib hello.prg
> > A HC:\hbm\hello.prg
> >
> > ___Result:
> >
> > C:\hbm>hello.exe
> >
> > 0
> > 0
> > 0
> >
> > ___code
> >
> > FUNCTION main()
> >
> > ? FILEATTR("hello.prg")
> > ? FILEATTR("C:\hbm\hello.prg")
> >
> > cFile := FILESEEK("hello.prg")
> > DO WHILE .NOT. EMPTY (cFile)
> > ? cFile, FILEATTR()
> > cFile := FILESEEK()
> > ENDDO
> >
> > return
> > // end
> >
> >
> > Have I found a bug? :3
> >
> > --
> > smu johnson
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbct FILEATTR() function not working.
Przemek:
1) The DO WHILE loop (3rd example out of my list of three examples) I ran
in the first message in this thread actually will return the decimal data.
In my post, it couldn't find the file, because it's attrib was +h, hidden.
:)
2) The first two " ? FILEATTR " examples I wrote, are indeed a bug like you
mentioned.
3) What my goal is, is to simply implement an attribute changer, to remove
things like -h, -s, -r dos attrib switches a file... without having to read
in the current bitwise decimal, do an AND / XOR on it, and then reset it.
FUNCKy lets you avoid all that by you supplying a T/F flag that either sets,
or disables the attribs, based simply the bitwise decimals you want to
adjust. Is there an HB_ function to do this? I looked at the change log
and grep'd around, but couldn't make sense out of some of the stuff because
it wasn't documented. Please give me a hint, if any. If there isn't one to
do this, can you suggest a safe way for me to program it, without me having
to worry that in any new versions of Harbour, my code might break due to
your bugfixes?
Thank you for everything
2010/1/30 Przemysław Czerpak
> On Sat, 30 Jan 2010, smu johnson wrote:
> > It appears the FILEATTR() function doesn't work.
> > According to http://www.ousob.com/ng/tools1-3/ng935ab.php , it says it
> > should return a bit-wise decimal number. I tried a few different ways...
> > absolute path, relative, and a piece of code my brother found from the
> > Harbour source files.
> > ___Pre-test:
> > C:\hbm>attrib hello.prg
> > A HC:\hbm\hello.prg
> > ___Result:
> > C:\hbm>hello.exe
> > 0
> > 0
> > 0
> > ___code
> > FUNCTION main()
> > ? FILEATTR("hello.prg")
> > ? FILEATTR("C:\hbm\hello.prg")
> > cFile := FILESEEK("hello.prg")
> > DO WHILE .NOT. EMPTY (cFile)
> > ? cFile, FILEATTR()
> > cFile := FILESEEK()
> > ENDDO
> > return
> > // end
> > Have I found a bug? :3
>
> Yes, Thank you very much for the information.
> The problem is only in MS-Windows builds and it's caused by wrongly
> written emulation of DOS volume label attribute in hb_fsFindFirst()/
> hb_fsFindNext().
> Additionally as I can see it's partially hacked in DIRECTORY() function
> so I cannot fix it immediately. I'll fix it later.
> Anyhow in current code we can remove yet another hack from FILEATTR()
> implementation which also resolve the problem.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbct FILEATTR() function not working.
On Sat, Jan 30, 2010 at 5:24 AM, Viktor Szakáts wrote: > > This has been discussed a lot on this list, and it's really > not a technical problem, it simply needs contributors, > willing to give something (in this case documentation writing) > back to the project they're getting for free. > Viktor, I would love to help out on the documentation project. I consider myself a decent writer who can explain things clearly and give examples that prove all nooks and cranny's of something. If you are interested in giving me a task to start off with, I'd be very glad to help, since you and others have been incredibly helpful, saving me days of hair-pulling frustration. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Przemek Q: SIX "FOR" clause Clipper/Harbour difference
The senior Clipper programmer here wanted me to ask someone this question. I couldn't think of a better person to ask than you! :) Question: - When a table's index file is re-opened (it was previously created), does it have to evaluate the FOR clause, or can it wait to do that only when a value in the table row changes? In SIX, it does not check the FOR expression when it opens an index file. In Harbour, when you open the index file it will evaluate the FOR expression, and if any variables or functions in that expression are not visible, the system will crash (undefined variable/function). eg. Index on iif(x=3,"a","b") tag "temp" of test.cdx When the index is opened (set index to...) if X is not visible, Harbour will crash. In Clipper, it will only crash if a row in the table changes value and the index needs to be updated. Unfortunately, my code has lots of specialized temporary indexes that are created and then used within a specific function. This does not present a problem until a timer event fires, which needs to close files to do "something". Upon reopening those file before RETURNing back the original function, the system crashes because the FOR in the index has variables out of scope. I can rewrite these but I will probably have to use Private variables and non-Static functions. Many thanks in advance -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
I have the test which has been proven with our Clipper 5.2e running on DOS
of a difference in Harbour below is an explanation I received by e-mail:
== start here
If eval({||devout("hello"),.f.)}) .or. .t.
endif
In Clipper the eval() will process (even though it appears redundant because
.t. will make the IF statement always return .t.
Harbour does not process the eval()
Unfortunately, my code could be scattered with situations where I have used
the Clipper behaviour to do something intentional (as in my search routine).
I will need to look for other places (or more likely wait for things to
break) and change the logic to get around this unless Harbour is interested
in making this fully compatible.
==
Any thoughts? Is it because the guy who showed me this line of code relied
too much on Clipper bugs when programming?
Thanks Przemek
On Thu, Jan 28, 2010 at 3:42 AM, smu johnson wrote:
> Thanks for the reply.
>
> As far as I can tell, I have found a difference in Clipper and Harbour in
> terms of these evaluations. But as I said earlier, I could be completely
> mistaken. I have done a lot of little tests to check the -z flag but
> unfortunately I'm not that good at Clipper as one of my friends is. (I'm
> better at Perl, etc). But if I can demonstrate the problem in a small Hello
> World type example, I will post it, to try to figure out what is happening,
> with your help. :) The only reason I bring this up, is because I am trying
> to compile an old DOS16 app and it is behaving differently on these .or.
> lines.
>
> Thanks again for reading!!! I have read your informative reply, and will
> test what you said out for myself to try to figure out what is going on.
>
>
> 2010/1/28 Przemysław Czerpak
>
>> On Thu, 28 Jan 2010, smu johnson wrote:
>>
>>
>> Hi!
>>
>> > I noticed the -z switch allows to stop using shortcuts for .and. and
>> .or.
>> > Clipper conditions.
>> > Without -z, if I do:
>> > eval(something) .or. .t. // will recognize that it's already true, and
>> not
>> > make the eval
>> > When -z is enabled:
>> > .f. .and. eval(something) // will try to eval 'something', despite the
>> fact
>> > that .f. already failed.
>>
>> Exactly just like in Clipper.
>>
>> > ... If what I said is actually true, is there any sort of secondary -z
>> > switch that can be done to make it simply not be lazy, yet fail on first
>> > condition?
>>
>> It's default behavior. Just simply do not use -z or better use the same
>> switches as in Clipper.
>>
>> > ... If what I said is complete nonsense and complete BS, I will have to
>> go
>> > through the code I'm trying to compile that someone else wrote and see
>> > what's up. By the way, I realize that the above examples are not the
>> best
>> > way to do things... and I sure as heck wouldn't do it that way myself.
>> Just
>> > trying to get some existing Clipper functioning code to behave the same
>> way
>> > in Harbour.
>>
>> You mixed two different things which confuse you:
>> 1. compile time optimizations
>> 2. lazy boolean expression evaluation
>>
>> Both Harbour and Clipper support -z switch to control lazy expression
>> evaluation. It works in the same way. This code illustrate it:
>>
>> proc main()
>> local f:=.F., t:=.T.
>> ?; ?? .t. .or. f()
>> ?; ?? .f. .and. f()
>> ?; ?? f() .or. .t.
>> ?; ?? f() .and. .f.
>> ?
>> ?; ?? t .or. f()
>> ?; ?? f .and. f()
>> ?; ?? f() .or. t
>> ?; ?? f() .and. f
>> ?
>> return
>> func f()
>> ?? "[F()] "
>> return .T.
>>
>> compile it with and without -z switch using Harbour and Clipper and
>> compare results. Please note that when -z is not used then first 4
>> expressions are optimized at compile time and next 4 ones are optimized
>> at runtime. Compile time optimization calculates final result and
>> replace the code with simple .F. or .T. so F() function is never
>> execute. It's also Clipper compatible behavior.
>> Anyhow Clipper does not optimize all expressions (i.e. it does not
>> optimize if message is send to it: :msg()) and cannot strip
>> parenthesis in optimization process. Harbour does not make any exceptions
>> here and optimize all end everywhere if it's possible what seems to be
>> correct behavior. You can add these lines to above test to see the
>> difference:
>>
>> ?; ?? (.t.) .or. f
[Harbour] Alert() / print buffer Clipper -> Harbour difference
Hi, I found a problem that is very noticeable when using the ALERT() func. If your MS Windows buffer size setting ( http://209.97.219.2/sjohnson/misc/alert_problem_buffer500-set.png ) is to > 25, position screws up. This is not a problem with Clipper 5.2e (using Blinker). The alert box shows up like this: http://209.97.219.2/sjohnson/misc/alert_problem_buffer500.png ... but like I said, this difference does not show up if you keep the buffer height set to 25. But since Clipper does not have this problem, no matter what the value is set to, I thought I'd ask here. Thanks for reading. What can I do? -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
Przemek,
I will try to take a video of the behaviour and figure it out. I swear to
you, that I am not making this up. If it helps, we are using Clipper 5.2e
and Blinker. I will take screenshots of the behavioru to prove what I am
saying is the case, and hopefully, with your Clipper knowledge :) we can
figure it out. Thanks for replying !
2010/2/3 Przemysław Czerpak
> On Tue, 02 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > I have the test which has been proven with our Clipper 5.2e running on
> DOS
> > of a difference in Harbour below is an explanation I received by
> e-mail:
> > == start here
> > If eval({||devout("hello"),.f.)}) .or. .t.
> > endif
> > In Clipper the eval() will process (even though it appears redundant
> because
> > .t. will make the IF statement always return .t.
> > Harbour does not process the eval()
>
> The above is not true.
> Both Clipper (5.2 and 5.3) and Harbour execute above code in exactly
> the same way:
> iF -z compile time switch is used then "hello" is printed otherwise not.
>
> Please compile your example with Clipper and check results.
>
> > Unfortunately, my code could be scattered with situations where I have
> used
> > the Clipper behaviour to do something intentional (as in my search
> routine).
> > I will need to look for other places (or more likely wait for things to
> > break) and change the logic to get around this unless Harbour is
> interested
> > in making this fully compatible.
>
> If you need help then you have to show us the difference.
> Otherwise we do not know what is the problem.
>
> > ==
> > Any thoughts? Is it because the guy who showed me this line of code
> relied
> > too much on Clipper bugs when programming?
>
> Without real code example I cannot help you.
> Maybe you are not talking about normal code but about macrocompiler?
> Clipper does not have compile time optimizations in macrocompiler so
> it may give different results for the same code compiled directly and
> by macrocompiler. This is self contain exmaple which illustrates the
> difference:
>
> ? eval({||qout("hello"),.f.}) .or. .t.
> ? &('eval({||qout("WORLD"),.f.}) .or. .t.')
>
> If you show me the _exact_ code which creates problems for you then
> I can try to help you to resolve it or find workaround but I have to
> know what it is.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Alert() / print buffer Clipper -> Harbour difference
Thanks Angel !!! On Tue, Feb 2, 2010 at 7:32 PM, Angel Pais wrote: > El 03/02/2010 1:22, smu johnson escribió: > >> Hi, >> >> I found a problem that is very noticeable when using the ALERT() func. >> If your MS Windows buffer size setting ( >> http://209.97.219.2/sjohnson/misc/alert_problem_buffer500-set.png ) is >> to > 25, position screws up. This is not a problem with Clipper 5.2e >> (using Blinker). >> >> The alert box shows up like this: >> http://209.97.219.2/sjohnson/misc/alert_problem_buffer500.png ... but >> like I said, this difference does not show up if you keep the buffer >> height set to 25. But since Clipper does not have this problem, no >> matter what the value is set to, I thought I'd ask here. >> >> Thanks for reading. What can I do? >> >> -- >> smu johnson > <mailto:smujohn...@gmail.com>> >> >> > You must put at the beggining of your main.prg: SetMode(25,80) > > HTH > Angel > > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Przemek Q: SIX "FOR" clause Clipper/Harbour difference
Thanks Przemek. Could you post back here when I should get the SVN etc? Thank you for your hard work 2010/2/3 Przemysław Czerpak > On Tue, 02 Feb 2010, smu johnson wrote: > > Hi, > > > When a table's index file is re-opened (it was previously created), does > it > > have to evaluate the FOR clause, or can it wait to do that only when a > value > > in the table row changes? > > It does not need to be evaluated and can wait but it has to be valid > expression which can be compiled by macrocompiler. > Anyhow few times people asked to make such test evaluation to detect > some potential problems like missing functions, incompatible aliases > or not logical results as fast as possible and report RTE before > executed code will start some operations which cannot be finished. > Just like someone asked to delay all such tests as long as possible > because he only wanted to skip using the index created by foreign > application with unknown UDFs in KEY and FOR expressions. > In clipper this behavior depends on used RDD and different RDDs > evaluates KEY and FOR expressions first time in different places. > Similar situation is in xHarbour. > > > In SIX, it does not check the FOR expression when it opens an index file. > > In Harbour, when you open the index file it will evaluate the FOR > > expression, and if any variables or functions in that expression are not > > visible, the system will crash (undefined variable/function). > > Not crash but generates RTE. You can catch RT errors using BEGIN SEQUENCE > statement.You are right about FOR expression. Harbour DBFCDX evaluates > index KEY and FOR expressions to test their results just after opening > index file. It's CL5.3 DBFCDX / COMIX behavior but CL5.2 DBFCDX / SIXCDX > evaluates only KEY expression when index is open and FOR is evaluated only > when index is updated. > > > eg. Index on iif(x=3,"a","b") tag "temp" of test.cdx > > When the index is opened (set index to...) if X is not visible, Harbour > will > > crash. In Clipper, it will only crash if a row in the table changes > value > > and the index needs to be updated. > > Yes but please use more precise description. RTE is not a crash but > exception which can be fully controlled by programmer. Some important > Clipper features are implemented using RTE, i.e. NETERR() or division > by 0. > > > Unfortunately, my code has lots of specialized temporary indexes that are > > created and then used within a specific function. This does not present a > > problem until a timer event fires, which needs to close files to do > > "something". Upon reopening those file before RETURNing back the original > > function, the system crashes because the FOR in the index has variables > out > > of scope. > > I can rewrite these but I will probably have to use Private variables and > > non-Static functions. > > I'll change early expression evaluation in Harbour SIXCDX driver only > so Harbour SIXCDX will work like CL52 DBFCDX / SIX3 SIXCDX and > Harbour DBFCDX will work like CL53 DBFCDX / COMIX verifying both KEY > and FOR expressions when index is opening. > > I'll commit it in a while. You should take current Harbour SVN and > rebuild the compiler binaries. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
Hi again,
I have the code here that I have tested on both Clipper 5.2e and Harbour.
This is the first time I have seen with my own eyes what I was being told
earlier, so I can verify that I have witnessed a difference with my own two
eyes. If you cannot replicate it, perhaps I will need to send you my
Blinker .LNK file, in case something is being switched on in there.
Anyways, Clipper will write "hello" at the top of the screen after "test",
and Harbour will not.
FUNC MAIN()
do while lastkey()#27
clear
x:= "test"
@ 2,0 get x ;
valid eval( {||devout("hello"), .f.} ) .or. .t.
read
? "test complete...press enter to do it again"
wait
enddo
RETURN
// Thanks Przemek
2010/2/3 Przemysław Czerpak
> On Wed, 03 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > I will try to take a video of the behaviour and figure it out. I swear
> to
> > you, that I am not making this up. If it helps, we are using Clipper
> 5.2e
> > and Blinker. I will take screenshots of the behavioru to prove what I am
> > saying is the case, and hopefully, with your Clipper knowledge :) we can
> > figure it out. Thanks for replying !
>
> I also have CL5.2e and BLINKER and before I replayed I had verified
> the results. I do not need any video, screen shots or antyhing like
> that. I need only code example. The one you sent works in the same
> way in CL5.2e and Harbour (after fixing typo which breaks compilation
> so I guess it was not real code but you typed it by hand for that
> message only). If you try to create real .prg code example and compile
> it using Clipper and Harbour (linker is unimportant here, you can use
> also RTLINK, i.e. with cl.bat) then you should find the exact reason
> of problem. If it will not be enough for you to resolve it then please
> send the code example here with descrption about the difference and
> I'll try to help you. Such example should be as small as possible,
> i.e. this code illustrates in 1-st line the the at compile time
> Clipper and Harbour gives _EXACTLY_ the same results when used with
> and without -z switch and the 2-nd line shows that Clipper does
> not optimize expressions in macrocompiler so code generated by
> macrocompiler is different then code generated by compiler. In
> Harbour it's the same.
>
> ? eval({||qout("hello"),.f.}) .or. .t.
> ? &('eval({||qout("WORLD"),.f.}) .or. .t.')
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Przemek Q: SIX "FOR" clause Clipper/Harbour difference
Thanks! As far as the timestamp stuff... have found that using FSETDATETIME and trying to set only one of the options, either DATE, or TIME, results in the other one getting timestamped to a NOW() type time. Hence I wrote my cludge in Clipper get around that... I tried all sorts of tricks.. HB_FSETDATETIME(file, nil, time), (file, , time)... etc.. and nothing seemed to work. === code === FUNCTION FY_FSETDATE(sFilename, sDate) // sets the file date only, leaving time untouched. // function emulates FUNCKy's laziness. Must pass this a string only. // HB_FSETDATETIME will timestamp the only other field, so next line keeps original TIME LOCAL sTimeOriginal := FILETIME(sFilename) RETURN HB_FSETDATETIME(sFilename, CTOD(sDate), sTimeOriginal) FUNCTION FY_FSETTIME(sFilename, sTime) // sets the file time only, from "HH:MM:SS" string, leaving date untouched. // HB_FSETDATETIME will timestamp the only other field, so next line keeps original DATE LOCAL dDateOriginal := FILEDATE(sFilename) RETURN HB_FSETDATETIME(sFilename, dDateOriginal, sTime) 2010/2/3 Przemysław Czerpak > On Wed, 03 Feb 2010, smu johnson wrote: > > Hi, > > > Thanks Przemek. > > Could you post back here when I should get the SVN etc? > > It's already ready in SVN. > I committed it few minutes after I sent you the message. > Look at the ChangeLog: > > 2010-02-03 11:15 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/src/rdd/dbfcdx/dbfcdx1.c > ! do not verify FOR expression just after loading new index file > in SIXCDX RDD. It's CL52 DBFCDX / SIX3 SIXCDX compatible behavior > but Harbour DBFCDX and CL53 DBFCDX / COMIX verifies both KEY and > FOR expressions when index is loaded. > ! fixed RTE numbers to be CL53 compatible when index with wrong > (returning wrong results) KEY or FOR expression is loaded. > > also the problem with FILEATTR() is already fixed: > 2010-02-02 17:58 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > > anyhow you may want to look at: > >HB_FGETATTR( , @ ) -> >HB_FSETATTR( , ) -> > > and maybe: > > HB_FSETDATETIME( , [], [] ) -> > > HB_FSETDATETIME( , [] ) -> > > HB_FGETDATETIME( , @ ) -> > HB_FGETDATETIME( , @, @ ) -> > > Harbour support timestamp values. You can find more information about > timestamp and other Harbour extensions in doc/xhb-diff.txt > > best regards, > Przemek > ___________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: 10 char variables with SAVE and REST w/ proof of concept
Hi,
Variables in Harbour can be over 10 characters. In clipper these can be
written as 10+ characters but only the 1st 10 are used at compile time.
When variables are saved to a .mem file only 10 characters are saved,
however when they are restored they are 10 characters, but the code
that references them can be 10+ characters, which causes undefined
variables. I had 60 variables in that situation and had to make several
hundred variable name changes to ensure everything is not more than 10
chars.
As well, an unknown number of other variable references are waiting to
explode
in situations such as:
Local MyVariable:=10
? MyVariableValue // will crash in Harbour but not in Clipper
{obviously, I should have kept them the same but Clipper allowed them to be
used this way, intentionally or accidentally}
___proof___
FUNC MAIN()
clear
mylongvariable:="[This is mylongvariable]"
? mylongvariable," - long variable name OK"
save all like my* to test.mem
release all like my*
rest from test.mem
? mylongvari," - truncated version is ok"
?
? "After this wait statement, the error will occur in Harbour"
wait
// if you can read the following print statement, then you're using
Clipper
// or some switch in Harbour to fix this incompat.
? mylongvariable," - long version should be ok, too."
RETURN
To be compatible, would Harbour make a switch or something to truncate
all variable and field referenced to 10 chars long (and maybe function
names?)
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: DIRECTORY() uppercase w/ proof of concept
Hi,
Filenames are not converted to uppercase by Harbour functions such as
Directory() was in Clipper.
#include "Directry.ch"
FUNC MAIN()
aDirectory := DIRECTORY("*.txt", "D")
AEVAL( aDirectory, {|aFile| QOUT(aFile[F_NAME])} )
RETURN
/*
__ HARBOUR (02/03/2010 01:18 PM 5 test.txt)
C:\hbm>hello
-
__ CLIPPER (02/03/2010 01:15p 11 test.txt)
C:\ver8\PRGS>hello.exe
TEST.TXT
*/
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: SETPOS() return val
Hi, In Clipper, ? SETPOS(10,4) returns 10. In Harbour, it returns NIL -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: CURDIR()
Hi! In Clipper, CURDIR() returns the absolute path, including the drive letter. In Harbour, it does the same, but omits the drive letter and colon. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: ACHOICE() w/ p.o.c
ACHOICE() behaves differently in Harbour than Clipper. In Clipper, the code
below will not have achoicef() called, as it knows that there is no point to
run it.. probably because the pFNames array is blank. Harbour however, will
try to run it, causing "array access" error.
--- code ---
func main()
Priv pFNames:={}// privates needed by achoice's function
AChoice(1,0,10,20,pFNames,,"achoicef",1,1)
return nil
Func achoicef(nMode,nItem)
? pFNames[nItem]
wait
return
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: 10 char variables with SAVE and REST w/ proof of concept
Ok. So I suppose the best solution is to just make .MEM saved vars 1-10 chars long? Also, sorry about the vague use of "crash". I'll edit my posts prior to posting to avoid that in the future. The good news is, I've never had Harbour actually crash yet! On Wed, Feb 3, 2010 at 2:05 PM, Viktor Szakáts wrote: > Hi, > > > Variables in Harbour can be over 10 characters. In clipper these can be > > written as 10+ characters but only the 1st 10 are used at compile time. > > When variables are saved to a .mem file only 10 characters are saved, > > however when they are restored they are 10 characters, but the code > > that references them can be 10+ characters, which causes undefined > > variables. I had 60 variables in that situation and had to make several > > hundred variable name changes to ensure everything is not more than 10 > chars. > > As well, an unknown number of other variable references are waiting to > explode > > in situations such as: > > > > Local MyVariable:=10 > > ? MyVariableValue // will crash in Harbour but not in Clipper > > It will RTE, not crash. It's not the same, when we read > 'crash', it suggests the it's a Harbour system crash. > > This is a known problem, and it's a limitation of the > .mem file format. It's not possible to solve it without > breaking CA-Cl*pper compatibility. > > Brgds, > Viktor > > ___________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: 10 char variables with SAVE and REST w/ proof of concept
Viktor, Was thinking a bit more about this... I suppose there are some things in Clipper and Harbour that are not compatible.. such as long variable names... Since this likely won't be changed, as I also prefer long variable names... but would would be the best way to do to just keep going ahead with porting our old .PRG's to Harbour? Thanks On Wed, Feb 3, 2010 at 2:05 PM, Viktor Szakáts wrote: > Hi, > > > Variables in Harbour can be over 10 characters. In clipper these can be > > written as 10+ characters but only the 1st 10 are used at compile time. > > When variables are saved to a .mem file only 10 characters are saved, > > however when they are restored they are 10 characters, but the code > > that references them can be 10+ characters, which causes undefined > > variables. I had 60 variables in that situation and had to make several > > hundred variable name changes to ensure everything is not more than 10 > chars. > > As well, an unknown number of other variable references are waiting to > explode > > in situations such as: > > > > Local MyVariable:=10 > > ? MyVariableValue // will crash in Harbour but not in Clipper > > It will RTE, not crash. It's not the same, when we read > 'crash', it suggests the it's a Harbour system crash. > > This is a known problem, and it's a limitation of the > .mem file format. It's not possible to solve it without > breaking CA-Cl*pper compatibility. > > Brgds, > Viktor > > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Harbour / Clipper Incompatibility Issue: SET() w/ p.o.c.
FUNC MAIN()
? set(24) // Clipper is "", Harbour is LPT1
set printer to ("junk.txt")
? set(24) // junk.txt
set printer to
? set(24) // s/b "", but set to LPT1 again
RETURN
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: CURDIR()
Viktor, http://209.97.219.2/sjohnson/misc/curdir-diff.png Please let me know if you need anything else. On Wed, Feb 3, 2010 at 2:42 PM, Viktor Szakáts wrote: > Please post more information about Clipper version, OS > and small test problem. > > Here CURDIR() returns /DIR/ format, in sync with C5x > documentation. (C5.2e under Win98) > > Brgds, > Viktor > > On 2010 Feb 3, at 22:52, smu johnson wrote: > > > Hi! > > > > In Clipper, CURDIR() returns the absolute path, including the drive > letter. In Harbour, it does the same, but omits the drive letter and colon. > > > > -- > > smu johnson > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: CURDIR()
Is there a way an HB_CURDIR or HB_CWD could be implemented, to always return the same val, based on it's own system lib thingies? On Wed, Feb 3, 2010 at 3:04 PM, Viktor Szakáts wrote: > > Viktor, > > > > http://209.97.219.2/sjohnson/misc/curdir-diff.png > > > > Please let me know if you need anything else. > > My only guess is that CURDIR() is overridden by > some libs. Sorry, but I can't replicate it here > and can't recall seeing such behavior even on W2K > either. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: CURDIR()
hmm.. i suppose i'd have to use some perl-like regex to test that this doesn't write C:\C:\hbm on other version of windows... On Wed, Feb 3, 2010 at 3:12 PM, Viktor Szakáts wrote: > Try this one: > > FUNCTION hb_pwd() > RETURN CurDrive() + hb_osDriveSeparator() + hb_osPathSeparator() + > CurDir() > > Brgds, > Viktor > > On 2010 Feb 4, at 00:05, smu johnson wrote: > > > Is there a way an HB_CURDIR or HB_CWD could be implemented, to always > return the same val, based on it's own system lib thingies? > > > > > > On Wed, Feb 3, 2010 at 3:04 PM, Viktor Szakáts > wrote: > > > Viktor, > > > > > > http://209.97.219.2/sjohnson/misc/curdir-diff.png > > > > > > Please let me know if you need anything else. > > > > My only guess is that CURDIR() is overridden by > > some libs. Sorry, but I can't replicate it here > > and can't recall seeing such behavior even on W2K > > either. > > > > Brgds, > > Viktor > > > > ___________ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > -- > > smu johnson > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: CURDIR()
Thanks Viktor.. you have been most helpful! On Wed, Feb 3, 2010 at 3:24 PM, Viktor Szakáts wrote: > > hmm.. i suppose i'd have to use some perl-like regex to test that this > doesn't write C:\C:\hbm on other version of windows... > > I don't think you need to make it that complicated. > > If CURDIR() returns a drive letter in Harbour, report > it on this list, as it is a clear bug. I'm confident > that such bug doesn't exist in Harbour though. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: SET() w/ p.o.c.
Well the program compiled in both Clipper and Harbour behaves differently on
the same machine, same environment, in this case, Vista 32-bit. Hence an
incompatibility.
On Wed, Feb 3, 2010 at 7:53 PM, Xavi wrote:
> smu,
>
>
>set printer to
>> ? set(24) // s/b "", but set to LPT1 again
>>
>
> Ok but it's also the default printer.
> Printer connected to port LPT1 in WoW and NTVDM DOS PC emulator under
> Windows.
>
> try .-
>
>
> FUNC MAIN()
>
> ? set(24) // Clipper is "", Harbour is LPT1
> set printer to ("junk.txt")
> ? set(24) // junk.txt
>
> set printer to
> ? set(24) // s/b "", but set to LPT1 again
>
> // set printer to LPT4
> // set printer to
> set printer on
> ? "Printed on default printer."
>
>
> RETURN
>
> --
> Xavi
>
> El 03/02/2010 23:39, smu johnson escribió:
>
>> FUNC MAIN()
>>
>> ? set(24) // Clipper is "", Harbour is LPT1
>> set printer to ("junk.txt")
>> ? set(24) // junk.txt
>>
>> set printer to
>> ? set(24) // s/b "", but set to LPT1 again
>>
>> RETURN
>>
>> --
>> smu johnson mailto:smujohn...@gmail.com>>
>>
>> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: DIRECTORY() uppercase w/ proof of concept
We haven't changed OS's though. That screenshot was a bad example.. Using the same Windows Vista 32bit OS, clipper 5.2e w/ blinker and Harbour returned different results, hence how I came across this. But we can get around it.. but I just wanted to share what I found in case this was a big deal to the mailing list. Should I take a screenshot that doesn't use a different computer? The only reason I did two different OS's in that case was because I can't get DOS16 apps to compile on Win7, hence I went to a Win2k computer cause it was nearby. But I can show this on my cute laptop which runs WinXP 32-bit. I am curious to try.. I will do it in a few hours. Thanks! 2010/2/4 Przemysław Czerpak > On Wed, 03 Feb 2010, smu johnson wrote: > > Hi, > > > Filenames are not converted to uppercase by Harbour functions such as > > Directory() was in Clipper. > > Clipper also does not convert directory names to upper case. > It simply returns what OS returns. It can be seen in some > network redirectors so Harbour is 100% Clipper compatible. > You have problem because you changed the OS and you are not > creating DOS application. DOS Harbour builds returns the same > result as Clipper. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: SETPOS() return val
Hmm... we have a good few lines of code in our .PRGs that expect the first arg returned, but I suppose it could be worked around without too much fuss as it's basic... but maybe would be closer to Clipper 5.3 compat? On Thu, Feb 4, 2010 at 12:41 AM, Viktor Szakáts wrote: > And BTW, in C5.3 they forgot to update the DEVPOS() > entry in the NG, which keeps saying it returns NIL, > while it doesn't > > Brgds, > Viktor > > On 2010 Feb 4, at 09:30, Viktor Szakáts wrote: > > > Hi, > > > > To be precise pls show that you were pasting from C5.3 > > guide (you're right in that I didn't check 5.3 guide also > > before posting). > > > > I was checking in _C5.2e_ guide, which is our reference > > in Harbour, and that says: > > --- > > SETPOS() > > Move the cursor to a new position > > > Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„ > > Syntax > > > > SETPOS(, ) --> NIL > > > > Arguments > > > > and define the new screen position of the cursor. > > These values may range from 0, 0 to MAXROW(), MAXCOL(). > > > > Returns > > > > SETPOS() always returns NIL. > > > > Description > > [...] > > --- > > > > --- > > DEVPOS() > > Move the cursor or printhead to a new position depending on the current > > device > > > Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„ > > Syntax > > > > DEVPOS(, ) --> NIL > > > > Arguments > > > > and are the new row and column positions of the > > cursor or printhead. > > > > Returns > > > > DEVPOS() always returns NIL. > > [...] > > --- > > > > Even then, C5.3 is buggy or sloppy, since it will return > > "" even if it's non-numeric. > > > > We could probably implement it with HB_COMPAT_C53 guard, > > though it will unnecessarily add overhead to this very > > often used function. > > > > Brgds, > > Viktor > > > > On 2010 Feb 4, at 09:15, Saulius Zrelskis wrote: > > > >>>> In Clipper, ? SETPOS(10,4) returns 10. In Harbour, it returns NIL > >>> > >>> Also DEVPOS(). They should return NIL as per documentation, > >>> but they return the first parameter, unchanged, even if it's > >>> invalid. I can't recall past discussions, but it seems like > >>> a C5.2/5.3 bug. > >> > >> Be precise! From Clipper guide: > >> SETPOS() > >> Move the cursor to a new position > >> > Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„Ć„ > >> Syntax > >> > >>SETPOS(, ) --> > >> > >> Arguments > >> > >> and define the new screen position of the cursor. > >>These values may range from 0, 0 to MAXROW(), MAXCOL(). > >> > >> Returns > >> > >>SETPOS() always returns > >> > >> Description > >> > >>SETPOS() is an environment function that moves the cursor to a new > >>position on the screen. After the cursor is positioned, ROW() and > COL() > >>are updated accordingly. To control the shape and visibility of the > >> cursor, use the SETCURSOR() function. > >> > >> Examples > >> > >>ž This example moves the cursor to a new position then displays > >> a string to the screen using a console command, ??: > >> > >> SETPOS(1, 1) > >> ?? "Hello world" > >> > >> Files Library is CLIPPER.LIB. > >> > >> Best regards, > >> Saulius > >> ___ > >> Harbour mailing list (attachment size limit: 40KB) > >> Harbour@harbour-project.org > >> http://lists.harbour-project.org/mailman/listinfo/harbour > > > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: DIRECTORY() uppercase w/ proof of concept
Thanks Viktor. I see what you now. Thanks for the HB_ func that returns the drive letter, as that is good enough for us, and was a huge help On Thu, Feb 4, 2010 at 6:51 AM, Viktor Szakáts wrote: > > We haven't changed OS's though. That screenshot was a bad example.. > Using the same Windows Vista 32bit OS, clipper 5.2e w/ blinker and Harbour > returned different results, hence how I came across this. > > MS-DOS apps run in an emulated MS-DOS environment (NTVDM) > in NT class OSes, so you did in fact change OS. To view > from another, more obvious perspective: You also changed > the target OS of your executable. > > If you change to Linux, which Harbour perfectly allows, > you'll have to face with some more challenges. > > IOW, Harbour can't mask, hide or resolve platform > compatibility and portability problems present on the > application level. (f.e. on *nix OSes there is no drive > letter) > > Making the app code portable would probably take > much longer than simply recompiling an app with > Harbour. > > BTW, Harbour also allows to build native MS-DOS apps, > and in case you tried it with your app, most of these > platform differences would automatically go away, and > you'd get the same as in Clipper. Albeit, without > much of the advantages of f.e. a Windows build. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: DIRECTORY() uppercase w/ proof of concept
It is okay, it is not an issue. But I did learn a bit about how DOS emulation works... from you and Viktor. We intend to just compile for Win32 and no DOS16 stuff.. so we shouldn't have to worry I don't think. By the way 2010/2/4 Przemysław Czerpak > On Thu, 04 Feb 2010, smu johnson wrote: > > We haven't changed OS's though. That screenshot was a bad example.. > > You changed. Now you are creating real windows binaries which are > executed natively. > Download Harbour DOS builds to create DOS binaries which are executed > like Clipper programs inside NTVDM DOS emulator. > > > Using the same Windows Vista 32bit OS, clipper 5.2e w/ blinker and > Harbour > > returned different results, hence how I came across this. > > So your Clipper programs are not executed as native windows applications > but inside NT Virtual DOS Machine. > If you compile your program using Harbour DOS build then they will be > also executed in virtual DOS machine and will return the same results. > > > But we can get around it.. but I just wanted to share what I found in > case > > this was a big deal to the mailing list. Should I take a screenshot that > > doesn't use a different computer? The only reason I did two different > OS's > > in that case was because I can't get DOS16 apps to compile on Win7, hence > I > > went to a Win2k computer cause it was nearby. But I can show this on my > > cute laptop which runs WinXP 32-bit. I am curious to try.. I will do it > in > > a few hours. Thanks! > > See above. DOS programs are executed inside DOS emulator. > These are not native application. > > Harbour does not emulate DOS inside other OS-es like MS-Windows, > WInCE, Linux, MacOSX, *BSD, Solaris, HP-UX, ... and it's not > our goal to reduce the functionality to DOS level :) > We have native Harbour DOS builds where such emulation is not necessary. > You can use it if you need strict DOS compatibility and NTVDM in your > VISTA system will make such emulation just like for all DOS applications. > > best regards, > Przemek > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour / Clipper Incompatibility Issue: ACHOICE() w/ p.o.c
Hi Przemek. Thank you for replying. We found one more possibly easy fix
(maybe) while you are fixing this minor bug for ACHOICE. I got this over
MSN, maybe you can figure out what it means better than me.
(11:01:46 AM) MN: Also on the subject of ACHOICE()... In Harbour, achoice()
restores the row() to where it was when achoice() started. In Clipper it
leaves the Row() at wherever achoice() happened to moved it... causing
cursor position disasters in the console-based program.
Thank you again
2010/2/4 Przemysław Czerpak
> On Wed, 03 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > ACHOICE() behaves differently in Harbour than Clipper. In Clipper, the
> code
> > below will not have achoicef() called, as it knows that there is no point
> to
> > run it.. probably because the pFNames array is blank. Harbour however,
> will
> > try to run it, causing "array access" error.
> > --- code ---
> > func main()
> > Priv pFNames:={}// privates needed by achoice's function
> > AChoice(1,0,10,20,pFNames,,"achoicef",1,1)
> > return nil
> > Func achoicef(nMode,nItem)
> > ? pFNames[nItem]
> > wait
> > return
>
> You touched never ending problem. ACHOICE and MEMOEDIT are peaces of
> code which should be rewritten from scratch or at least seriously cleaned.
> Unfortunately none of us has motivation to touch this code.
> Probably none of core developers use them in hos own programs and do
> not want to invest time in detail test of undocumented Clipper behaviors.
> In the past we had similar problem with TBROWSE but two years ago I rewrote
> it in practice nearly from scratch and seems that it resolved all reported
> by user problems. But I needed over two weeks to document Clipper behavior
> with great Viktor help and it was more then I needed for coding.
> I have no motivation to make the same with ACHOICE. It's .prg code and
> many of Harbour users should be able to make detail tests and update this
> code. It's not C and does not need any special knowledge. It's enough
> to carefully document all side effects of ACHOICE implementation in Clipper
> and then create compatible code. Probably much smaller then the current
> one.
>
> I'll commit fix for your example but for sure it will not address all
> potential problems in ACHOICE. Maybe your code will not exploit any
> of new incompatibilities so it will be enough for your. Anyhow if you
> want to look at it closer then src/rtl/achoice.prg is the source code
> of ACHOICE in Harbour.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] -z switch seems to be overly anti-lazy
Many thank yous to you, Przemek!!!
2010/2/4 Przemysław Czerpak
> On Wed, 03 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > I have the code here that I have tested on both Clipper 5.2e and Harbour.
> > This is the first time I have seen with my own eyes what I was being told
> > earlier, so I can verify that I have witnessed a difference with my own
> two
> > eyes. If you cannot replicate it, perhaps I will need to send you my
> > Blinker .LNK file, in case something is being switched on in there.
> > Anyways, Clipper will write "hello" at the top of the screen after
> "test",
> > and Harbour will not.
> > FUNC MAIN()
> > do while lastkey()#27
> > clear
> > x:= "test"
> > @ 2,0 get x ;
> > valid eval( {||devout("hello"), .f.} ) .or. .t.
> > read
> > ? "test complete...press enter to do it again"
> > wait
> > enddo
> > RETURN
>
> This code touches few different things.
> 1. It works differently in CL52 and CL53. Harbour works like CL53.
> It's caused by preprocessor rules. You can test in .ppo file
> generated by -p switch that for this line
> @ 2,0 get x valid eval( {||devout("hello"), .f.} ) .or. .t.
>CL52 generates:
> SetPos( 2, 0 ) ; Add( GetList, ;
> _GET_( x, "x",, {|| eval( {||devout("hello"), .F.} ) .OR. .T.},
> ):display() )
> but Harbour and CL53
> SetPos( 2, 0 ) ; AAdd( GetList, ;
> _GET_( x, "x",, {|| eval( {||devout("hello"), .F.} ) .OR. .T.}, ) ) ;
> ATail(GetList):Display()
> This is result of extended GET rules in std.ch. You can see them
> in out std.ch[563].
> 2. As I said before Clipper does not optimize expression used in some
> language constructions and this is the exact case I used as example.
> In code like:
> : [( [] )]
> the is not optimized (probably typo in compiler but I only guess)
> and code generated by CL5.2 PP:
> _GET_( x, "x",, {|| eval( {||devout("hello"), .F.} ) .OR. .T.},
> ):display() )
> creates exactly such situation where is:
> _GET_( x, "x",, {|| eval( {||devout("hello"), .F.} ) .OR. .T.}, )
> and this is the source of problem.
> 3. In Harbour it's possible to disable extensions and optimizations to
> the Clipper level using -kc switch. In most of cases it's enough
> to use -kc if you want to force strict Clipper behavior. So you can
> try to use own std.ch (it's enough to use -ustd.ch compiler switch
> because it will also disable all macros used in #if... expressions
> in std.ch) and it will cause that Harbour PP generate code like CL52
> (check it in .ppo file using -p and -ustd.ch options).
> Anyhow it will not be enough because this example uses expressions
> in codeblock and Harbour optimize all codeblocks regardless of their
> position in the code and -kc switch.
> To make it fully compatible I will have to add to Harbour compiler
> additional code to emulate this Clipper behavior and disable codeblock
> optimization when -kc switch is used. I'll commit it in few minutes so
> please check it using Harbour compiled from new SVN code. You will
> have to use -ustd.ch and -kc switches to force exact CL5.2 behavior.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Przemek: .DBT and .FPT file confusion
Hi, 1) We're having a problem with our Harbour compiles not understanding the .DBT standard, when new .DBF files are created. I think it is assuming that when we create Memo fields on a new .DBF table, to assume we want the .FPT standard. However, our old DOS code stuff uses .DBT. Is there a flag to switch this? 2) On the topic of .DBT and .FPT files, since Harbour is so nice and modern, we are wondering which standard we should use. We used the .DBT stuff cause that's all there was "back in the day", and wondering if we should switch to something else. Thank you, 'o SIX3 database guru. :) -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Przemek: .DBT and .FPT file confusion
What I don't understand about these nice commands you've laid out is... does this interfere with the fact that I am including the ".ch" file for Harbours SIX implementation? I will admit, I know about 0.0001% of what you know about Clipper and SIX3... so I am unsure if these commands will magically work with our SIXCDX files. Hopefully this doesn't sound like a stupid question. -_- 2010/2/4 Przemysław Czerpak > On Thu, 04 Feb 2010, smu johnson wrote: > > Hi, > > > 1) We're having a problem with our Harbour compiles not understanding > the > > .DBT standard, when new .DBF files are created. I think it is assuming > that > > when we create Memo fields on a new .DBF table, to assume we want the > .FPT > > standard. However, our old DOS code stuff uses .DBT. Is there a flag to > > switch this? > > See rddInfo() function and RDDI_* macros in dbinfo.ch. > I.e. you can set DBT as default MEMO driver in DBFCDX RDD by: > rddInfo( RDDI_MEMOTYPE, DB_MEMO_DBT, "DBFCDX" ) > or SMT in DBFNTX by: > rddInfo( RDDI_MEMOTYPE, DB_MEMO_SMT, "DBFNTX" ) > > You can also create your own RDD using HBUSRRDD lib with prefered > memo type. > In /src/rdd/usrrdd/rdds/dbtcdx.prg is simple code which creates new > DBTCDX RDD which inherits from DBFCDX but uses DBT as default memo > type. > > The memo type is important only for new files (dbCreate()). > When existing DBF file is open Harbour automatically recognize type of > memo using information from DBF header and enable valid memo driver. > Of course if program which created DBF file set valid memo type signature. > > > 2) On the topic of .DBT and .FPT files, since Harbour is so nice and > > modern, we are wondering which standard we should use. We used the .DBT > > stuff cause that's all there was "back in the day", and wondering if we > > should switch to something else. > > Any you want. DBT allows to store only strings and uses 512 bytes blocks. > FPT allows to store also other data types (numbers, dates, arrays, ...) > and user can set block size (default is 64 bytes) so it's more flexible > and creates smaller files. > It also contains garbage collector which allow to reuse freed regions. > SMT is SIX3 format which have most of FPT features. > All formats are recognized by Harbour. In fact it even recognize different > implementations of FPT formats which can be controlled by: > rddInfo( RDDI_MEMOVERSION, DB_MEMOEXT_* [, ] ) > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13774] trunk/harbour
Viktor, I took a peek at the setpos.c commit change, and found:' 73 #if defined( HB_COMPAT_C53 ) || defined( HB_CLP_UNDOC ) I am wondering that the "protected by" means. I am unsure if I have to enable this HB_COMPAT_C53 setting or something manually if I want to take advantage of the Cl53 SETPOS() behaviour in Harbour. Thanks On Fri, Feb 5, 2010 at 2:26 AM, wrote: > Revision: 13774 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13774&view=rev > Author: vszakats > Date: 2010-02-05 10:26:13 + (Fri, 05 Feb 2010) > > Log Message: > --- > 2010-02-05 11:25 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * src/rtl/setpos.c > * src/rtl/console.c >! Fixed SETPOS() and DEVPOS() to return the first parameter > unconditionally. For SETPOS() it's protected with 'HB_CLP_UNDOC > or HB_COMPAT_C53', for DEVPOD() it's protected with 'HB_CLP_UNDOC' > only. > > * src/rtl/diskspac.c >* Using 'int' for drive spec. >* Minor cleanup. >; Please review me. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/src/rtl/console.c >trunk/harbour/src/rtl/diskspac.c >trunk/harbour/src/rtl/setpos.c > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] OFF: PDF417 barcode
I don't, but I have a CODE128 barcode generator I wrote from scratch in Clipper a few days ago, which switches between mode B and C efficiently, in case that helps. Probably not as your question is very specific, but maybe my thing could go in a contrib someday. On Fri, Feb 5, 2010 at 3:12 AM, Viktor Szakáts wrote: > Hi All, > > Does anyone have source code to generate PDF417 barcodes? > (using .ttf file or graphical shapes if possible) > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Hi guys, With Harbour, I am having to through a ton of code in order to convert all my tag names to uppercase... and I'm wondering if there is a way to make it so I do not have to do this with SIXCDX... because I am worried I will then have to find all the other commands like sx_killtag and make sure their tags are all uppercase too, etc etc. Clipper allowed us to be sloppy. Not saying that this is a good thing, but I am wondering if there is a switch I can set to prevent this behaviour, which might end up making me do an hour of work and a ton of mistakes if i screw something up. Any thoughts? I tried looking in the dbinfo.ch file but didn't seem to find anything relevant. Thank you -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HB_SETENV-like function, for HB_RUN child processes?
Hi, Viktor mentioned to me that I might have some luck with HB_SETENV to set ENV vars for child processes, though it would set the ENV's for the current process too. I was wondering if a new HB_ Harbour function could be made to do it for child processes, much like how Blinker's SWPSETENV() / SWPSETENVBAS() commands do ( http://www.ousob.com/ng/blinker/ng5ade2.php ). Since this might not be easy to do... perhaps an optional arg added to the HB_RUN command that allows some way to pass it ENV vars? Maybe that is too sloppy, I don't know. Thanks in advance for reading. PS: If anyone is curious, we are trying to change the PROMPT= when our main .PRG file calls "cmd.exe" to shell out in Windows to display anything we want, making it obvious to users that they are currently in a SHELL. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Well in the Clipper 5.2e w/ Six3 to Harbour migration, we are finding a ton of RTE problems because OrdSetFocus() calls and such are failing because this function seems to be case sensitive in Harbour. We haven't had any of these problems in our Clipper stuff. Sorry for not providing enough information earlier, I am not sure exactly what to provide. The senior programmer who wrote all this stuff simply told me to "go through our code and change all TAG ___'s and OF ___'s to uppercase so that we don't get any more lowercase / uppercase setordfocus RTE problems." Hope this is of some value to you. As far as me talking about sx_killtag, I only brought that up because when I was going through the .PRGs I found a lot of names that were used in my previous changes that my senior requested me to do, and started to become afraid that I was going to make a huge mistake... Hence I decided to ask the walking encyclopedia of Six3 knowledge. :) Let me know how I can best help you, if this isn't enough information. 2010/2/5 Przemysław Czerpak > On Fri, 05 Feb 2010, smu johnson wrote: > > Hi, > > > With Harbour, I am having to through a ton of code in order to convert > all > > my tag names to uppercase... and I'm wondering if there is a way to make > it > > so I do not have to do this with SIXCDX... because I am worried I will > then > > have to find all the other commands like sx_killtag and make sure their > tags > > are all uppercase too, etc etc. Clipper allowed us to be sloppy. > > I do not now why you have made such modification. > > > Not saying that this is a good thing, but I am wondering if there is a > > switch I can set to prevent this behaviour, which might end up making me > do > > an hour of work and a ton of mistakes if i screw something up. > > Any thoughts? I tried looking in the dbinfo.ch file but didn't seem to > find > > anything relevant. > > Sorry but as long as you will not explain what exactly you are doing and > why then we cannot help you. > > best regards, > Przemek > ___________ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Hi,
Sorry for the all the confusion. I sat down with my senior programmer and
finally got the bottom of the confusion.
It is actually two separate issues that I confused as one due to my lack of
Clipper knowledge.
Difference 1) ordsetfocus() if it cannot find a key you are looking for..
for instance if you run (with a typo) the ordsetfocus("isbnM") (notice the M
typo) twice, when I really was looking for "isbn"... it will return a blank
C string "" the 2nd time, because it cannot find "isbnM". Clipper instead
does not switch it to "", but retains the previously working key.
Difference 2) sx_indexname returned CAPS all the time in Clipper. Also,
with a few more differences. This is the workaround my senior has created
to deal with this.
***
FUNC BM_INDEXNAME(x,lNoPath) // SIMULATES THE SX_INDEXNAME() BUT STRIPS THE
PATH
// Harbour SX_Indexname() was not compat with SIX
// Harbour does not covert to uppercase
// Harbour return NIL instead of "" when no index is found
LOCAL CDXNAME:=SX_INDEXNAME(X)
LOCAL NPOS:=RAT("\",CDXNAME)
If ValType(CDXName)="C"
CDXName:=Upper(CDXName)
Endif
IF Valtype(lNoPath)="L".and.lNoPath .and. NPOS>0
CDXNAME:=SUBSTR(CDXNAME,NPOS+1)
ENDIF
RETURN CDXNAME
**
I think this will clear up the confusion earlier. I'm sorry for that. :(
But basically with these two things we are having to do, we are finding a
lot of our .PRGs need to be changed. If this now makes sense, could you
recommend some steps for us to take?
2010/2/5 Przemysław Czerpak
> On Fri, 05 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > Well in the Clipper 5.2e w/ Six3 to Harbour migration, we are finding a
> ton
> > of RTE problems because OrdSetFocus() calls and such are failing because
> > this function seems to be case sensitive in Harbour. We haven't had any
> of
> > these problems in our Clipper stuff.
>
> None of Harbour core RDDs uses cases sensitive tag names so above
> conclusion is false.
> Maybe you had some problems but they were not related to case sensitive
> tag or bag names.
>
>
> > Sorry for not providing enough information earlier, I am not sure exactly
> > what to provide. The senior programmer who wrote all this stuff simply
> told
> > me to "go through our code and change all TAG ___'s and OF ___'s to
> > uppercase so that we don't get any more lowercase / uppercase setordfocus
> > RTE problems."
>
> So you made sth absolutely unnecessary and the real problem still exist
> somewhere and you do not know where and what it is.
> BTW there is small undocumented difference in tag selection between
> ordSetFocus() and sx_setTag() but it's not bound with case sensitive
> indexes. You can see the difference in /src/rdd/hbsix/sxcompat.prg.
> In short words: sx_setTag() accepts bug numbers and when bug is specified
> as number or character then tag number is relative to this bug.
> in ordSetFocus() when tag number is set the bug is ignored.
>
> > Hope this is of some value to you. As far as me talking about
> sx_killtag,
> > I only brought that up because when I was going through the .PRGs I found
> a
> > lot of names that were used in my previous changes that my senior
> requested
> > me to do, and started to become afraid that I was going to make a huge
> > mistake... Hence I decided to ask the walking encyclopedia of Six3
> > knowledge. :)
> > Let me know how I can best help you, if this isn't enough information.
>
> Locate the real reason of problem. For sure in Harbour core RDDs tag
> selection is not case sensitive and I haven't heard about any problems
> reported by user that it's not.
>
> best regards,
> Przemek
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Thanks Przemek, this is also what my senior thought.
2010/2/5 Przemysław Czerpak
> On Fri, 05 Feb 2010, smu johnson wrote:
>
> Hi,
>
> > Difference 1) ordsetfocus() if it cannot find a key you are looking
> for..
> > for instance if you run (with a typo) the ordsetfocus("isbnM") (notice
> the M
> > typo) twice, when I really was looking for "isbn"... it will return a
> blank
> > C string "" the 2nd time, because it cannot find "isbnM". Clipper
> instead
> > does not switch it to "", but retains the previously working key.
>
> Not exactly.
> 1. The return value depends order set before you call ordSetFocus()
> and it doesn't matter what you specify as parameter. Of course the
> result can be different then you expected but in such case it was
> caused by wrongly selected tag in previous ordSetFocus() call.
>
> 2. When you specify wrong (not existing) tag name then the behavior
> depends on used RDD. Also in Clipper.
> In Clipper DBFNTX and SIX3 RDDs do not change the index but
> COMIX based RDDs change it to 0.
> In Harbour decided to use the same behavior in all RDDs and
> I chose COMIX CL53 DBFCDX like behavior because it allows help
> to find and eliminate typos in the code and I left such note
> in DBFNTX and DBFNSX:
> /*
> * In Clipper 5.3 DBFCDX (COMIX) when bad name or order is given
> * tag number is set to 0 (natural record order). CL52 RDDs and
> * SIX3 drivers do not change order in such case.
> * I'd like to keep the same behavior in all native [x]Harbour
> * RDDs and I chosen DBFCDX one as default. [druzus]
> */
>
> And this is the one difference.
> The empty string returned by ordSetFocus() is result of some other
> typos in previously called ordSetFocus() which switch the order to 0.
>
> My advice. Look for the typos and fix them. Otherwise you will keep
> code which make sth like:
> ordSetFocus( "wrongname" )
> [ do sth ]
> and above ordSetFocus() is redundant and can be deleted or it fails
> but only sometimes when the order set by some other code is different
> then expected.
> Changing the default behavior I chose does not resolve the problem
> but only hides it. Such code has to be fixed even in Clipper programs.
> Probably it will be good to add even more strict behavior here and
> generate RT error [tag not found] in such case. It should help to
> locate such problems in source code quite fast. I.e. you can use
> USRRDD and overload UR_ORDLSTFOCUS method to catch all such situations
> and report RTE. Then you should be able to find quite fast all typos by
> simple runtime code testes. You can even report such problems saving
> the information to file and emulating original SIX3 behavior.
>
> > Difference 2) sx_indexname returned CAPS all the time in Clipper. Also,
> > with a few more differences. This is the workaround my senior has
> created
> > to deal with this.
> > ***
> > FUNC BM_INDEXNAME(x,lNoPath) // SIMULATES THE SX_INDEXNAME() BUT STRIPS
> THE
> > PATH
> > // Harbour SX_Indexname() was not compat with SIX
> > // Harbour does not covert to uppercase
> > // Harbour return NIL instead of "" when no index is found
> > LOCAL CDXNAME:=SX_INDEXNAME(X)
> > LOCAL NPOS:=RAT("\",CDXNAME)
> > If ValType(CDXName)="C"
> > CDXName:=Upper(CDXName)
> > Endif
> > IF Valtype(lNoPath)="L".and.lNoPath .and. NPOS>0
> > CDXNAME:=SUBSTR(CDXNAME,NPOS+1)
> > ENDIF
> > RETURN CDXNAME
> > **
> > I think this will clear up the confusion earlier. I'm sorry for that. :(
> > But basically with these two things we are having to do, we are finding a
> > lot of our .PRGs need to be changed. If this now makes sense, could you
> > recommend some steps for us to take?
>
> Harbour works on systems using case sensitive file systems.
> Any conversions on file names are bugs for us. In the future you may
> want to migrate to some other systems like Linux, MacOSX or any other
> POSIX compatible system so I suggest to be really careful with forcing
> any upper/lower file names conversions. Otherwise you will ask about
> some other problem when:
> dbCreate( "Test", aStruct )
> use test
> will not work.
> Using such wrappers is quite good solution if you want to force upper
> names for comparison only and can be introduced in few minutes by simple
> S&R but if such function is used to make some operation on files then
> it's hardcoded only to case sens
Re: [Harbour] bug: ACHOICE()
Hi Viktor, see: http://lists.harbour-project.org/pipermail/harbour/2010-February/031590.html http://lists.harbour-project.org/pipermail/harbour/2010-February/031661.html In case you missed them. On Sat, Feb 6, 2010 at 3:51 AM, Viktor Szakáts wrote: > Hi All, > > In recent SVN, tests/ac_test.prg shows some problems > with ACHOICE(). It doesn't initially show to > selecting and RTEs (Bound Error) after moving > around. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug: ACHOICE()
I am curious about this ACHOICE stuff. It sounds as though Przemek thought it needed to be rewritten from scratch. Is that a big project to do, or likely to be done? I'm starting to think I'd be a lot more useful to the Harbour Project if I was a good C programmer. On Sat, Feb 6, 2010 at 7:30 AM, Viktor Szakáts wrote: > Hi, > > I didn't miss them, but what I reported look like new > errors after recent patches. > > Just run ac_test.prg, press , then -> RTE. > > It was okay in 2.0.0, but it's not okay in current trunk. > > Brgds, > Viktor > > On 2010 Feb 6, at 16:22, smu johnson wrote: > > > Hi Viktor, see: > > > > > http://lists.harbour-project.org/pipermail/harbour/2010-February/031590.html > > > > > http://lists.harbour-project.org/pipermail/harbour/2010-February/031661.html > > > > In case you missed them. > > > > On Sat, Feb 6, 2010 at 3:51 AM, Viktor Szakáts > wrote: > > Hi All, > > > > In recent SVN, tests/ac_test.prg shows some problems > > with ACHOICE(). It doesn't initially show to > > selecting and RTEs (Bound Error) after moving > > around. > > > > Brgds, > > Viktor > > > > ___________ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > -- > > smu johnson > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] bug: ACHOICE()
In order to do a lot of the other Clipper implementations, did the Harbour Project reverse engineer Clipper code, or was some source code donated from the original Clipper company? In this instance, would you have to just take an approximate guess as to how ACHOICE functions under any circumstance to try to be as close as possible to Clipper 5.3? On Sat, Feb 6, 2010 at 9:06 AM, Viktor Szakáts wrote: > > I am curious about this ACHOICE stuff. It sounds as though Przemek > thought it needed to be rewritten from scratch. Is that a big project to > do, or likely to be done? I'm starting to think I'd be a lot more useful to > the Harbour Project if I was a good C programmer. > > ACHOICE() (and also MEMOEDIT()) needs to be rewritten from scratch > IMO too. Can't tell how much work is ACHOICE(), but to make such > effort useful, I'd estimate large part of the work to be pure testing > to trace back what exactly needs to be implemented and how, to be > perfectly Clipper compatible. > > These parts don't need any .c programming skills, it's currently > written in .prg and it's perfect if any new implementation also use > .prg code. > > Brgds, > Viktor > > > On Sat, Feb 6, 2010 at 7:30 AM, Viktor Szakáts > wrote: > > Hi, > > > > I didn't miss them, but what I reported look like new > > errors after recent patches. > > > > Just run ac_test.prg, press , then -> RTE. > > > > It was okay in 2.0.0, but it's not okay in current trunk. > > > > Brgds, > > Viktor > > > > On 2010 Feb 6, at 16:22, smu johnson wrote: > > > > > Hi Viktor, see: > > > > > > > http://lists.harbour-project.org/pipermail/harbour/2010-February/031590.html > > > > > > > http://lists.harbour-project.org/pipermail/harbour/2010-February/031661.html > > > > > > In case you missed them. > > > > > > On Sat, Feb 6, 2010 at 3:51 AM, Viktor Szakáts > wrote: > > > Hi All, > > > > > > In recent SVN, tests/ac_test.prg shows some problems > > > with ACHOICE(). It doesn't initially show to > > > selecting and RTEs (Bound Error) after moving > > > around. > > > > > > Brgds, > > > Viktor > > > > > > ___ > > > Harbour mailing list (attachment size limit: 40KB) > > > Harbour@harbour-project.org > > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > > > > > -- > > > smu johnson > > > > > > ___ > > > Harbour mailing list (attachment size limit: 40KB) > > > Harbour@harbour-project.org > > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > -- > > smu johnson > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] GETREADER() oGet:postBlock / oGet type functions and blocks in Clipper 5.3 / Harbour?
Hi. After a bit of research, I see in the Norton Guides some reference to a bunch of objGet / oGet type functions. In our Clipper 5.2e APP, we have a GETSYS.PRG which seems to implement a lot of these functions. My guess is that Clipper 5.3 decided to make these functions part of the core, instead of giving you a GETSYS.PRG template? Anyways, the problem we're having is on line 157 of the following code. It hangs when a NIL is returned by the postBlock block. (I have no idea what / where the postBlock is even declared, as mentioned in my post to the Users maillist: http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html). To add a bit more confusion, I am not sure in Harbour / Clipper 5.3 you have to have this "getsys.prg" file. It seems we need for what we are doing, as you can see an added line of code on line 152 where my superior added some cursor modifications. My first guess would be to simply add some sort of VALTYPE == "L" check prior to doing the IF statement, but I am not sure if this is a problem with Harbour, or our own code. I thought I would ask here. If my post makes no sense to the developers, I will try to provide more code / info. Thanks in advance. 135 PROCEDURE GetReader( oGet ) 136 137// Read the GET if the WHEN condition is satisfied 138IF ( GetPreValidate( oGet ) ) 139 140 // Activate the GET for reading 141 oGet:setFocus() 142 143 WHILE ( oGet:exitState == GE_NOEXIT ) 144 145 // Check for initial typeout (no editable positions) 146 IF ( oGet:typeOut ) 147 oGet:exitState := GE_ENTER 148 ENDIF 149 150 // Apply keystrokes until exit 151 WHILE ( oGet:exitState == GE_NOEXIT ) 152 SETCURSOR(IIF( SET(_SET_INSERT),2,1)) // MIKE ADDED TO CHANGE CURSOR SHAPE 153 GetApplyKey( oGet, inkey( 0 ) ) 154 ENDDO 155 156 // Disallow exit if the VALID condition is not satisfied 157 IF ( !GetPostValidate( oGet ) ) 158 oGet:exitState := GE_NOEXIT 159 ENDIF 160 ENDDO 161 162 // De-activate the GET 163 oGet:killFocus() 164 165ENDIF 166 167RETURN 168 -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] oGet problems solved... because Harbour was Warning me for no reason!
Dear Harbour,
I have solved the whole oGet problems I was having, referenced by both of
the URLs below of the mailing list.
http://lists.harbour-project.org/pipermail/harbour/2010-February/031851.html
http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html
The problem was Harbour was Warning me about useless vals.
3:28 PM 2/5/2010
GL.PRG(419) Warning W0027 Meaningless use of expression 'String'
GL2.PRG(1460) Warning W0027 Meaningless use of expression 'String'
GL2.PRG(1469) Warning W0027 Meaningless use of expression 'String'
DATPROMO.PRG(10) Warning W0027 Meaningless use of expression 'String'
ORDERS.PRG(794) Warning W0027 Meaningless use of expression 'Logical'
ORDERS.PRG(2034) Warning W0027 Meaningless use of expression 'Logical'
RECONCIL.PRG(1029) Warning W0027 Meaningless use of expression 'String'
RECONCIL.PRG(1035) Warning W0027 Meaningless use of expression 'String'
CRMAIN.PRG(1837) Warning W0027 Meaningless use of expression 'Logical'
CRAUX2.PRG(78) Warning W0027 Meaningless use of expression 'Logical'
CRAUX2.PRG(465) Warning W0027 Meaningless use of expression 'String'
PROCESS.PRG(1497) Warning W0027 Meaningless use of expression 'String'
PROCESS.PRG(1510) Warning W0027 Meaningless use of expression 'String'
Phone.prg(5) Warning W0027 Meaningless use of expression 'String'
Turns out, these were not meaningless. They were in EVAL lines of code
where the "useless" value was needed to get the oGet stuff to work
properly. An example of a line of code:
Valid !lGiftCard .and. (lNegPrice .or. !CRPrice<0) .and.
iif(lNew.and.CRPrice#0,Eval({||SpecialPrice:=.t.,SetPrice:=SpecialPrice,.t.}),.t.)
As soon as I take out the "Meaningless" val, the warning stops when
compiling, but our .PRG hangs when the getReader() function is called and
breaks.
Maybe this could be considered a bug in Harbour, where it is warning me for
no reason?
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] oGet problems solved... because Harbour was Warning me for no reason!
Well... all I know is that upon making the Warning "come back" we don't get
a conditional BASE/ error. I just thought I'd pass it along, if anyone
cares to look into it.
The warnings don't really bother us really, so we don't mind seeing them if
nothing needs to be changed in this regard with Harbour warning messages.
Keep up the great work!!
On Mon, Feb 8, 2010 at 2:03 PM, Viktor Szakáts wrote:
> Hi,
>
> I'd suggest to take a look at .ppo file generated, as I'm
> 100% sure that the meaningless expression is not wrong.
> Maybe you need to code it differently to avoid it. Or,
> just turn off warnings, if that's not an option.
>
> From personal experience it's sometimes difficult to
> see why compiler warns, but so far it was right on all
> cases.
>
> Brgds,
> Viktor
>
> On 2010 Feb 8, at 22:55, smu johnson wrote:
>
> > Dear Harbour,
> >
> > I have solved the whole oGet problems I was having, referenced by both of
> the URLs below of the mailing list.
> >
> >
> http://lists.harbour-project.org/pipermail/harbour/2010-February/031851.html
> >
> http://lists.harbour-project.org/pipermail/harbour-users/2010-February/000314.html
> >
> > The problem was Harbour was Warning me about useless vals.
> >
> > 3:28 PM 2/5/2010
> > GL.PRG(419) Warning W0027 Meaningless use of expression 'String'
> > GL2.PRG(1460) Warning W0027 Meaningless use of expression 'String'
> > GL2.PRG(1469) Warning W0027 Meaningless use of expression 'String'
> > DATPROMO.PRG(10) Warning W0027 Meaningless use of expression 'String'
> > ORDERS.PRG(794) Warning W0027 Meaningless use of expression 'Logical'
> > ORDERS.PRG(2034) Warning W0027 Meaningless use of expression 'Logical'
> > RECONCIL.PRG(1029) Warning W0027 Meaningless use of expression 'String'
> > RECONCIL.PRG(1035) Warning W0027 Meaningless use of expression 'String'
> > CRMAIN.PRG(1837) Warning W0027 Meaningless use of expression 'Logical'
> > CRAUX2.PRG(78) Warning W0027 Meaningless use of expression 'Logical'
> > CRAUX2.PRG(465) Warning W0027 Meaningless use of expression 'String'
> > PROCESS.PRG(1497) Warning W0027 Meaningless use of expression 'String'
> > PROCESS.PRG(1510) Warning W0027 Meaningless use of expression 'String'
> > Phone.prg(5) Warning W0027 Meaningless use of expression 'String'
> >
> > Turns out, these were not meaningless. They were in EVAL lines of code
> where the "useless" value was needed to get the oGet stuff to work properly.
> An example of a line of code:
> >
> > Valid !lGiftCard .and. (lNegPrice .or. !CRPrice<0) .and.
> iif(lNew.and.CRPrice#0,Eval({||SpecialPrice:=.t.,SetPrice:=SpecialPrice,.t.}),.t.)
> >
> > As soon as I take out the "Meaningless" val, the warning stops when
> compiling, but our .PRG hangs when the getReader() function is called and
> breaks.
> >
> > Maybe this could be considered a bug in Harbour, where it is warning me
> for no reason?
> >
> > --
> > smu johnson
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] KSETINS() bug, making MEMOEDIT life difficult
Dear Harbour Devs, We are having a real hassle getting MEMOEDIT() to start editing with the INSERT mode, because KSETINS() that clipper tools provides doesn't work. (neither does KSETNUM). I am not sure about KSETCAPS etc but I would take a guess that they don't work either. When insert is .T. in memoedit mode, you can hit enter, and separate lines, etc etc, much like how Windows notepad.exe behaves in its regular mode. In Clipper 5.2e + Funcky the INSERT() function they provide is identical as far as its function prototype, but works well in the DOS world as well as 32-bit Windows dos emu world. Perhaps the Clipper-Tools KSET* funcs could be fixed... or maybe HB_SET* functions made? Any thoughts? Thank you. So far, these issues are showing up on Win XP Pro, and Win 7 64-bit. PS: We've seen some other MEMOEDIT bugs... and I remember reading that Viktor thought it could use a definite rewrite. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] KSETINS() bug, making MEMOEDIT life difficult
Hi. I found that READINSERT() does the job, and is part of Clipper 5.3 Hip hip hurray! On Fri, Feb 12, 2010 at 2:16 PM, Viktor Szakáts wrote: > Hi, > > > We are having a real hassle getting MEMOEDIT() to start editing with the > INSERT mode, because KSETINS() that clipper tools provides doesn't work. > (neither does KSETNUM). I am not sure about KSETCAPS etc but I would take > a guess that they don't work either. When insert is .T. in memoedit mode, > you can hit enter, and separate lines, etc etc, much like how Windows > notepad.exe behaves in its regular mode. > > Just try with plain Clipper SET( _SET_INSERT, ). > > > In Clipper 5.2e + Funcky the INSERT() function they provide is identical > as far as its function prototype, but works well in the DOS world as well as > 32-bit Windows dos emu world. > > > > Perhaps the Clipper-Tools KSET* funcs could be fixed... or maybe HB_SET* > functions made? > > These don't seem very portable functions, so hopefully > someone will fix them in hbct, if possible at all under > non-DOS OSes. Remember these are system wide keyboard > settings normally controlled by user, so I wouldn't be > surprised if some OSes wouldn't provide a way to alter > it programmatically to avoid apps taking over these > thing. > > F.e. except forcing keyboard to CAPS, maybe it's more > user friendly and portable approach to convert input > to uppercase on app level. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] KSETINS() bug, making MEMOEDIT life difficult
Thanks for the hints. My stuff is closer to working! Another inconsistency I found in MEMOEDIT is the CTRL-END key. In Harbour, it escapes out. In clipper, it goes to the bottom right hand section of the memo. On Fri, Feb 12, 2010 at 2:43 PM, Viktor Szakáts wrote: > > Hi. I found that READINSERT() does the job, and is part of Clipper 5.3 > > It's a wrapper to SET( _SET_INSERT ). > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] KSETINS() bug, making MEMOEDIT life difficult
Ok, I will try the new editor. One last thing to say about MEMOEDIT... there is a word-wrapping bug. http://209.97.219.2/sjohnson/misc/scrnshots/wordwrap-bug.png Notice the spaces between the 's and the 's. I will take a guess that HBEDITOR doesn't have this problem? :) On Fri, Feb 12, 2010 at 3:26 PM, Viktor Szakáts wrote: > On 2010 Feb 13, at 00:14, smu johnson wrote: > > > Thanks for the hints. My stuff is closer to working! > > > > Another inconsistency I found in MEMOEDIT is the CTRL-END key. In > Harbour, it escapes out. In clipper, it goes to the bottom right hand > section of the memo. > > NG says that Ctlr+W ends editing, and Ctrl+W has > the same key code as Ctrl+End, so to me it looks > consistent, I don't know what you experience. > > Anyhow I've fixed Ctrl+End/Esc/Ctrl+W related problems > at least a dozen times, I'll now leave the rest for > someone with remaining nerves to waste on this area. > > In general I'd suggest to forget MEMOEDIT() completely > and use HBEDITOR class directly. It gives much > better control and all these 110% compatibility > problems can be easily avoided. MEMOEDIT() in > Harbour is based on HBEDITOR. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] KSETINS() bug, making MEMOEDIT life difficult
For me I do not get Ctrl+End as being the same as CTRL-W. ? INKEY(0) /* CTRL-END 415 CTRL-W 23 */ On Fri, Feb 12, 2010 at 3:26 PM, Viktor Szakáts wrote: > On 2010 Feb 13, at 00:14, smu johnson wrote: > > > Thanks for the hints. My stuff is closer to working! > > > > Another inconsistency I found in MEMOEDIT is the CTRL-END key. In > Harbour, it escapes out. In clipper, it goes to the bottom right hand > section of the memo. > > NG says that Ctlr+W ends editing, and Ctrl+W has > the same key code as Ctrl+End, so to me it looks > consistent, I don't know what you experience. > > Anyhow I've fixed Ctrl+End/Esc/Ctrl+W related problems > at least a dozen times, I'll now leave the rest for > someone with remaining nerves to waste on this area. > > In general I'd suggest to forget MEMOEDIT() completely > and use HBEDITOR class directly. It gives much > better control and all these 110% compatibility > problems can be easily avoided. MEMOEDIT() in > Harbour is based on HBEDITOR. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] KSETINS() bug, making MEMOEDIT life difficult
Sorry Viktor, i accidently hit ALT- instead of CTRL. In my little test, I see that it is indeed 23. I am sorry to waste your time with that. One last question if i may... in order to use the new editor instead of a MEMOEDIT call, do I need to learn and write a ton of OOP type Clipper syntax to get this to work? On Fri, Feb 12, 2010 at 4:05 PM, Viktor Szakáts wrote: > Please always compare with plain CA-Clipper > without local patches, modification, or extra > libraries. > > 415 is Alt+End in CA-Clipper INKEY.CH. You must > be using an altered version of this header, or > some other local solution. > > Brgds, > Viktor > > On 2010 Feb 13, at 00:39, smu johnson wrote: > > > For me I do not get Ctrl+End as being the same as CTRL-W. > > > > ? INKEY(0) > > > > /* > > CTRL-END 415 > > CTRL-W 23 > > */ > > > > > > On Fri, Feb 12, 2010 at 3:26 PM, Viktor Szakáts > wrote: > > On 2010 Feb 13, at 00:14, smu johnson wrote: > > > > > Thanks for the hints. My stuff is closer to working! > > > > > > Another inconsistency I found in MEMOEDIT is the CTRL-END key. In > Harbour, it escapes out. In clipper, it goes to the bottom right hand > section of the memo. > > > > NG says that Ctlr+W ends editing, and Ctrl+W has > > the same key code as Ctrl+End, so to me it looks > > consistent, I don't know what you experience. > > > > Anyhow I've fixed Ctrl+End/Esc/Ctrl+W related problems > > at least a dozen times, I'll now leave the rest for > > someone with remaining nerves to waste on this area. > > > > In general I'd suggest to forget MEMOEDIT() completely > > and use HBEDITOR class directly. It gives much > > better control and all these 110% compatibility > > problems can be easily avoided. MEMOEDIT() in > > Harbour is based on HBEDITOR. > > > > Brgds, > > Viktor > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > -- > > smu johnson > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Viktor, Does this mean that all the Extended Ascii chars from the DOS world will disappear and turn into their latin-1 / utf-8 equivalents? 2010/2/15 "網緹資訊‧廖文勝(WenSheng)" > > In Asia, we are very needed him. > > > +1 UNICODE mode for window build > > What steep for give harbour "full unicode support"? > > > > 2010/2/15 Viktor Szak嫢s > > > > > Hi All, > > > > > > I'd like to gather opinions on switching default Harbour > > > Windows builds to UNICODE mode in next major release. > > > > > > Advantages: > > > - Runs more efficiently on NT-class OSes since > > >we're using native API instead of ANSI wrappers, > > >and the OS-level CP conversion is saved also. > > > - Harbour level CP configuration is much easier for GTs. > > > - Will run even more efficiently when implementing > > >native UNICODE support inside HVM. > > > - Some languages can only be supported in UNICODE mode. > > > - We're in sync with all Harbour Windows builds and > > >also with WinCE builds, which already have UNICODE > > >enabled. > > > > > > Disadvantage: > > > - Apps won't run on Win9x OSes anymore. Here there > > >exists a solution, unicows lib: > > >http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx > > > > > > Notes: > > > - UNICODE is already enabled by default for > > >MSVC 2005 and upper, and WinCE. MSVC 2008 > > >and upper doesn't even support non-UNICODE > > >anymore. > > > - non-UNICODE can be enabled for custom Harbour > > >builds anytime using build-time option: > > > HB_BUILD_UNICODE=no. > > > > > > Opinions? > > > > > > Brgds, > > > Viktor > > > > > > ___ > > > Harbour mailing list (attachment size limit: 40KB) > > > Harbour@harbour-project.org > > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > > > > -- > > Massimo Belgrano > > Wang Ti information CO. of Taiwan > http://www.zzz.com.tw/ > mailto:ss...@mail.zzz.com.tw > Yahoo: ssbbstw > MSN:ssb...@hotmail.com > Skype:ssbbstw > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Then I'm + in favour! I'm all for UNICODE finally becoming the default for
things world-wide.
2010/2/15 Viktor Szakáts
> Hi Smu,
>
> On 2010 Feb 15, at 21:20, smu johnson wrote:
>
> > Viktor,
> >
> > Does this mean that all the Extended Ascii chars from the DOS world will
> disappear and turn into their latin-1 / utf-8 equivalents?
>
> No, it's an internal change specific to Windows platform,
> and it means that Harbour core and contrib will use UNICODE
> ("WIDE") Windows API calls, as opposed to "ANSI" ones.
>
> It's only a difference in Harbour code interfaces with Windows.
>
> This may mean that on app level some things have to be tweaked
> to work in this case (*), but overall it makes things simpler
> to manage, and this change is transparent for the most part
> on the app level. We're in development phase, so any show
> stoppers that may happen to remain, can be fixed. We're using
> UNICODE with MSVC and WinCE since some time, so the situation
> is rather good.
>
> (*) The only such case that comes to mind is printing ASCII
> line drawing chars using hbwin GDI printing engine.
>
> Brgds,
> Viktor
>
>
> >
> > 2010/2/15 "網緹資訊•廖文勝(WenSheng)"
> >
> > In Asia, we are very needed him.
> >
> > > +1 UNICODE mode for window build
> > > What steep for give harbour "full unicode support"?
> > >
> > > 2010/2/15 Viktor Szak嫢s
> > >
> > > > Hi All,
> > > >
> > > > I'd like to gather opinions on switching default Harbour
> > > > Windows builds to UNICODE mode in next major release.
> > > >
> > > > Advantages:
> > > > - Runs more efficiently on NT-class OSes since
> > > >we're using native API instead of ANSI wrappers,
> > > >and the OS-level CP conversion is saved also.
> > > > - Harbour level CP configuration is much easier for GTs.
> > > > - Will run even more efficiently when implementing
> > > >native UNICODE support inside HVM.
> > > > - Some languages can only be supported in UNICODE mode.
> > > > - We're in sync with all Harbour Windows builds and
> > > >also with WinCE builds, which already have UNICODE
> > > >enabled.
> > > >
> > > > Disadvantage:
> > > > - Apps won't run on Win9x OSes anymore. Here there
> > > >exists a solution, unicows lib:
> > > >http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
> > > >
> > > > Notes:
> > > > - UNICODE is already enabled by default for
> > > >MSVC 2005 and upper, and WinCE. MSVC 2008
> > > >and upper doesn't even support non-UNICODE
> > > >anymore.
> > > > - non-UNICODE can be enabled for custom Harbour
> > > >builds anytime using build-time option:
> > > > HB_BUILD_UNICODE=no.
> > > >
> > > > Opinions?
> > > >
> > > > Brgds,
> > > > Viktor
> > > >
> > > > ___
> > > > Harbour mailing list (attachment size limit: 40KB)
> > > > Harbour@harbour-project.org
> > > > http://lists.harbour-project.org/mailman/listinfo/harbour
> > > >
> > >
> > >
> > >
> > > --
> > > Massimo Belgrano
> >
> > Wang Ti information CO. of Taiwan
> > http://www.zzz.com.tw/
> > mailto:ss...@mail.zzz.com.tw
> > Yahoo: ssbbstw
> > MSN:ssb...@hotmail.com
> > Skype:ssbbstw
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
> >
> >
> >
> > --
> > smu johnson
> >
> > ___
> > Harbour mailing list (attachment size limit: 40KB)
> > Harbour@harbour-project.org
> > http://lists.harbour-project.org/mailman/listinfo/harbour
>
> ___
> Harbour mailing list (attachment size limit: 40KB)
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
--
smu johnson
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Crash in rev 13881
Hi, This is the first actual crash I can report. I am not quite sure what to do... May I could just wait patiently for a newer version? --- Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:0048C6B2 EAX:00582300 EBX:0028F73C ECX:0037CE9C EDX:0048C6B0 ESI:00581870 EDI:00363804 EBP: CS:EIP:0023:0048C6B2 SS:ESP:002B:0028F70C DS:002B ES:002B FS:0053 GS:002B Flags:00010282 CS:EIP: 00 8B 44 24 2C 8B 4C 24 78 8B 54 24 64 8B 74 24 SS:ESP: 0042A12A 0036424C 00581870 0028F73C 00436A05 0019 8000 0003 00453DFC 0036422C 003672D4 002F 00DE 00370324 00470005 C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... Modules: 0x0040 0x00332000 F:\ver10\latest\BKMNGR.EXE 0x76E9 0x0018 C:\Windows\SysWOW64\ntdll.dll 0x7506 0x0010 C:\Windows\syswow64\kernel32.dll 0x74F9 0x00046000 C:\Windows\syswow64\KERNELBASE.dll 0x74A7 0x000AC000 C:\Windows\syswow64\msvcrt.dll 0x7571 0x0010 C:\Windows\syswow64\USER32.dll 0x7648 0x0009 C:\Windows\syswow64\GDI32.dll 0x74A6 0xA000 C:\Windows\syswow64\LPK.dll 0x7567 0x0009D000 C:\Windows\syswow64\USP10.dll 0x751E 0x000A C:\Windows\syswow64\ADVAPI32.dll 0x7504 0x00019000 C:\Windows\SysWOW64\sechost.dll 0x74CF 0x000F C:\Windows\syswow64\RPCRT4.dll 0x74A0 0x0006 C:\Windows\syswow64\SspiCli.dll 0x749F 0xC000 C:\Windows\syswow64\CRYPTBASE.dll 0x74F3 0x0006 C:\Windows\system32\IMM32.DLL 0x7548 0x000CC000 C:\Windows\syswow64\MSCTF.dll Called from HBMEMOEDITOR:DISPLAY(0) in ../../../teditor.prg Called from MEMOEDIT(0) in ../../../memoedit.prg Called from MSGWAIT(46) in FRAMES.PRG Called from ACTIVEUSERS(276) in 1BMMENU.PRG Called from CHECKSYS(280) in CHECKSYS.PRG Called from BM(423) in BM.PRG Called from MAIN(38) in main.PRG -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[13871] trunk/harbour
Nice work on ACHOICE Viktor On Sun, Feb 14, 2010 at 4:58 AM, wrote: > Revision: 13871 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13871&view=rev > Author: vszakats > Date: 2010-02-14 12:58:20 + (Sun, 14 Feb 2010) > > Log Message: > --- > 2010-02-14 13:57 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * src/rtl/achoice.prg >! Fixed/added cursor positioning to resemble to Clipper. > > * tests/ac_test.prg >+ Shows row/col when entering callback function. > > * contrib/hbfimage/fi_winfu.c > * contrib/hbfimage/fi_wrp.c >* Formatting. > > * contrib/hbwin/hbdyn.c >- Deleted recently added, but finally unused union member. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbfimage/fi_winfu.c >trunk/harbour/contrib/hbfimage/fi_wrp.c >trunk/harbour/contrib/hbwin/hbdyn.c >trunk/harbour/src/rtl/achoice.prg >trunk/harbour/tests/ac_test.prg > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Actually, that part where they won't run in Win9x anymore got me worried. Do you mean won't run _at all_, or just won't run UNICODE stuff properly. We have a few people who use Windows 98 who will use your Harbour compiled .exe files. If you mean they won't run period, then maybe there could be a harbour.exe compiler switch? I dunno... Please let me know. On Mon, Feb 15, 2010 at 1:14 AM, Viktor Szakáts wrote: > Hi All, > > I'd like to gather opinions on switching default Harbour > Windows builds to UNICODE mode in next major release. > > Advantages: > - Runs more efficiently on NT-class OSes since >we're using native API instead of ANSI wrappers, >and the OS-level CP conversion is saved also. > - Harbour level CP configuration is much easier for GTs. > - Will run even more efficiently when implementing >native UNICODE support inside HVM. > - Some languages can only be supported in UNICODE mode. > - We're in sync with all Harbour Windows builds and >also with WinCE builds, which already have UNICODE >enabled. > > Disadvantage: > - Apps won't run on Win9x OSes anymore. Here there >exists a solution, unicows lib: >http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx > > Notes: > - UNICODE is already enabled by default for >MSVC 2005 and upper, and WinCE. MSVC 2008 >and upper doesn't even support non-UNICODE >anymore. > - non-UNICODE can be enabled for custom Harbour >builds anytime using build-time option: > HB_BUILD_UNICODE=no. > > Opinions? > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Ahh I feel kind of stupid. Having reread your original e-mail, it looks like simply the Harbour Project won't run on Win9x anymore, not the .EXE's that Harbour makes. On Mon, Feb 15, 2010 at 6:08 PM, smu johnson wrote: > Actually, that part where they won't run in Win9x anymore got me worried. > Do you mean won't run _at all_, or just won't run UNICODE stuff properly. > > We have a few people who use Windows 98 who will use your Harbour compiled > .exe files. If you mean they won't run period, then maybe there could be a > harbour.exe compiler switch? I dunno... Please let me know. > > > On Mon, Feb 15, 2010 at 1:14 AM, Viktor Szakáts wrote: > >> Hi All, >> >> I'd like to gather opinions on switching default Harbour >> Windows builds to UNICODE mode in next major release. >> >> Advantages: >> - Runs more efficiently on NT-class OSes since >>we're using native API instead of ANSI wrappers, >>and the OS-level CP conversion is saved also. >> - Harbour level CP configuration is much easier for GTs. >> - Will run even more efficiently when implementing >>native UNICODE support inside HVM. >> - Some languages can only be supported in UNICODE mode. >> - We're in sync with all Harbour Windows builds and >>also with WinCE builds, which already have UNICODE >>enabled. >> >> Disadvantage: >> - Apps won't run on Win9x OSes anymore. Here there >>exists a solution, unicows lib: >>http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx >> >> Notes: >> - UNICODE is already enabled by default for >>MSVC 2005 and upper, and WinCE. MSVC 2008 >>and upper doesn't even support non-UNICODE >>anymore. >> - non-UNICODE can be enabled for custom Harbour >>builds anytime using build-time option: >> HB_BUILD_UNICODE=no. >> >> Opinions? >> >> Brgds, >> Viktor >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > > > > -- > smu johnson > > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Crash in rev 13881
Hi, I would have replied to this thread earlier if I could simply "reply" to it via gmail... But anyways... my program started crashing with all sorts of BASE/ errors after I kept retrying it. Then I just rebooted and never saw these errors again. The only thing I can think of that I did as far as these errors coming was I used a ramdisk program to compile Harbour. I rebooted, and never saw the crash again... tested it on a few other computers too. So maybe I won't worry about it now. Thanks for replying Przemek. I will let you know if it ever happens again. It had me worried! 2010/2/16 Przemysław Czerpak > On Mon, 15 Feb 2010, smu johnson wrote: > > Hi, > > > This is the first actual crash I can report. I am not quite sure what to > > do... May I could just wait patiently for a newer version? > > --- > > Called from HBMEMOEDITOR:DISPLAY(0) in ../../../teditor.prg > > Called from MEMOEDIT(0) in ../../../memoedit.prg > > Called from MSGWAIT(46) in FRAMES.PRG > > Called from ACTIVEUSERS(276) in 1BMMENU.PRG > > Called from CHECKSYS(280) in CHECKSYS.PRG > > Called from BM(423) in BM.PRG > > Called from MAIN(38) in main.PRG > > Which Harbour version have you used? (2.0.0 or 2.1.x from SVN?) > Is it repeatable? > If yes can you copy src/rtl/teditor.prg to your source code project > to check and rebuild your application so we can check the exact line > where it fails. > The we probably ask you about parameters. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
When you say "won't run on Win9x" do you mean harbour.exe and tools, or do you mean .EXE's generated with Harbour? On Tue, Feb 16, 2010 at 12:08 AM, Viktor Szakáts wrote: > Hi, > > On 2010 Feb 16, at 03:08, smu johnson wrote: > > > Actually, that part where they won't run in Win9x anymore got me worried. > Do you mean won't run _at all_, or just won't run UNICODE stuff properly. > > At all. Win9x doesn't support UNICODE. > > There is way to solve it, but it's currently > not developed to Harbour: unicows lib or opencows lib, > you supply an extra .dll for your UNICODE app to > run on Win9x. > > > We have a few people who use Windows 98 who will use your Harbour > compiled .exe files. If you mean they won't run period, then maybe there > could be a harbour.exe compiler switch? I dunno... Please let me know. > > There is a build-time switch, so it's possible to > create a build which runs on Win9x. > > We're discussing the default of this build-time switch. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Uh oh. Will the compile switch make it work with any version of Windows, as it currently does? On Tue, Feb 16, 2010 at 1:04 AM, Viktor Szakáts wrote: > > When you say "won't run on Win9x" do you mean harbour.exe and tools, or > do you mean .EXE's generated with Harbour? > > Both. > > Since Harbour core libs will contain references to > Windows UNICODE functions, anything that uses these > core libs won't (by default) run on Win9x. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Crash in rev 13881
It is hard to find a decent ramdisk piece of software for windows these days... :( I appreciate the reply though. No more ramdisk stuff for me. 2010/2/16 Przemysław Czerpak > On Tue, 16 Feb 2010, smu johnson wrote: > > Hi, > > > I would have replied to this thread earlier if I could simply "reply" to > it > > via gmail... But anyways... my program started crashing with all sorts > of > > BASE/ errors after I kept retrying it. Then I just rebooted and never > saw > > these errors again. The only thing I can think of that I did as far as > > these errors coming was I used a ramdisk program to compile Harbour. I > > rebooted, and never saw the crash again... tested it on a few other > > computers too. So maybe I won't worry about it now. > > Thanks for replying Przemek. I will let you know if it ever happens > again. > > It had me worried! > > Probably not. Many of such ramdisk emulators has bugs which can cause > data corruption in some cases and then any other bad side effects so > it was probably the source of problems. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] win - making UNICODE the default
Forgive the stupid question, but the only switch I'm worried about it is how it behaves now. ie, Harbour compiled .exe's run on Win9x -> Windows 7 64bit. I take it though, that "set HB_BUILD_UNICODE=no" will accomplish this, when Viktor's plan goes through for the future edition. Thanks 2010/2/16 Przemysław Czerpak > On Tue, 16 Feb 2010, smu johnson wrote: > > Uh oh. Will the compile switch make it work with any version of Windows, > as > > it currently does? > > You will have to recompile core Harbour code with: > set HB_BUILD_UNICODE=no > Then Harbour compiler and final binaries created by Harbour compiler > will work on Win9x. > > Now above set is default for most of desktop MS-Windows builds and only > WinCE and new MSVC builds uses > set HB_BUILD_UNICODE=yes > because they do not support pure ASCII API. > Viktor wants to make > set HB_BUILD_UNICODE=yes > default in all MS-Windows builds. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] GCC distribution
Well... are you using Ubuntu? sudo apt-get install build-essential On Wed, Feb 17, 2010 at 11:11 AM, Bruno Luciani wrote: > anybody knows where I can find an standalone Linux GCC distribution ? > > Similar to Mingw format distribution ? > > I need a basic compiler to add to a harbour qt project. > > Thanks for any Idea > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Switch to detect undeclared vars being used
Hi, Since using Harbour from Clipper 5.2e, we'd have a few minor problems, and a lot of success. One thing that will make our lives easier in 100,000 lines of Clipper code is some sort of switch in Harbour / hbmk2 that will warn you if you are using a variable that wasn't declared by LOCAL, PRIV, MEMVAR, etc etc... in a function. For example, if I do: FUNC GOOSE() LOCAL x, y FOR i := 1 TO 10 ? i NEXT RETURN It would warn me upon compilation that "i" isn't declared in the Function. Maybe I am asking too much, as I don't think it's technically wrong. Just that we have a lot of code where the original author forgot to keep his var declarations clean, and write LOCAL i after the FUNC declaration. I tried looking through the switches that Harbour.exe provides... but I couldn't find anything relevant. Thank you. Any thoughts / criticisms welcome. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Hi,
I was curious if a some sort of compability switch / flag could be enabled
to toggle the ordsetfocus() to behave like Clipper 5.2e (or higher, not sure
if it is different in 5.3) to not change the focus if it cannot find what is
in the argument. The way it behaves now is good for fixing bugs and stuff,
and I'm happy with it... but my senior has asked me to ask you in case it
can be done, as he will probably do that to start off with so we don't get
RTE errors, even if it is sloppy.
Any thoughts?
2010/2/5 smu johnson
> Thanks Przemek, this is also what my senior thought.
>
>
> 2010/2/5 Przemysław Czerpak
>
>> On Fri, 05 Feb 2010, smu johnson wrote:
>>
>> Hi,
>>
>> > Difference 1) ordsetfocus() if it cannot find a key you are looking
>> for..
>> > for instance if you run (with a typo) the ordsetfocus("isbnM") (notice
>> the M
>> > typo) twice, when I really was looking for "isbn"... it will return a
>> blank
>> > C string "" the 2nd time, because it cannot find "isbnM". Clipper
>> instead
>> > does not switch it to "", but retains the previously working key.
>>
>> Not exactly.
>> 1. The return value depends order set before you call ordSetFocus()
>> and it doesn't matter what you specify as parameter. Of course the
>> result can be different then you expected but in such case it was
>> caused by wrongly selected tag in previous ordSetFocus() call.
>>
>> 2. When you specify wrong (not existing) tag name then the behavior
>> depends on used RDD. Also in Clipper.
>> In Clipper DBFNTX and SIX3 RDDs do not change the index but
>> COMIX based RDDs change it to 0.
>> In Harbour decided to use the same behavior in all RDDs and
>> I chose COMIX CL53 DBFCDX like behavior because it allows help
>> to find and eliminate typos in the code and I left such note
>> in DBFNTX and DBFNSX:
>> /*
>> * In Clipper 5.3 DBFCDX (COMIX) when bad name or order is given
>> * tag number is set to 0 (natural record order). CL52 RDDs and
>> * SIX3 drivers do not change order in such case.
>> * I'd like to keep the same behavior in all native [x]Harbour
>> * RDDs and I chosen DBFCDX one as default. [druzus]
>> */
>>
>> And this is the one difference.
>> The empty string returned by ordSetFocus() is result of some other
>> typos in previously called ordSetFocus() which switch the order to 0.
>>
>> My advice. Look for the typos and fix them. Otherwise you will keep
>> code which make sth like:
>> ordSetFocus( "wrongname" )
>> [ do sth ]
>> and above ordSetFocus() is redundant and can be deleted or it fails
>> but only sometimes when the order set by some other code is different
>> then expected.
>> Changing the default behavior I chose does not resolve the problem
>> but only hides it. Such code has to be fixed even in Clipper programs.
>> Probably it will be good to add even more strict behavior here and
>> generate RT error [tag not found] in such case. It should help to
>> locate such problems in source code quite fast. I.e. you can use
>> USRRDD and overload UR_ORDLSTFOCUS method to catch all such situations
>> and report RTE. Then you should be able to find quite fast all typos by
>> simple runtime code testes. You can even report such problems saving
>> the information to file and emulating original SIX3 behavior.
>>
>> > Difference 2) sx_indexname returned CAPS all the time in Clipper.
>> Also,
>> > with a few more differences. This is the workaround my senior has
>> created
>> > to deal with this.
>> > ***
>> > FUNC BM_INDEXNAME(x,lNoPath) // SIMULATES THE SX_INDEXNAME() BUT STRIPS
>> THE
>> > PATH
>> > // Harbour SX_Indexname() was not compat with SIX
>> > // Harbour does not covert to uppercase
>> > // Harbour return NIL instead of "" when no index is found
>> > LOCAL CDXNAME:=SX_INDEXNAME(X)
>> > LOCAL NPOS:=RAT("\",CDXNAME)
>> > If ValType(CDXName)="C"
>> > CDXName:=Upper(CDXName)
>> > Endif
>> > IF Valtype(lNoPath)="L".and.lNoPath .and. NPOS>0
>> > CDXNAME:=SUBSTR(CDXNAME,NPOS+1)
>> > ENDIF
>> > RETURN CDXNAME
>> > **
>> > I think this will clear up the confusion earlier. I'm sorry for that.
>> :(
>> > But basically with these two things we are having to do, we are finding
>
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
Oops.. i mean Viktor
2010/2/22 smu johnson
> I agree with your opinion too. I'm a bit anally-retentive when it comes to
> just fixing the root bugs in the first place.
>
> I am curious though... what kind of stuff would HB_CLP_STRICT do for me?
> I grepped the src tree but couldn't quite get the answer.
>
> Thanks przemek
>
>
>
> 2010/2/22 Viktor Szakáts
>
> I think it's not very good to add knobs that
>> bend behavior for undefined/undocumented cases.
>>
>> We will end up with 100 such options, and no
>> one will know what they are, and we will create
>> incompatibility/unportability between Harbour code.
>>
>> Maybe turning on HB_CLP_STRICT build-time option
>> could be a solution to your problem. But overall
>> I think you lose more than you gain.
>>
>> Better to fix the code.
>>
>> Brgds,
>> Viktor
>>
>> On 2010 Feb 22, at 21:21, smu johnson wrote:
>>
>> > Hi,
>> >
>> > I was curious if a some sort of compability switch / flag could be
>> enabled to toggle the ordsetfocus() to behave like Clipper 5.2e (or higher,
>> not sure if it is different in 5.3) to not change the focus if it cannot
>> find what is in the argument. The way it behaves now is good for fixing
>> bugs and stuff, and I'm happy with it... but my senior has asked me to ask
>> you in case it can be done, as he will probably do that to start off with so
>> we don't get RTE errors, even if it is sloppy.
>> >
>> > Any thoughts?
>> >
>> >
>> > 2010/2/5 smu johnson
>> > Thanks Przemek, this is also what my senior thought.
>> >
>> >
>> > 2010/2/5 Przemysław Czerpak
>> > On Fri, 05 Feb 2010, smu johnson wrote:
>> >
>> > Hi,
>> >
>> > > Difference 1) ordsetfocus() if it cannot find a key you are looking
>> for..
>> > > for instance if you run (with a typo) the ordsetfocus("isbnM") (notice
>> the M
>> > > typo) twice, when I really was looking for "isbn"... it will return a
>> blank
>> > > C string "" the 2nd time, because it cannot find "isbnM". Clipper
>> instead
>> > > does not switch it to "", but retains the previously working key.
>> >
>> > Not exactly.
>> > 1. The return value depends order set before you call ordSetFocus()
>> > and it doesn't matter what you specify as parameter. Of course the
>> > result can be different then you expected but in such case it was
>> > caused by wrongly selected tag in previous ordSetFocus() call.
>> >
>> > 2. When you specify wrong (not existing) tag name then the behavior
>> > depends on used RDD. Also in Clipper.
>> > In Clipper DBFNTX and SIX3 RDDs do not change the index but
>> > COMIX based RDDs change it to 0.
>> > In Harbour decided to use the same behavior in all RDDs and
>> > I chose COMIX CL53 DBFCDX like behavior because it allows help
>> > to find and eliminate typos in the code and I left such note
>> > in DBFNTX and DBFNSX:
>> > /*
>> > * In Clipper 5.3 DBFCDX (COMIX) when bad name or order is given
>> > * tag number is set to 0 (natural record order). CL52 RDDs and
>> > * SIX3 drivers do not change order in such case.
>> > * I'd like to keep the same behavior in all native [x]Harbour
>> > * RDDs and I chosen DBFCDX one as default. [druzus]
>> > */
>> >
>> > And this is the one difference.
>> > The empty string returned by ordSetFocus() is result of some other
>> > typos in previously called ordSetFocus() which switch the order to 0.
>> >
>> > My advice. Look for the typos and fix them. Otherwise you will keep
>> > code which make sth like:
>> > ordSetFocus( "wrongname" )
>> > [ do sth ]
>> > and above ordSetFocus() is redundant and can be deleted or it fails
>> > but only sometimes when the order set by some other code is different
>> > then expected.
>> > Changing the default behavior I chose does not resolve the problem
>> > but only hides it. Such code has to be fixed even in Clipper programs.
>> > Probably it will be good to add even more strict behavior here and
>> > generate RT error [tag not found] in such case. It should help to
>> > locate such problems in source code quite fast. I.e. you can use
>> > USRRDD and overload UR_ORDLSTFOCUS method to ca
Re: [Harbour] INDEX ON ... TAG "CaseSensitive" OF "CaseSensitive" [Harbour / Clipper difference]
I agree with your opinion too. I'm a bit anally-retentive when it comes to
just fixing the root bugs in the first place.
I am curious though... what kind of stuff would HB_CLP_STRICT do for me? I
grepped the src tree but couldn't quite get the answer.
Thanks przemek
2010/2/22 Viktor Szakáts
> I think it's not very good to add knobs that
> bend behavior for undefined/undocumented cases.
>
> We will end up with 100 such options, and no
> one will know what they are, and we will create
> incompatibility/unportability between Harbour code.
>
> Maybe turning on HB_CLP_STRICT build-time option
> could be a solution to your problem. But overall
> I think you lose more than you gain.
>
> Better to fix the code.
>
> Brgds,
> Viktor
>
> On 2010 Feb 22, at 21:21, smu johnson wrote:
>
> > Hi,
> >
> > I was curious if a some sort of compability switch / flag could be
> enabled to toggle the ordsetfocus() to behave like Clipper 5.2e (or higher,
> not sure if it is different in 5.3) to not change the focus if it cannot
> find what is in the argument. The way it behaves now is good for fixing
> bugs and stuff, and I'm happy with it... but my senior has asked me to ask
> you in case it can be done, as he will probably do that to start off with so
> we don't get RTE errors, even if it is sloppy.
> >
> > Any thoughts?
> >
> >
> > 2010/2/5 smu johnson
> > Thanks Przemek, this is also what my senior thought.
> >
> >
> > 2010/2/5 Przemysław Czerpak
> > On Fri, 05 Feb 2010, smu johnson wrote:
> >
> > Hi,
> >
> > > Difference 1) ordsetfocus() if it cannot find a key you are looking
> for..
> > > for instance if you run (with a typo) the ordsetfocus("isbnM") (notice
> the M
> > > typo) twice, when I really was looking for "isbn"... it will return a
> blank
> > > C string "" the 2nd time, because it cannot find "isbnM". Clipper
> instead
> > > does not switch it to "", but retains the previously working key.
> >
> > Not exactly.
> > 1. The return value depends order set before you call ordSetFocus()
> > and it doesn't matter what you specify as parameter. Of course the
> > result can be different then you expected but in such case it was
> > caused by wrongly selected tag in previous ordSetFocus() call.
> >
> > 2. When you specify wrong (not existing) tag name then the behavior
> > depends on used RDD. Also in Clipper.
> > In Clipper DBFNTX and SIX3 RDDs do not change the index but
> > COMIX based RDDs change it to 0.
> > In Harbour decided to use the same behavior in all RDDs and
> > I chose COMIX CL53 DBFCDX like behavior because it allows help
> > to find and eliminate typos in the code and I left such note
> > in DBFNTX and DBFNSX:
> > /*
> > * In Clipper 5.3 DBFCDX (COMIX) when bad name or order is given
> > * tag number is set to 0 (natural record order). CL52 RDDs and
> > * SIX3 drivers do not change order in such case.
> > * I'd like to keep the same behavior in all native [x]Harbour
> > * RDDs and I chosen DBFCDX one as default. [druzus]
> > */
> >
> > And this is the one difference.
> > The empty string returned by ordSetFocus() is result of some other
> > typos in previously called ordSetFocus() which switch the order to 0.
> >
> > My advice. Look for the typos and fix them. Otherwise you will keep
> > code which make sth like:
> > ordSetFocus( "wrongname" )
> > [ do sth ]
> > and above ordSetFocus() is redundant and can be deleted or it fails
> > but only sometimes when the order set by some other code is different
> > then expected.
> > Changing the default behavior I chose does not resolve the problem
> > but only hides it. Such code has to be fixed even in Clipper programs.
> > Probably it will be good to add even more strict behavior here and
> > generate RT error [tag not found] in such case. It should help to
> > locate such problems in source code quite fast. I.e. you can use
> > USRRDD and overload UR_ORDLSTFOCUS method to catch all such situations
> > and report RTE. Then you should be able to find quite fast all typos by
> > simple runtime code testes. You can even report such problems saving
> > the information to file and emulating original SIX3 behavior.
> >
> > > Difference 2) sx_indexname returned CAPS all the time in Clipper.
> Also,
> > > with a few more differences. This is the workaround my senior has
> created
> >
[Harbour] PICTURE() incompat
Hi, We have discovered the following incompatibility: x:="Y" @ 3,0 get x picture "Y" read The Picture command is used to format the screen display as well as put control on what the field will accept. In the case of picture "Y", it forces the user to enter either Y (Yes) or N (No). However x will always be returned in uppercase in Clipper but Harbour returns the case that the user entered into the field I have tons of places where I check the value of the field to be either Y or N and did not have to test for y or n because it was impossible to assign a lowercase value. We have 120 occurrences of picture "Y" and I will have to change them all to picture "@!Y" Should I go ahead with the changes, or is this is a valid incompatibility report? Thank you -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14004] trunk/harbour
thanks viktor! On Fri, Feb 26, 2010 at 2:19 PM, wrote: > Revision: 14004 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14004&view=rev > Author: vszakats > Date: 2010-02-26 22:19:52 + (Fri, 26 Feb 2010) > > Log Message: > --- > 2010-02-26 23:18 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * src/rtl/tget.prg > * tests/rto_get.prg >! Fixed to convert input to uppercase for "Y" picture mask. >+ Added regression test for this case. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/src/rtl/tget.prg >trunk/harbour/tests/rto_get.prg > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] For Przemek: SIXCDX difference found with examples
Hi again, With a Roll-your-own index open, when you use a dbgoto(), the record pointer is moved to the correct row in the table but the pointer in the index file is not positioned to the corresponding row, even though the record is in the index. With a regular cdx index, the index pointer is always positioned after a dbgoto(). Perhaps the reason for not positioning the index pointer in an ryo index is that an ryo index can contain multiple entries for a single table row, and as such, positioning the index pointer would be ambiguous action (pick one?) and could therefore cause unpredictable results. Am I correct in that thinking? In any event, the Harbour behaviour is different from the SIX SDX, which is causing me problems. I have included a URL for a tiny .ZIP file for a simple source code example, and 2 .txt files showing different behaviour on Clipper 5.2e / Harbour. Please read here: http://209.97.219.2/sjohnson/misc/sixcdx-incompat.zip PS: The source file has the code for Harbour to select SIX type drivers, and wasn't present when compiling the cl52e version, for obvious reasons. Thanks !!! -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
I also am getting this. ..\latest\.hbmk\win\mingw\1BMMENU.o:1BMMENU.c:(.data+0x818): undefined reference to `HB_FUN_CURDRIVE' ..\latest\.hbmk\win\mingw\CHECKSYS.o:CHECKSYS.c:(.data+0x7c8): undefined reference to `HB_FUN_CURDRIVE' ..\latest\.hbmk\win\mingw\SUPPLIER.o:SUPPLIER.c:(.data+0xf88): undefined reference to `HB_FUN_CURDRIVE' *sad face* On Sat, Feb 20, 2010 at 7:07 AM, Massimo Belgrano wrote: > same in win > WIN-MAKE[2]: [install] Error 1 (ignored) > ../../../../../bin/win/mingw/harbour.exe ../../../hbrun.prg > -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l > gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer > -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbrun.o -c > hbrun.c > gcc -L../../../../../lib/win/mingw -o > ..\..\..\..\..\bin\win\mingw\hbrun.exe hbrun.o -lhbcplr -lhbpp > -lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage > -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbrdd -lrddntx > -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbuddall > -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib > -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd >1 file copiati. > ../../../../../bin/win/mingw/harbour.exe ../../../hbmk2.prg > -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l > gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer > -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbmk2.o -c > hbmk2.c > gcc -L../../../../../lib/win/mingw -o > ..\..\..\..\..\bin\win\mingw\hbmk2.exe hbmk2.o -lhbcplr -lhbpp > -lhbcommon -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage > -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbnulrdd -lhbrtl > -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib > -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd > hbmk2.o:hbmk2.c:(.data+0xb38): undefined reference to `HB_FUN_CURDRIVE' > collect2: ld returned 1 exit status > WIN-MAKE[3]: *** [hbmk2.exe] Error 1 > WIN-MAKE[2]: *** [descend] Error 2 > WIN-MAKE[1]: *** [hbmk2.inst] Error 2 > WIN-MAKE: *** [utils.inst] Error 2 > > > > 2010/2/20 : > > Hi! > > > > I can't build harbour > > $Id: ChangeLog 13933 2010-02-20 12:03:26Z vszakats $ > > > > ../../../../../bin/win/bcc/harbour.exe ../../../hbmk2.prg > > -i./../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l > > bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -w-sig- -Q -d > -6 > > -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF > > -I"c:\dev\borland\bcc55\bin\..\Include" -ohbmk2.obj -c hbmk2.c > > hbmk2.c: > > ilink32.exe -L"c:\dev\borland\bcc55\bin\..\Lib" > > -L"c:\dev\borland\bcc55\bin\..\Lib\PSDK" -L"..\..\..\..\..\lib\win\bcc" > -Gn > > -Tpe c0x32.obj hbmk2.obj, "..\..\..\..\..\bin\win\bcc\hbmk2.exe", nul, > > hbcplr hbpp hbcommon hbextern hbdebug hbvmmt hbrtl hblang hbcpage gtcgi > > gtpca gtstd gtwvt gtgui gtwin hbnulrdd hbrtl hbvmmt hbmacro hbcplr hbpp > > hbcommon hbpcre hbzlib kernel32 user32 ws2_32 advapi32 gdi32 cw32mt > import32 > > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland > > Error: Unresolved external '_HB_FUN_CURDRIVE' referenced from > > C:\DEV\HARBOUR_SVN\UTILS\HBMK2\OBJ\WIN\BCC\HBMK2.OBJ > > > > Regards, > > Alexey Myronenko > > > > ___ > > Harbour mailing list (attachment size limit: 40KB) > > Harbour@harbour-project.org > > http://lists.harbour-project.org/mailman/listinfo/harbour > > > > > > > > -- > Massimo Belgrano > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
I should also note that I got Harbour dev to compile in windows, just that I can't get it to compile my .PRGs On Fri, Feb 26, 2010 at 4:47 PM, smu johnson wrote: > I also am getting this. > > ..\latest\.hbmk\win\mingw\1BMMENU.o:1BMMENU.c:(.data+0x818): undefined > reference to `HB_FUN_CURDRIVE' > ..\latest\.hbmk\win\mingw\CHECKSYS.o:CHECKSYS.c:(.data+0x7c8): undefined > reference to `HB_FUN_CURDRIVE' > ..\latest\.hbmk\win\mingw\SUPPLIER.o:SUPPLIER.c:(.data+0xf88): undefined > reference to `HB_FUN_CURDRIVE' > > *sad face* > > > > On Sat, Feb 20, 2010 at 7:07 AM, Massimo Belgrano wrote: > >> same in win >> WIN-MAKE[2]: [install] Error 1 (ignored) >> ../../../../../bin/win/mingw/harbour.exe ../../../hbrun.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer >> -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbrun.o -c >> hbrun.c >> gcc -L../../../../../lib/win/mingw -o >> ..\..\..\..\..\bin\win\mingw\hbrun.exe hbrun.o -lhbcplr -lhbpp >> -lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage >> -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbrdd -lrddntx >> -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbuddall >> -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib >> -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd >>1 file copiati. >> ../../../../../bin/win/mingw/harbour.exe ../../../hbmk2.prg >> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer >> -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbmk2.o -c >> hbmk2.c >> gcc -L../../../../../lib/win/mingw -o >> ..\..\..\..\..\bin\win\mingw\hbmk2.exe hbmk2.o -lhbcplr -lhbpp >> -lhbcommon -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage >> -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbnulrdd -lhbrtl >> -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib >> -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd >> hbmk2.o:hbmk2.c:(.data+0xb38): undefined reference to `HB_FUN_CURDRIVE' >> collect2: ld returned 1 exit status >> WIN-MAKE[3]: *** [hbmk2.exe] Error 1 >> WIN-MAKE[2]: *** [descend] Error 2 >> WIN-MAKE[1]: *** [hbmk2.inst] Error 2 >> WIN-MAKE: *** [utils.inst] Error 2 >> >> >> >> 2010/2/20 : >> > Hi! >> > >> > I can't build harbour >> > $Id: ChangeLog 13933 2010-02-20 12:03:26Z vszakats $ >> > >> > ../../../../../bin/win/bcc/harbour.exe ../../../hbmk2.prg >> > -i./../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >> > bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -w-sig- -Q -d >> -6 >> > -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF >> > -I"c:\dev\borland\bcc55\bin\..\Include" -ohbmk2.obj -c hbmk2.c >> > hbmk2.c: >> > ilink32.exe -L"c:\dev\borland\bcc55\bin\..\Lib" >> > -L"c:\dev\borland\bcc55\bin\..\Lib\PSDK" -L"..\..\..\..\..\lib\win\bcc" >> -Gn >> > -Tpe c0x32.obj hbmk2.obj, "..\..\..\..\..\bin\win\bcc\hbmk2.exe", nul, >> > hbcplr hbpp hbcommon hbextern hbdebug hbvmmt hbrtl hblang hbcpage gtcgi >> > gtpca gtstd gtwvt gtgui gtwin hbnulrdd hbrtl hbvmmt hbmacro hbcplr hbpp >> > hbcommon hbpcre hbzlib kernel32 user32 ws2_32 advapi32 gdi32 cw32mt >> import32 >> > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >> > Error: Unresolved external '_HB_FUN_CURDRIVE' referenced from >> > C:\DEV\HARBOUR_SVN\UTILS\HBMK2\OBJ\WIN\BCC\HBMK2.OBJ >> > >> > Regards, >> > Alexey Myronenko >> > >> > ___ >> > Harbour mailing list (attachment size limit: 40KB) >> > Harbour@harbour-project.org >> > http://lists.harbour-project.org/mailman/listinfo/harbour >> > >> > >> >> >> >> -- >> Massimo Belgrano >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> > > > > -- > smu johnson > > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error: Unresolved external '_HB_FUN_CURDRIVE'
I just changed it to HB_CURDRIVE a few mins before you wrote that.. but you beat me to it! :) On Fri, Feb 26, 2010 at 4:56 PM, Viktor Szakáts wrote: > Either add hbxpp to you liblist or change the call to HB_CURDRIVE(). > > See ChangeLog for more. > > Brgds, > Viktor > > > On Sat, Feb 27, 2010 at 1:50 AM, smu johnson wrote: > >> I should also note that I got Harbour dev to compile in windows, just that >> I can't get it to compile my .PRGs >> >> >> On Fri, Feb 26, 2010 at 4:47 PM, smu johnson wrote: >> >>> I also am getting this. >>> >>> ..\latest\.hbmk\win\mingw\1BMMENU.o:1BMMENU.c:(.data+0x818): undefined >>> reference to `HB_FUN_CURDRIVE' >>> ..\latest\.hbmk\win\mingw\CHECKSYS.o:CHECKSYS.c:(.data+0x7c8): undefined >>> reference to `HB_FUN_CURDRIVE' >>> ..\latest\.hbmk\win\mingw\SUPPLIER.o:SUPPLIER.c:(.data+0xf88): undefined >>> reference to `HB_FUN_CURDRIVE' >>> >>> *sad face* >>> >>> >>> >>> On Sat, Feb 20, 2010 at 7:07 AM, Massimo Belgrano >>> wrote: >>> >>>> same in win >>>> WIN-MAKE[2]: [install] Error 1 (ignored) >>>> ../../../../../bin/win/mingw/harbour.exe ../../../hbrun.prg >>>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >>>> gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer >>>> -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbrun.o -c >>>> hbrun.c >>>> gcc -L../../../../../lib/win/mingw -o >>>> ..\..\..\..\..\bin\win\mingw\hbrun.exe hbrun.o -lhbcplr -lhbpp >>>> -lhbcommon -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage >>>> -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbrdd -lrddntx >>>> -lrddnsx -lrddcdx -lrddfpt -lhbsix -lhbhsx -lhbusrrdd -lhbuddall >>>> -lhbrtl -lhbvm -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib >>>> -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd >>>>1 file copiati. >>>> ../../../../../bin/win/mingw/harbour.exe ../../../hbmk2.prg >>>> -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >>>> gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer >>>> -march=i586 -mtune=pentiumpro -DHB_LEGACY_TYPES_OFF -ohbmk2.o -c >>>> hbmk2.c >>>> gcc -L../../../../../lib/win/mingw -o >>>> ..\..\..\..\..\bin\win\mingw\hbmk2.exe hbmk2.o -lhbcplr -lhbpp >>>> -lhbcommon -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage >>>> -lgtcgi -lgtpca -lgtstd -lgtwvt -lgtgui -lgtwin -lhbnulrdd -lhbrtl >>>> -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lhbzlib >>>> -lkernel32 -luser32 -lws2_32 -ladvapi32 -lgdi32 -lhbmainstd >>>> hbmk2.o:hbmk2.c:(.data+0xb38): undefined reference to `HB_FUN_CURDRIVE' >>>> collect2: ld returned 1 exit status >>>> WIN-MAKE[3]: *** [hbmk2.exe] Error 1 >>>> WIN-MAKE[2]: *** [descend] Error 2 >>>> WIN-MAKE[1]: *** [hbmk2.inst] Error 2 >>>> WIN-MAKE: *** [utils.inst] Error 2 >>>> >>>> >>>> >>>> 2010/2/20 : >>>> > Hi! >>>> > >>>> > I can't build harbour >>>> > $Id: ChangeLog 13933 2010-02-20 12:03:26Z vszakats $ >>>> > >>>> > ../../../../../bin/win/bcc/harbour.exe ../../../hbmk2.prg >>>> > -i./../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l >>>> > bcc32.exe -I. -I../../../../../include -q -tWM -CP437 -w -w-sig- -Q >>>> -d -6 >>>> > -O2 -OS -Ov -Oi -Oc -DHB_LEGACY_TYPES_OFF >>>> > -I"c:\dev\borland\bcc55\bin\..\Include" -ohbmk2.obj -c hbmk2.c >>>> > hbmk2.c: >>>> > ilink32.exe -L"c:\dev\borland\bcc55\bin\..\Lib" >>>> > -L"c:\dev\borland\bcc55\bin\..\Lib\PSDK" >>>> -L"..\..\..\..\..\lib\win\bcc" -Gn >>>> > -Tpe c0x32.obj hbmk2.obj, "..\..\..\..\..\bin\win\bcc\hbmk2.exe", >>>> nul, >>>> > hbcplr hbpp hbcommon hbextern hbdebug hbvmmt hbrtl hblang hbcpage >>>> gtcgi >>>> > gtpca gtstd gtwvt gtgui gtwin hbnulrdd hbrtl hbvmmt hbmacro hbcplr >>>> hbpp >>>> > hbcommon hbpcre hbzlib kernel32 user32 ws2_32 advapi32 gdi32 cw32mt >>>> import32 >>>> > Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland >>>> > Error: Unresolved external '_HB_FUN_CURDRIVE' referenced from >
[Harbour] Can HB_RUN fork?
Hi, Can HB_RUN be made to fork a process? For instance, if you tried to run the crappy Windows notepad.exe, it wouldn't wait for notepad.exe to terminate before you got your prompt back. On some text editors, this isn't a concern, like WRITE / WORDPAD.exe... but in notepad it is, and I am very curious if something can be done. Thank you -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Trap / run routine when MS Windows red X box closed?
Hi, This may not come as a surprise to anyone, but often, people just can't stop quitting applications by clicking the X on the righthand side of a MS windows application. Sometimes in some more serious console apps, there is a separate Exit function that handles its own cleanup code, quitting protocols, etc etc. that needs to be run, and is usually like the (alt/ctrl) X or E key on the mainmenu of that program. I was wondering that since it's impossible for everyone to not keep clicking it, that some sort of Harbour function or flag or whatever could somehow control what happens if it's clicked via some sort of API call that Windows might provide to Harbour. Like, if someone clicked the X box it might call a func that exits cleanly instead of instantly. Any tips welcome. thanks! -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] For Przemek: SIXCDX difference found with examples
Przemek, As always... many thanks, 'O Six driver database guru. I will keep an eye out for a druzus commit. Keep up the great work! 2010/2/28 Przemysław Czerpak > On Fri, 26 Feb 2010, smu johnson wrote: > > Hi, > > > With a Roll-your-own index open, when you use a dbgoto(), the record > pointer > > is moved to the correct row in the table but the pointer in the index > file > > is not positioned to the corresponding row, even though the record is in > the > > index. With a regular cdx index, the index pointer is always positioned > > after a dbgoto(). > > No. It's positioned in the same way in both cases using sth like: > SEEK EVAL( ) + > It means that it will not work when you used in RYO index your own > values which are not results of evaluation because corresponding > entry cannot be found. > > > Perhaps the reason for not positioning the index pointer in an ryo index > is > > that an ryo index can contain multiple entries for a single table row, > and > > as such, positioning the index pointer would be ambiguous action (pick > one?) > > and could therefore cause unpredictable results. Am I correct in that > > thinking? > > No, see above. After DBGOTO() RDD uses seek to find corresponding record > to eliminate linear scan of all key stored in index from the index top > position to locate the entry which has corresponding record number. > Such linear scan is simply very expensive in big tables because it may > force reading whole index file to locate given entry. > > > In any event, the Harbour behaviour is different from the SIX SDX, which > is > > causing me problems. > > > > I have included a URL for a tiny .ZIP file for a simple source code > example, > > and 2 .txt files showing different behaviour on Clipper 5.2e / Harbour. > > Please read here: http://209.97.219.2/sjohnson/misc/sixcdx-incompat.zip > > Looks that SIX3 for template indexes enables such linear scan > automatically. > Harbour doesn't. You can force linear scan for index repositioning manually > by: > > sx_findRec( recNo() ) > > just after dbGoTo(). > I'll enable automatic linear repositioning for template SIXCDX tags ASAP. > > best regards, > Przemek > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Trap / run routine when MS Windows red X box closed?
What is a GT? Forgive the stupid question... :( On Sun, Feb 28, 2010 at 5:27 PM, Pritpal Bedi wrote: > > > smu johnson wrote: > > > > I was wondering that since it's impossible for everyone to not keep > > clicking > > it, that some sort of Harbour function or flag or whatever could somehow > > control what happens if it's clicked via some sort of API call that > > Windows > > might provide to Harbour. Like, if someone clicked the X box it might > > call > > a func that exits cleanly instead of instantly. > > > > It is there. > > First which GT are you using ? > GTWVT and GTWVG provide this functionality. > > > - > enjoy hbIDEing... >Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/Trap-run-routine-when-MS-Windows-red-X-box-closed-tp4651773p4651882.html > Sent from the harbour-devel mailing list archive at Nabble.com. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] bug/issue: slow pasting on uppercase letters
Hi, On regular CLI input boxes where you can type stuff, we have found copying and pasting in Windows to be very slow. When I looked more into it, using something like MEMOEDIT() to test pasting a bunch of chars, I found the UPPERCASE chars paste very slowly, and lowercase chars paste instantly. It didn't take much to test this out for myself, but if no one else can see what I'm talking about, I will record a small youtube video of it maybe. My paste test string: FESFJSEFKJESFKJSFNEjqelmkdewlkESFJSEFKJESFKJSFNEESFJSEFKJESFKJSFNE Thanks -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Way for a harbour .exe to delete itself?
Hi, Is there a way (or smarter way) to basically "upgrade" the .exe you are running without quitting it... Such as if the harbour-made .exe (test.exe, for example) was running, could delete itself, call winrar to extract a new test.exe, and then so a unix-like exec() call to reload itself? Any hints greatly appreciated. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Trap / run routine when MS Windows red X box closed?
Hi, On Sun, Feb 28, 2010 at 6:12 PM, Pritpal Bedi wrote: > > Show on this list how you build your appln ? > > ..\harbour-dev\bin\hbmk2 -strip -ustd.ch -kc -lhbct -lhbtpathy -lhbnf -inc -o..\latest\bmd.exe bm.hbp (bm.hbp simply contains a giant list of all the .PRG files) Is this enough info for you? Thanks for taking an interest. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Trap / run routine when MS Windows red X box closed?
Well... what can I do to make it supported? Will I have to change my entire code if I switch away from GTWIN? I am not quite sure how to use those other features you mentioned earlier :( Please give me a hint. :) Thank you! On Mon, Mar 1, 2010 at 6:17 PM, Pritpal Bedi wrote: > > > smu johnson wrote: > > > > ..\harbour-dev\bin\hbmk2 -strip -ustd.ch -kc -lhbct -lhbtpathy -lhbnf > -inc > > -o..\latest\bmd.exe bm.hbp > > > > (bm.hbp simply contains a giant list of all the .PRG files) > > > > Is this enough info for you? Thanks for taking an interest. > > > > Oh yes, so you are using GTWIN. > No, for this GT "Close -> X" button cannot be manipulated. > > > > - > enjoy hbIDEing... >Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/Trap-run-routine-when-MS-Windows-red-X-box-closed-tp4651773p4658528.html > Sent from the harbour-devel mailing list archive at Nabble.com. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Trap / run routine when MS Windows red X box closed?
Hi, Thanks for the tips. I tried both these options, and they seem to start up a new console window whenever I run stuff. I imagine this is the price I have to pay, in order to trap the red X button being pressed... *worried face* On Mon, Mar 1, 2010 at 7:23 PM, Pritpal Bedi wrote: > > > Przemysław Czerpak wrote: > > > > It's redundant. -gtwvt makes the above. > > If you use -gt* switches in hbmk2 then it makes for the 1-st one: > >REQUEST HB_GT_*_DEFAULT > > and for the next ones: > >REQUEST HB_GT_* > > > > so you do not have to use any 'REQUEST HB_GT_*[_DEFAULT] in your > > PRG code. > > > > Long time elapsed I played with this stuff, so was out of memory. > So only -gtwvt switch is required, more simplified. > > > - > enjoy hbIDEing... >Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/Trap-run-routine-when-MS-Windows-red-X-box-closed-tp4651773p4658761.html > Sent from the harbour-devel mailing list archive at Nabble.com. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Trap / run routine when MS Windows red X box closed?
May joy and happiness forever come your way! On Tue, Mar 2, 2010 at 1:40 AM, Saulius Zrelskis wrote: > > Oh yes, so you are using GTWIN. > > No, for this GT "Close -> X" button cannot be manipulated. > > It can, through API SetConsoleCtrlHandler(). Handles events: > CTRL_C_EVENT > CTRL_BREAK_EVENT > CTRL_CLOSE_EVENT <<<=== > CTRL_LOGOFF_EVENT > CTRL_SHUTDOWN_EVENT > > Best regards, > Saulius > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Microsoft's SMB2 in Vista and above crippling your network apps?
Hi, We have struggled with a problem for years with Clipper, and it happens in Harbour too. But that is not to say that either of these are to blame. The problem is that when a huge amount of DBF (using six driver, fwiw) type file creation and modification, etc etc, happens over a shared network drive in Windows, and the hosting drive is on a Vista or higher OS, we have problems with inaccurate data because the network protocol is not strict enough when it comes to two people changing the same file, etc etc. This is never a problem when hosting from Win2k, and XP I believe also is okay. So, as a last resort, I was wondering if any of you guys have dealt with this, and know of a solution. Currently, we found one way to deal with it, but it's not 100% perfect as it only supports certain builds of Vista, and not Windows 7, and would probably take forever to support all these OS's. It involves changing some registry settings to disable smb2 ( http://en.wikipedia.org/wiki/Server_Message_Block ). Maybe it's my lucky day, and some of you guys have had this problem and found a permenant solution to deal with it. I ask here, as I imagine maybe someone else doing network .dbf work might have run into this at some point in their lives. Thank you for reading. -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Microsoft's SMB2 in Vista and above crippling your network apps?
Well we have a ton of people who still use Windows, and because of that we need a Windows solution. I am happy to report that after about 30 mins of Googling, I came across this page, which solved the problem, if you disable SMB2. http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx It's amazing, as we have spent countless hours Googling for this months ago, and relied on .bat files that worked 80% of the time. So far, this works 100% of the time. This is a miracle for us!!! We've worried for 6 years about this problem. On Tue, Mar 2, 2010 at 6:24 PM, Angel Pais wrote: > The solution to your problems is NETIO. > It also allows you to host your dbfs in a linux box. > It is also more secure because users don`t have direct access to your data. > > HTH > Angel > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] New Windows unicode support "for dummies" thread
Hi, I thought I'd start this out as I don't really understand a lot of the Changelog stuff in layman's terms. Fact: Win9x OS's will need a unicows.dll file to work in future .exe compiles generated by Harbour. Question: Does that mean if I just download and include 1 single file, unicows.dll in the path where the generated .exe's are put and executed from, everything will magically work for Win9x => Windows 7 64-bit type OS's? -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] New Windows unicode support "for dummies" thread
I know I asked this before, but just to make double-dog-sure I got this right... Is this unicode stuff only concerning compiling Harbour on Windows, or creating .EXEs from Clipper code with Harbour on Windows. I believe the answer is "both" but I get messed up from time to time. Thanks Viktor On Wed, Mar 3, 2010 at 12:51 AM, Viktor Szakáts wrote: > > I thought I'd start this out as I don't really understand a lot of the > Changelog stuff in layman's terms. > > > > Fact: Win9x OS's will need a unicows.dll file to work in future .exe > compiles generated by Harbour. > > Not exactly. > > The _default_ Harbour build will need unicows.dll. > Anyone, anytime may create a non-UNICODE Harbour build > by using HB_BUILD_UNICODE=no. > > > Question: Does that mean if I just download and include 1 single file, > unicows.dll in the path where the generated .exe's are put and executed > from, everything will magically work for Win9x => Windows 7 64-bit type > OS's? > > Unfortunately no. I've written detailed description > on the method a few days ago on this list. But of > course there are several general descriptions about > it on MS website and other places. > > It doesn't currently work reliably with Harbour though. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Microsoft's SMB2 in Vista and above crippling your network apps?
Hi, Thanks for replying. The reason this guy wrote a blog about SMB2 to the link I pasted was because this web blogger read about an old security flaw in SMB2 but it wasn't the reason why I needed to disable it. Ever since Vista came out, this has been a HUGE headache for us. We have written code to even test this problem over the network. It worked fine in win2k, and XP, but as soon as Vista and Windows 7 came, their SMB 2.0 and 2.1 network things have been a constant nightmare for us. Disabling SMB2 finally solved the problem once and for all for us. Before, we had .bat files changing registry settings which only worked on certain builds of Vista. It has been a huge headache for us ever since Vista cam eout. As far as are networking situation, we have one machine hosting a shared folder in Windows, (in our case, \\TBM-SERVER\apps in Windows terms), and about 18 stations have that shared folder mapped in Windows. This seems pretty straight forward... but having read Przemek's reply, I would be very curious to try out these new solutions. Only problem is, I am afraid to ask for help, and I have no idea if they apply to our case as described above. It would be nice to avoid this smb2 stuff completely, ie, not using the .msi I found, and do it as Przemek and Angel pointed out. I read: > then you should switch to HBNETIO. If you want much stronger > data protection and move all index processing to server side then you should > use dedicated RDBMS like LETO or ADS. For me to just "get this working" would probably involve me grepping the Harbour source for about 1-2 hours. If there is something obvious I'm missing, I'm very willing to hear it. Thanks for posting! 2010/3/3 Przemysław Czerpak > On Tue, 02 Mar 2010, smu johnson wrote: > > Well we have a ton of people who still use Windows, and because of that > we > > need a Windows solution. > > HBNETIO is platform independent solution. It can be used by stations using > only one platform (i.e. only MS-Windows programs) but it also allow to > safely share DBF tables (with memo and indexes) between program compiled > on different platforms i.e. Linux, FreeBSD, SunOS, MacOSX, DOS, W95, WinXP, > W2K, Win7, OS2 stations using native programs accessing the same files. > It system eliminates file sharing with its all potential synchronization > problems by switching to own TCP/IP protocol dedicate to share Harbour > tables. > > > I am happy to report that after about 30 mins of Googling, I came across > > this page, which solved the problem, if you disable SMB2. > > > http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx > > Above fix is for remote hackers attack so it's not related to your problem. > Anyhow as I can see there is a switch to disable SMBv2 protocol and this > may indirectly help to resolve the problem because it's possible that it > can be exploited only when SMBv2 is enabled and some buggy network clients > are used. > Anyhow if you do not want to worry about possible problems which can be > caused by some incompatible network transport layer or unsafe concurrent > file access caused by some speed "optimization (i.e. not synchronized read > ahead caches) then you should switch to HBNETIO. If you want much stronger > data protection and move all index processing to server side then you > should > use dedicated RDBMS like LETO or ADS. If you want to full even logical > protection then you should move your whole application to server side and > leave only user interface on the client side. It's the fastest and the most > safe solution. > > best regards, > Przemek > _______ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- smu johnson ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
