On Tue, 01 Dec 2009, Brian Hays wrote:
Hi,
> I need help with a decision on whether to throw an error or not. Please see
> discussion below.
>
> 2009-12-01 01:37 UTC-0800 Brian Hays <bhays/at/abacuslaw.com>
> * contrib\rdd_ads\ads1.c
> + Added support for ordDescend's 3rd arg to dynamically change
> the index direction between ascending / descending.
> ONLY supported in ADS 9 and later.
> BEFORE, if you used ordDescend(,,.t.) (or any value in the 3rd arg),
> it was silently ignored no matter what version of ADS you used.
> This change now means that with ADS 9 or later the flag is implemented.
> BUT if you have ADS 8 or earlier, now I throw an error to alert you that
> that
> flag is not supported and your requested action would fail to do anything.
> This may anger people who have been silently failing for years
> (perhaps with code that is shared with other platforms that DO support the
> flag)
> Im not very good at details with our Error throwing details. Heres what I
> coded:
> // Do we have a "Unsupported Option in this version" error?
> hb_errRT_DBCMD( EG_ARG, EDBCMD_DBINFOBADPARAMETER, "Dynamic
> descend not supported in this version", HB_ERR_FUNCNAME );
> SHOULD WE REMOVE THIS, and go back to ignoring it? Or should the error msg
> be standardized?
Dynamic DESCEND flag is not supported also in many Clipper RDDs.
So far the standard way in Clipper and [x]Harbour to check if dynamic
descending order is supported was checking the value returned by:
ordDescend( [<tag>], [<bag>] )
just after:
ordDescend( [<tag>], [<bag>], <lOnOff> )
i.e.:
ordDescend( nTag,, .T. )
? "order:", iif( ordDescend( nTag ), "descending", "ascending" )
such code works for any RDDs and will work also for ADS if you do not
enable such RTE.
In all core native RDDs (NTX, CDX, NSX) I implemented dynamic descend
flags so such RTE cannot be generated so I think that it will be most
important for ADS users which without RTE can easy create the same code
for different ADS versions.
> A second question: AdsSetIndexDirection takes an unusual flag that EITHER
> takes 0 to return
> to the original state, or TRUE to "reverse the direction from the current
> state"
> IOW, they have the ability to go back to normal which IIUC
> Clipper/(x)Harbour does NOT.
To clarify some technical issues.
In indexes like CDX, ADI or NSX there is no "normal" state.
Physically they exist only in ascending order and descending
order is done by logical flag (BTW I'm surprised why adding
user interface to change such logical flag took such long time
ADS authors) so we can talk only about default settings for
this flag stored in index header. Only NTX format uses reverted
key orders in index file to implement default descending sorting
so in our DBFNTX I implemented both versions and it's possible
to use dynamic switching too just like in CDX or NSX formats.
I guess that you are asking about method of "resetting" DESCEND
flag to value chose by RDD when index is open. So far we do not
have such functionality though it can be easy implemented if we
agree how to inform RDD that we want to "reset" this flag.
> Am I missing something? It would be nice to have a value to "return to
> native state" in our syntax
> instead of requiring a close/re-open of the file. Note: Once the direction
> has been
> dynamically changed, ordDescend() is only capable of returning the CURRENT
> state; there is no
> api to get the Original direction setting.
Please remember that we are always in native state. The order direction
is in practice only logical flag. Usually structural code have to safe
and restore descend flag settings because it cannot assume that it was
in the same state as after opening table. Operation like resetting order
DESCEND flag to the same state as after opening table are not structural
so are less usable in most of code. Probably the only one type of code
I can imagine is some DBU like program which may want to display some
information with default order settings.
> In some COMIX functions, there was the difference between an explicit NIL
> and an ignored parameter
> to distinguish between intentions. I never liked having to explain it to
> people, BUT
> this may be an instance where explicitly passing NIL as the third arg could
> be the flag
> to revert to the original state of the index.
NIL can be used for such job. In such case it's necessary to modify
ordDescend() in dbcmd53.c and change:
pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL );
to:
pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_LOGICAL );
if( pOrderInfo.itmNewVal )
pOrderInfo.itmNewVal = hb_param( 3 , HB_IT_NIL );
> Is there a good way to add the extended value/functionality of either
> learning or setting
> the original direction?
The other method is defining new DBOI_* action for dbInfo() to extract
default DESCEND flag settings which can be used as ordDescend() parameter.
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
