xBrowse, bSeek y lAutoOrder

[Biel EA6DD]

Hola foro,
esta manañana estaba intentando reutilizar una porción de código que funcionaba originalmente con FWH 12.11, y al incorporarla al nuevo proyecto desarrollado con FWH 13.05, ha dejado de funcionar.
Inicialmente, pense que era algún problema con el código, y despues de revisarlo detenidamente y no encontrar nada, me decidi a rastrear la calse xBrowse, y allí encontre el problema.
El problema es que en mi funciíon hago uso de una busqueda incremental personalizada, que asigo al DATA bSeek, pero este DATA se sobreescribe siempre en el metodo SetRdd, que se llama siempre desde el metodo initiate. Antes habia un if, que hoy aparece comentado, en la linea 3979.

Code: Select all  Expand view

//   if lAutoOrder

      (::cAlias)->( OrderTagInfo( aStruct, 8 ) )

      for nFor := 1 to Len( ::aCols )
         if ( n := AScan( aStruct, { |a| a[ 1 ] == Upper( ::aCols[ nFor ]:cHeader ) } ) ) > 0
            ::aCols[ nFor ]:cSortOrder    := aStruct[ n ][ 8 ]
            ::aCols[ nFor ]:cOrdBag       := ( cAlias )->( OrdBagName( ::aCols[ nFor ]:cSortOrder ) )
         endif
      next nFor

      ::bSeek  := { |c,u| ( ::cAlias )->( ::RddIncrSeek( c, @u ) ) }

//   endif

 

Si lAutorder era falso, bSeek no era modificado. Mi pregunta es, ese cambio, supongo que será para arreglar/mejorar algo, quisiera conocer que. Y en la medida de lo posible para compatibilizar mi software, me gustaria que volviera el IF lAutoOrder, o en us defecto que no se modificase bSeek, si ya está asignado.

Code: Select all  Expand view

DEFAULT ::bSeek  := { |c,u| ( ::cAlias )->( ::RddIncrSeek( c, @u ) ) }

[nageswaragunupudi]

It is highly desirable to first call

oBrw:cAlias := <youralias>
oBrw:SetRdd( .... )

before assigning any of your data and codeblocks.

If you do not explicitly call SetRdd( .. ) initially in the program, XBrowse at the time of initializing by default calls SetRdd(), but this is not recommended.

As you suggested, we are now creating ::bSeek in SetRDD method as DEFAULT (from version 13.06) to take care of above situations.

Still our advice is to use command syntax to create xbrowse to avail the full power of xbrowse.

[Biel EA6DD]

Hi, many thanks for your answer.
Thanks for your recommendation to use SetRDD before assigning DATA or codeblocks, that solves the problem due after executing SetRDD I can change the codeblocks, and Initiate will not run again SetRdd.

After reviewing the xBrowse class, another alternative is to define the DATA :nDataType :=DATATYPE_RDD.

I know the command syntax is easy, fast and powerful. But I feel confortable woorking at object level, gives me more control of what I do and how I want to do it.

[nageswaragunupudi]

Thanks for your recommendation to use SetRDD before assigning DATA or codeblocks, that solves the problem due after executing SetRDD I can change the codeblocks, and Initiate will not run again SetRdd.

That is how XBrowse is intended to be used. Any further developments assume xbrowse is used the way it is intended to be used.

XBrowse has some fault tolerant coding. Instead of failing the programmer, it tries to accommodate programmer's deviations from the intended usage by providing intelligent defaults.

Calling SetRdd() by default during Initialization is provided as one of such features in case the programmer forgot the explicitly call this method initially.
But it is not desirable for th programmer to rely on such defaults because it is always safe to be explicit and not to rely on defaults.

After reviewing the xBrowse class, another alternative is to define the DATA :nDataType :=DATATYPE_RDD.

This may work. But still I advise you to go the recommended way.

I know the command syntax is easy, fast and powerful. But I feel comfortable working at object level, gives me more control of what I do and how I want to do it.

You have the choice of style of programming. Still it is my duty to recommend using command syntax for creation of xbrowse and if not you may be missing out the full power of xbrowse. Final choice is yours.