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>
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
