Oops.. i mean Viktor 2010/2/22 smu johnson <smujohn...@gmail.com>
> 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 <harbour...@syenar.hu> > > 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 <smujohn...@gmail.com> >> > Thanks Przemek, this is also what my senior thought. >> > >> > >> > 2010/2/5 Przemysław Czerpak <dru...@acn.waw.pl> >> > 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 sensitive FS which in practice exists only >> > in DOS, MS-Windows and OS2 and even in this OS-es it's possible to >> > access some other file systems using case sensitive file names and >> > your programs will not work. >> > >> > BTW Harbour has HB_FNAMESPLIT() function and Sx_FNameParser() >> > which seem to be better to implement lNoPath parameter because >> > they will strip drive letter and also respect '/' as directory >> > separator: i.e. >> > >> > func bm_indexName( x, lNoPath ) >> > return upper( sx_FNameParser( sx_indexName( x ), ; >> > valType( lNoPath ) != "L" .or. !lNoPath, .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 <smujohn...@gmail.com> >> > >> > >> > >> > >> > -- >> > smu johnson <smujohn...@gmail.com> >> > >> > _______________________________________________ >> > 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 <smujohn...@gmail.com> > > -- smu johnson <smujohn...@gmail.com>
_______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour