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
