GRID vs. BROWSE - which control is faster?

[mrduck]

I know you are talking about HMG3 but there is the exact same problem in HMG4.

In HMG4 this problem is due to the fact that when SET FILTER is filtering and you do a GO 5, you don't go to the 5th filtered record but on the 5th absolute record... this in HMG4... you should do a GO TOP; skip 5 but you understand that it is impossible to do on a "generic" SET FILTER...

It would be interesting to dig the problem...

Something is wrong in moving pointer in grid while incremental searching.
I will put some screens tomorrow. When I use browse, everything works OK - from about two years. When I've changed browse to grid - data presented in table does not much a content of current record of database.

[mol]

I'm using function, which realises incremental searching of data entered in "Wyszukaj" Field.
Any input in "Wyszukaj" field causes DBSeek in table and changes pointer in table.
No filter is set.
When I present data in BROWSE control, everything works ok:


When I present data in GRID control, it's very strange, but table shows different records than searched:


for changing pointer in GRID/BROWSE I use this code:

Code: Select all

               if lGridControlMode
			SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))
		else  
                        //lBrowseControlMode
			SetProperty(cOkno,"B_Towary","Value", towary->(Recno()))
		endif

What's wrong with me or GRID???

[mrduck]

I'm just doing some cleanup on HMG4 GRID/BROWSE code and as I said in the previous message I found some problems. So I'm looking at HMG3 source code to better understand what happens and your problem is an excuse to do so

for changing pointer in GRID/BROWSE I use this code:

Code: Select all

               if lGridControlMode
			SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))
		else  
                        //lBrowseControlMode
			SetProperty(cOkno,"B_Towary","Value", towary->(Recno()))
		endif

What's wrong with me or GRID???

It seems to me that SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno())) ends in h_grid.prg function setdatagridrecno()

Can you please check which branch of the IF is taken ?

The first branch is taken if:
- there is no filter
- SET DELETED is OFF
- there is no FOR in the index (but there other options that should probably checked, like UNIQUE)
then ordkeyno() is used to retrieve the "line" of the row.
otherwise gotop() and loop until the correct recno() is found()

So you should check how the index is built, its parameters.

If still in error, I'd unroll SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))... I mean creating a function that extrapolates the program lines from SetProperty functions and create a MySetDataGridRecno() that "overloads" the standard one, and putting trace info to understand what happens...

[mol]

I'm just doing some cleanup on HMG4 GRID/BROWSE code and as I said in the previous message I found some problems. So I'm looking at HMG3 source code to better understand what happens and your problem is an excuse to do so

for changing pointer in GRID/BROWSE I use this code:

Code: Select all

               if lGridControlMode
			SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))
		else  
                        //lBrowseControlMode
			SetProperty(cOkno,"B_Towary","Value", towary->(Recno()))
		endif

What's wrong with me or GRID???

It seems to me that SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno())) ends in h_grid.prg function setdatagridrecno()

Can you please check which branch of the IF is taken ?

The first branch is taken if:
- there is no filter
- SET DELETED is OFF
- there is no FOR in the index (but there other options that should probably checked, like UNIQUE)
then ordkeyno() is used to retrieve the "line" of the row.
otherwise gotop() and loop until the correct recno() is found()

So you should check how the index is built, its parameters.

If still in error, I'd unroll SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))... I mean creating a function that extrapolates the program lines from SetProperty functions and create a MySetDataGridRecno() that "overloads" the standard one, and putting trace info to understand what happens...

1. No filter
2. Set deleted on
3. Simple index on character field "NAZWA" C 50
4. Any FOR nor UNIQUE were used

I've added some code for debugging this situation:

Code: Select all

		cFoundName := towary->nazwa
		if lSzybkaTabelaTowarow
			SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))
		else
			SetProperty(cOkno,"B_Towary","Value", towary->(Recno()))
		endif
		MsgBox('I found record with NAZWA="' + cFoundName + chr(10) + ;
				"Searching method: "+ cSearchMethod + chr(10) + ;
				"After moving pointer in table, NAZWA is: "+ towary->nazwa)

the result is below:

[mrduck]

so you can compile hmg3... why don't you report the nRecNo and nLogicalPos variables ?

it seems that you are in the ELSE branch (due to set deleted on), can you please check this ?

so, if you have a filter applied on the DB (and set deleted on is a sort of filter), the only way to find the logical (filtered) row of a certain recno() is to loop on the db.... like already done in the code...

I don't see nothing strange in this piece of code... check what is passed to _SetValue and if it behaves correctly..

[mol]

After some changes in program:
1. SET DELETED OFF
2. SET FILTER TO
any filter is active now

Code: Select all

                cFoundName := towary->nazwa
		nFoundRecord := towary->(RecNo())

		SetProperty(cOkno,"B_Towary","RECNO", towary->(Recno()))

		nCurrentName := towary->nazwa
		nCurrentRecord := towary->(RecNo())
		
		MsgBox('I found record #' + alltrim(str(nFoundRecord)) + ' with NAZWA="' + cFoundName + chr(10) + ;
				"Searching method: "+ cSearchMethod + chr(10) + ;
				"After moving pointer in table, recno is #" + alltrim(str(nCurrentRecord))+ ", NAZWA is: "+ nCurrentName)

effect is like below:



and pointer to towary was moved by grid to last viewed record in table, not this highlighted

[mol]

These problems disqualify using of GRID to browse DBF file, in my honest opinion

[mrduck]

These problems disqualify using of GRID to browse DBF file, in my honest opinion

Can it be that grid is 0 based ?

[mol]

I have no time to analyze h_grid.prg source file.
Maybe someone knows it?

[Hazael]

Hello all,

I am trying hmg 3.0.39 and I got a problem that I can't understand and I hope someone with more knowledge will help me.

I tryied a modified version of: C:\hmg.3.0.39\SAMPLES\RDD.SQL\mdb\demo.prg where I want to click on the GRID's header and get the program to sort it for me but somehow it gives only a limited view of all the records...

Could you please try it over there and tell me what I did wrong, please?

Code: Select all

* RDD SQL DEMO
* Based on Harbour Compiler Contrib Samples
* Adapted for HMG by Roberto Lopez - 2009

#include "hmg.ch"

REQUEST SDDODBC, SQLMIX

#define RDDI_CONNECT          1001
 
PROC main()

	RDDSETDEFAULT( "SQLMIX" )
	SET( 4, "yyyy-mm-dd" )
	RDDINFO( RDDI_CONNECT, { "ODBC", "DBQ="  + "test.mdb;Driver={Microsoft Access Driver (*.mdb)}" } )
	DBUSEAREA( .T.,, "select * from test", "test" )

//	INDEX ON FIELD->SALARY TO Salary
	DBGOTOP()

	DEFINE WINDOW Win_1 ;
		ROW 0 ;
		COL 0 ;
		WIDTH 500 ;
		HEIGHT 400 ;
		TITLE 'RDD SQL' ;
		WINDOWTYPE MAIN  

		DEFINE GRID grid1
			ROW 		10
			COL 		10
			WIDTH		470			
			HEIGHT		330
			HEADERS 	{'First','Last','Salary'}
			WIDTHS		{135,135,135}
			ROWSOURCE	"TEST"
			COLUMNFIELDS	{'First','Last','Salary'}
			ON HEADCLICK { {||head1()} , {||head2()} , {||head3()} }
		END GRID
		                           	
	END WINDOW

	Win_1.Center

	Win_1.Activate

RETURN   

PROCEDURE head1()
	INDEX ON FIELD->FIRST TO First
	DBGOTOP()
	Win_1.grid1.Refresh
RETURN

PROCEDURE head2()
	INDEX ON FIELD->LAST TO Last
	DBGOTOP()
	Win_1.grid1.Refresh
RETURN

PROCEDURE head3()
	INDEX ON FIELD->SALARY TO Salary
	DBGOTOP()
	Win_1.grid1.Refresh
RETURN

Thanks for any help.

Qatan