Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Selected record at same place in grid after indexing
Message
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00468940
Message ID:
00468957
Vues:
32
Hi!

In start up situations:
I made grid class that stores its preferences in the user profile. One of the preferences is a record number. I understand that record number might be different when data changed on the server, but usually it is not, so it works. You can use also ID key field value to remember it and that restore in Init of grid. I guess you data prepared before Init of grid.

In indexing (sorting) situation:
I guess I will add this to FAQ...
There is reliable way to sort (index) cursor for grid and refresh grid without change of the record number AND with very good looking. I made this in my grid class and tested it already 2 years so far. Note that way I used puts a requirement to the cursor for grid - it should not contain changes or should contain, but in table buffering mode. This because changes will be updated when record moved for cursors in the row buffering mode. Anyway, I restrict ant sorting until user saves changes, so you can solve this too on the interface level.

Following is a code from my grid class commented and fixed to do not confuse by details of my framework:
* Grid.RefreshAfterSorting
lparameters poColumn
* column reference should be passed of column being sorted
* called internally only as event from the column header after sorting
with this
	.lSorting = .T. 
        && above flag used in the AfterRowColChange and other grid events to do not fire 
        && any code during running of this method. This method might cause weird record
        && moving by grid when sorted, so anyway it is required. We will force record moveng
        && too for better refreshing.

	local lcOldArea, lcGridAlias
	m.lcOldArea = select(0)
	
	m.lcGridAlias = this.RecordSource
	select (m.lcGridAlias)

	* store 'real' grid position, this is needed because it might change in the next chapter
	local nOldRecNo
	m.nOldRecNo = .nRecno && nRecNo - property that updated in AfterRowColChange event of grid
                      && in AfterRowColChange event flag lSorting prevents change of this property

	&& restore row position - it might be changed during indexing and cell activation

        && after refresh after sorting you can see grid shows, for example, last row only,
        && when really it contains 3 rows and all fit into grid. This is a problem we going
        && to solve by following code lines

	* this must be BEFORE any refresh of grid
	if between(m.nOldRecNo,1,reccount())
		LOCATE FOR .F. && same as 'go top', but works more quickly for filtered data
	ENDIF
	.Refresh() 

	&& activate cell that is appropriate to sorting column,
        && so grid will not scroll out from sorting column. When we do not do this, after
        && click on the header, grid will scroll to current cell (column) focused, that might
        && hide (scroll out) column that is just sorted - looks confising.
	if !.lInit && flag that is .T. when Init method is running.
		m.poColumn.SetFocus()
		if between(m.nOldRecNo,1,reccount())
			go (m.nOldRecNo)
		ENDIF
	else
                && during Grid Init, however, we should not do this because SetFocus will cause
                && error. Just refresh it. This is needed to check for case when we want to restore
                && grid sorting when form loads from user preferenses
		if between(m.nOldRecNo,1,reccount())
			go (m.nOldRecNo)
		ENDIF
		.Refresh()
	endif

	select (m.lcOldArea)
	
	DOEVENTS && this is required before any other actions to correctly refresh grid and do not
                 && move record pointer weirdly
	.lSorting = .F.
endwith
It is also recommended th use thisform.LockScreen to prevent grid plashing - hide all grid refreshing from users, so they will see just results.


>Does anybody know...
>How can I deside where the selected record should appear in a grid in start-up situations or after an indexing procedure.
Vlad Grynchyshyn, Project Manager, MCP
vgryn@yahoo.com
ICQ #10709245
The professional level of programmer could be determined by level of stupidity of his/her bugs

It is not appropriate to say that question is "foolish". There could be only foolish answers. Everybody passed period of time when knows nothing about something.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform