remove selection of record in a grid

[keepfoxing]

i have a grid on a form and when im adding
a new record, it replaces the selected record on my grid.

how to solve this issue..tnx

 

[Scott24x7]

Do you have any code to show us?

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

I'd ask the same. Especially about "when I'm adding a new record"
If you use INSERT-SQL or APPEND BLANK, no record is overwritten.

It might visually seem so, if the new record appears at a place in the grid, where another record was, but that scrolled away, then.

Or do you add records via Hotkey? Do you give it the same ID, so it overwrites an existing record?

It's not possible to help you without knowing what you do, this is not a behaviour coming from the grid control alone, using the native grid. That gives editing abilities, if (besides other prerequisites)= AllowCellSelection is .T. and allows adding records by the AllowAddNew setting. With that setting you still overwrite existing records, if you edit them. You still have to do something to first get a new record: You have press the DOWN ARROW while being in the last row. If that is swallowed, eg by ON KEY LABEL, then that doesn't work, but it's still not the grid overwriting the selected record. It's still you editing the selected record instead of first adding a new one then.

I rather think you see the effect of a record being overwritten in the grid by your code, but the grid just displays that, it doesn't do it.

Do you do a GATHER? Do you expect it to add a new record? Then learn from what you see, it does not do so, it changes the selected record. Do you do a REPLACE? The same applies for that, with several scopes it can even modify multiple records. Both GATHER and REPLACE don't create new records. Do you do an INSERT? If you use the SQL-Insert it adds a new record, if you use the INSERT command not being documented anymore, you just insert a new record somewhere else than at the end of the dbf file, but you might not be positioned on that newly inserted record "slot". Don't use that command, it's deprecated.

Bye, Olaf.

 

[Mike Lewis]

It might help you to keep in mind that when you are supposedly adding or removing records from a grid, what you are really doing is adding or removing them from the underlying cursor. The grid is merely a window on the cursor. So it boils down to what method you are using to add or remove from the cursor.

If you could clarify that, we will be in a better position to help.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I think what is happening is he is adding a record to the underlying data, which moves the record pointer for the grid, but is not
actually issuing a thisform.grid1.refresh. so as he moves left and right across the columns the new data would 'appear' and replace
the originally selected record.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

To summarize the consequences of what Mike and Griff said:

After you add a record do a THISFORM.REFRESH() to see the change.

And one more thing: SET REFRESH to some seconds will not refresh UI, mainly only browses, not grids nor other controls, if you think that should account for UI refreshs. In terms of UI SET REFRESH is really just limited to BROWSE windows and memo editing windows popping up from browse. Otherwise it does refresh the local cache. But not grids.

Bye, Olaf.

 

[Mike Lewis]

Rather than THISFORM.REFRESH(), I usually do THISFORM.MyGrid.SetFocus. It has the same effect, but it generally quicker. Also, I believe it does not move the highlight, whereas a Refresh will set it back to the top of the file (I'm not completely sure about that).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

grid.refresh does not move the current record, grid.setfocus does not necessarily refresh the grid.

grid.refresh followed by grid.setfocus is normally what I do.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Olaf Doschke]

> Refresh will set it back to the top of the file
No, that's not the case. A Form refresh will simply also refresh other parts that might show single fields of the current record. If you know you only need to refresh the grid, setting focus to it would be sufficient, that's true.

The FFC navbar botton have a refresh routine doing a thisformset.refresh() in case of formsets and a _screen.activeform.refresh() otherwise. Also a special handling in case of 1:n forms, but in general the form refresh would work here and if MS does it that way, it shouldn't influence the record positioning. I am also quite sure about that, it just confirms my idea of what the form.refresh() does. Some frameworks do act on relations or do other data lookups within Refresh events of framework controls. That might result in going to top somewhere, but that's not native behaviour. It's also a misuse of the refresh() event and a side effect of giving the forms an intellligence that should not be put into them. And that is not only a matter of your framework architechture, because a refresh also is triggered, if you move a form and that has to be considered when writing refresh code. Doing too much in a refesh can cause a cascading and - worse - a self triggering event cascade. Calling the refresh is not the sin, though, doing more than refreshing current display in the method (which is native behaviour already) is the culprit.

Just to clarify: Actually refresh is not an event, it's a method you call triggering some native behaviour. In that sense it works as an event, especially since a form.refresh() causes this native behaviour code to refresh all visible objects, so it has a cascading effect in itself without you needing to loop objects. You might extend that behaviour, but should only do so in the sense of refreshing current data display only.

Bye, Olaf.

 

[Mike Lewis]

I've just done a quick test. I highlighted a particular cell in the grid (not in the first row). When I did a refresh, the highlight disappeared, and the record pointer was at the top of the table. I repeated the test, but this time I did a setfocus; the record pointer and highlight remained in place.

But let's not get bogged down with this. It does not directly answer KeepFoxing's question, and might only serve to obfuscate the answer.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike,

maybe you test to combine both refresh and setfocus, as Griff does. The pointer pointing to the top is a strong sign, but I wonder if that is just temporary. The grid surely reads the few records it displays during the refresh, but it should end the pointer were it was, the record might just move to the top of the visible grid, but that is the record scrolling up, not the current position in data moving up.

Bye, Olaf.

PS: And by the way I just used a native formk, native grid and native button and a grid.refresh() does neither move record pointer nor scrolls up the current record. You must have some code in refresh, Mike.

 

[keepfoxing]

sorry for the late response..
here is my code on the add button.

SELECT stud_table
	=CURSORSETPROP("Buffering",4)
	APPEND BLANK
	
	replace Id_no WITH thisform.txtId_no.Value
	replace lname WITH PROPER(thisform.txtlname.Value)
	replace fname WITH PROPER(thisform.txtfname.Value)
	replace mname WITH PROPER(thisform.txtmname.Value)
	replace major WITH thisform.cmb_major.DisplayValue
	replace yr WITH thisform.cmb_yr.DisplayValue

	replace pic WITH thisform.txtsaved.Value
	
	=TABLEUPDATE(.T.)

actually this:

replace pic WITH thisform.txtsaved.Value

is the only field that replaces the selected record.

 

[Mike Lewis]

What do you mean when you say it "is the only field that replaces the selected record"? That doesn't mean a thing to me.

This is probably a very simple problem, but it will take us a long time to solve it if you can't explain it clearly.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Olaf, I'll assume you're right about the record pointer in a Refresh. But we still don't know if that's the reason for the problem that KeepFoxing is seeing, which is why I was suggesting that we don't persue it for now.

KeepFoxing, it would help if you could tell us if you have tried doing a Refresh or a SetFocus (or both) after the update, as we suggested earlier, and if in fact that solves the problem. If it does, we can re-visit the question of whether a Refresh is better than a SetFocuc or vice versa, but that's not the main point at present.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[keepfoxing]

sorry for my bad english..
wat i mean is that..
after append blank, this adds a new record blank and replaces with this code.

replace Id_no WITH thisform.txtId_no.Value
	replace lname WITH PROPER(thisform.txtlname.Value)
	replace fname WITH PROPER(thisform.txtfname.Value)
	replace mname WITH PROPER(thisform.txtmname.Value)
	replace major WITH thisform.cmb_major.DisplayValue
	replace yr WITH thisform.cmb_yr.DisplayValue
        replace pic WITH thisform.txtsaved.Value

but the last line replaces the pic field of the selected record on the grid.
or in other words, 2 records have the same pic value..

 

[Olaf Doschke]

No, the replace command works in current workarea and when you don't specify a scope on the current record only.

Take a look on the controlsource of the txtsaved textbox. Something else is causing the pic to change, not this replace. Not, if it's right after the append blank.

To make sure, don't do a series of replaces, don't append blank, instead do one insert:

INSERT INTO yourtable (Id_no,lname,fname,mname,major,yr,pic) VALUES (thisform.txtId_no.Value,...)

All your controls then should be unbound, but you'll only be able to enter new records then, not modify existing records.

If you bind controls to the table, they will always modify the current record, also a new one you add with APPEND BLANK. Then you don't do any REPLACE, you simply enter the data while being positioned on the new record. The controlsources are a two-way connection to the data, displaying current data and modifying it interactively. There is no need for code putting the values into the table fields then, the controlsources do that.

There are a lot more things to say, eg IDs should rather be autogenrated and won't ever come from a textbox, eg using data binding (controlsource) you'd not need these REPLACES at all, because controlsources set the field values, and much more. It is quite obvious despite your choice of name "keepfoxing" you are not a frequent fox developer and may have just started using FoxPro. I suggest you look out for some basic tutorials, especially about database theory, that also will be helpful, if you later switch to something else, DB and SQL knowledge helps you find other jobs with data centric business applications.

Bye, Olaf.

 

[Olaf Doschke]

Also, since you have a problem with a pic field: There is no control you can bind to an image, so a column, which should show a pic per records needs quite some trickery. The control to display a pic is an image control, it has no controlsource nor value property, instead it has a picture and pictureval property. The latter one came with later VFP versions only. To display a pic per record you need an image control class, that has a backstyle_access method to set its picture with a path to a pic file or its pictureval with a blob of the image itself, the first one is more recommendable than storing pics themselves in blobs.

If you don't have that the image control put into a grid will display the same image of the current record in all rows.

That's not the problem you describe but worth noting. If you really have the same pic value in the current and the new record after your code ran, be assured this is not due to the replace. I'm quite sure the controlsource of the textboxs is binding it to the pic field. If you comment the replace, you'll get the pic in the current record then, when you leave the control. A control saves the value of itself into what is sepcified as controlsource, if that is writable (like a field of a table) and in the moment the valid returns .t. or a numeric value specifying how many tabs to set the focus to somewhere else. Or also when you click on a button like eg a "new record" or "add" button.

Bye, Olaf.

 

[keepfoxing]

i have already checked the control source of each textbox but
there is none..

 

[Olaf Doschke]

1. Then the double setting of two records remains a mystery. Do you do the APPEND BLANK right before the REPLACES? If not, that explains it. The grid makes some record the active record, the user can change to any record, and the final replace changes whatever current record instead of the blank record appended earlier.

2. Then learn how to use controlsources, as that works without both REPLACE and INSERT. You simply APPEND BLANK to start with and a user can edit that new empty record.

Bye, Olaf.

 

[Mike Lewis]

You could also try temporarily removing the Replace of Pic, just to see if the problem goes away (you might already have done that).

By the way, what is the data type of Pic?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads