Moving Record up/down in Grid 1

[David Higgs]

I have a Grid displayed on a Form with Up / Down Command Buttons. When I first run the program it is always the '1st record' that get's moved down and not the record where the cursor is located. I would like to be able to click / select any row in the table and be able to move the contents up/down with the cursor following the record so that the record can be moved further up/down. I'm thinking I need a RecNo() or Set Focus somewhere, but I'm not sure!

	SELECT net_list

	SET ORDER TO pos

	pos_1 = pos
	call_1 = callsign

	skip

	pos_2 = pos
	call_2 = callsign

	replace pos WITH pos_2 FOR callsign = call_1

	replace pos WITH pos_1 FOR callsign = call_2

	*	= TABLEUPDATE(.T.)  

	DO alt_col		&& Alternative Column Colours

	GO TOP

	SEEK (pos_2)	&& Return pointer to selected entry

	thisform.pageframe1.page8.grdWab_net.Refresh

Regards,
David

 

[Mike Lewis]

First, you need to do the SEEK after the Refresh. The Refresh will re-load the grid with the data, and put the record pointer on the first row.

Alternatively, don't do a Refresh. Do a SetFocus instead.

Having said that, are you aware that the Listbox control has this feature built in? You just need to enable the MoverBars property. It has the advantage of letting the user move the rows by dragging with the mouse, by using keyboard shortcuts, or by clicking Up and Down buttons as per your existing grid.

I appreciate you might not want to abandon your existing grid, and might prefer to solve the present problem. But I thought I'd mention the Listbox in case you didn't already know about it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Hello Mike,

Thank you for your reply.

The Refresh will re-load the grid with the data, and put the record pointer on the first row.

I would like to be able to choose any record to move up/down and the cursor to follow the record, not go to the first row. The code is not executing at the current cursor position, so I need to update cursor position? The annoying thing is, I had this option working at some stage but have not visited it for many months and I can't find my original code!!

Having said that, are you aware that the Listbox control has this feature built in?

No, I didn't know about this, I will take a look at it.

Regards,
David

 

[Mike Lewis]

David,

OK, I see what you mean now. The position of the SEEK obviously isn't the issue.

Are you sure your Pos field is being correctly updated? Can you check its value at the point where you do the SEEK?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Are you sure your Pos field is being correctly updated?

Yes it is, I have it displayed on the Grid and also checked with a Browse.

The issue I have is that when running the form for the first time it is always the '1st record' that will be moved up/down irrespective of where the record pointer is. I want to be able to click on any record and move it; this is not happening.

I took a quick look at Listbox and moverbars, it looks ok but I was unable to get moverbars to work because I have RowSourceType = 6 (Fields) and with that option moverbars is not available. I would also like alternative row colours and I'm not sure if that works with a listbar, so for the time being I will continue with my code.

Regards,
David

 

[David Higgs]

I temporarily modified my code to "SEEK" an entry within the table which confirmed that the "record Pointer" position is not being updated in the code example above when I click on a row. Once the "SEEK" had found the record, it was this record that moved up/down and not the first record.

In my Code Example above you'll notice I have not activated TABLEUPDATE() although it was in my original code. However if I use the TABLEUPDATE() Command, I get the "requires table buffer mode" error. I don't recall having this issue with original code.


Regards,
David

 

[Mike Lewis]

I did notice the commenting-out of TABLEUPDATE(), but I didn't think that would make any difference. If the data is not committed, the SEEK would operate on the buffered data, so either way it should go to the correct record. However, if you want to try it with the TABLEUPDATE() in place, you only need to call CURSORSETPROP() to set a buffer mode. Then again, I don't know what implications that would have for other parts of the application.

By the way, I just noticed the GO TOP. I don't think that will do any harm, as the SEEK in effect will override it. But it might be worth removing it, if only to simplify the code slightly.

Also, since we last spoke, I've been trying to reproduce the problem, but haven't managed to do that - mainly because I don't know what other code you have that night affect things. I'll try again when I can grab a moment.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Ok, I added =TABLEUPDATE() and the following code:-

SET MULTILOCKS ON

SELECT 0
USE wab_net_list IN 0 ORDER pos ALIAS net_list

=CURSORSETPROP("Buffering", 5, "net_list")

still not working as expected.

I vaguely recall that =TABLEUPDATE() came to my rescue when I was writing the code for the first time. I don't know what I may have changed over the months for this not to work.

Just to make sure that I have explained everything correctly, if you take a look at this Link you will see the pointer is pointing to "Chai" i.e the top record. If I click on say "Ikura" and then pressed my "Down" command button I would expect records "Ikura" and "Quesocabrales" to have swapped places. In my case what is happening is that "Chai" and "Chang" are swapping places, no matter where you place the cursor on the grid. If I were to SEEK "Ikura" it would be this record that is moved up/down. I am sure it something simple like a setting in the table properties because I think that is the only thing that might have changed since my original program.

Regards,
David

 

[Mike Lewis]

What you said about setting the buffer mode confirms what I thought: it doesn't make any difference. So I suggest you remove the buffering code - including the TABLEUPDATE() - so as to simplify the code and let you focus on the problem.

With the grid example that you showed, it's easier to understand what you are seeing. I assume that pos (in the line [tt]Pos_1 = pos[/tt]) is a field in the table, specifically used to determine the record's position in the table. Is that right? And what exactly is callsign? Is that a unique field within the record?

Mike






__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

I assume that pos (in the line Pos_1 = pos) is a field in the table, specifically used to determine the record's position in the table. Is that right? And what exactly is callsign? Is that a unique field within the record?

Yes "POS" is a field in the Table which is used to determine the record's position in the table and to set alternate colours to the Grid Rows.

The application is all to do with "Amateur Radio Operations" where each individual is allocated a "Callsign" used to identify themselves. The list is basically a order in which each "Callsign" will Transmit. On occasions it is necessary to rearrange the order of the Transmission, hence the code. So, yes, "callsign" is unique.


Regards,
David

 

[Mike Lewis]

Sorry, David, but I've been trying to reproduce the problem, but don't see the behaviour you are seeing. I have to clock off now but might re-visit tomorrow.

The only thing I can think of is that you have some other code somewhere that is changing the record pointer - between the user clicking on the grid row and your saving Pos and Callsign. It might be earlier in the Up/Down buttons' Click, or somewhere else in the form, such as the grid column's GotFocus. Is that possible?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[David Higgs]

Thank you for your help Mike.

I will try making a new "stand alone" module and see how I get on.



Regards,
David

 

[Olaf Doschke]

In what event or method of the grid is this code? Not in grid.click, is it? The "grid" itself merely consists of grid lines, a click into cells is not triggering grid.click but grid.columnx.text1.click, for example. An event to use to let the code work on the activated row would be afterrowcolchange. It happens after the row/column is the active one, so you act on the clicked row.

Bye, Olaf.

 

[Olaf Doschke]

DO alt_col

There can be many things in alt_col.prg disturbing the positioning of the grid.

Bye, Olaf.

 

[David Higgs]

Ok, a quick update:-

I decided to make a New Test Project with a Table of 5 records with 2 Fields (1) POS (Indexed Table Position) and (2) Location. I entered 5 City Names in random order and Indexed on POS. This gave me a list in a Grid of POS in numerical order and 5 cities in random order.

On the Form I created 2 Command Buttons UP & Down.

I ran the program and found that I was able to achieve my goal of moving any selected Row up or down.

So, now I need to investigate why my original program doesn't work in the same manner. The only things that I can remember changing is that my original code was written in VFP 6 and I'm now using VFP 9. Also I recently changed from an old habit of using "USE FILE IN H" where as I now use "USE FILE IN 0".
One other thing maybe worth a mention is the Grid is in a Pageframe, I think this was the case before, although I may have done the development on a single Form, I'm not sure.
I'll report back.

Regards,
David

 

[Mike Lewis]

David,

The fact that you now have a working model is a good start. You should now gradually incorporate the features that are in your full app, until you start seeing the bad behaviour again (if you do). That will give you a good clue as to where the problem lies.

Regarding USE FILE IN H vs USE FILE IN 0, the most likely implication is that you might have the wrong table selected at the point at which you switch the records. But since you explicitly SELECT the table at the start of the code, that would be unlikely.

It would also be worth looking at your Alt_Col routine, to see if that has any side-effect (as Olaf pointed out). But, again, I would think that unlikely, given that you have already stored Pos and Callsign at that point.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

One thing I see in the posted code, no matter where it's done, which could go wrong is, if both callsigns are equal, pos_2 is lost and overwritten by pos_1 and SEEK(pos_2) would go to EOF of net_list.
Besides that, obvious things not working would be net_list not being the displayed Alias.

It wouldn't matter, whether the grid is in a pageframe or not, if you refresh the form, nonactive pages will not refresh, but the moment you activate them, they will, so the refresh will come sooner or later, besides a setfocus should be sufficient, as Mike answered first.

Bye, Olaf.

 

[David Higgs]

Another update.

Well, it turned out to be something wrong with the "GRID". I will take a look a the "Properties" for each Grid to see if I can find anything.

Thanks again for all the help.

Regards,
David