Strange Control Browse Issue

[GoStern]

Re: Strange Control Browse Issue

Thanks to all. The patch fixed the problem.

[ADCO Service]

Re: Strange Control Browse Issue

Thanks Tom for your follow up.

Any idea as to when the pre-release will go into production?

[Tom Cone Jr]

Re: Strange Control Browse Issue

Nope, sorry.

[MoGrace]

Re: Strange Control Browse Issue

This is similar to many reported user experiences with interactive browses.
Its kind of known about (I don't mean acceptable)

but often manageable if you have the need. Some methods I have used to tame..

causes could be;
Certain OnRow... activity and especially event/events if you use them.
Table or Form wide calculated fields.
These may scroll the underlying table and not always re-position the browse. Especially when it is a scrollable browse (ie not all rows fit in the frame)

try some functions including
Get_Viewport_Row()
topparent.Resynch()
Scroll_Current_Row(cr)

24 May 2013 Raymond Lyons suggested in a post
"Have you tried <OBJECT>.REFRESH_FIELDS() ? Or <OBJECT>.REFRESH_LAYOUT() with the object being the name of the form?"

Hi Ray,
I found a couple of threads that suggested using get_viewport_row() but the problem with that function is that the row number it gets only relates to the rows currently displayed in the embedded browse. IOW you may have 200 records but only 20 display at a time in the browse and so your row number will be in the range of 1-20. If for example you delete a record using the delete_record() function, it will jump to the end of the browse so that scroll_current_row(var) returns you to the row in THAT current display (ie. row 1 is now 20 records from the bottom) - not the one you were viewing before!

This works in a button for deleting a record then takes you back to the next record in the original display based on my current index key for the form:

dim gokey as c
dim curkey as c
curkey = cdate(txdate.value)+needle.value
ui_freeze(.t.)
topparent.fetch_next()
gokey = cdate(txdate.value)+needle.value
[COLOR="#0000FF"]'used to test
response = ui_msg_box("Delete Record","Index Key: "+curkey,33)
if response = 2 then
	end
end if[/COLOR]
topparent.fetch_prev()
topparent.delete_record(.t.)
ui_freeze(.f.)
topparent.find(gokey)

[Ray in Capetown]

Re: Strange Control Browse Issue

Yes Robin, I can see how that sequence would keep things tight. Working outside the browse - ie the button is on the parent form.
Through it, I just discovered another nicety that I hadn't come across, UI_Freeze.
So if I want a size 36 top there's a high likelihood I'll get one ? (blue is good).

Could a method like that help in the case of editing directly in a browse where the underlying record (and therefore data) goes out of sync and messes with the current?

[martinwcole]

Re: Strange Control Browse Issue

I've had this issue for years, and not just with embedded browses, but also with the parent record in a set for the form. My approach, where the event and script vary according to the circumstance, has been this:

In the autoexec I define a global variable
dim global rnum as n=0

then, where I am committing a record in the form, I say something like this: (which in this case applies only when editing a record)

dim global rnum as n
t=table.current()
rnum=t.recno()
parentform.commit()
if t.recno() <> var->rnum
parentform.index_set("")
parentform.find(var->rnum)
end if

where this goes, and the syntax, varies on the situation, but it has been a satisfactory solution for jumping records.

[Ray in Capetown]

Re: Strange Control Browse Issue

If the "commit()" changed the record pointer, then "if t.recno() <> var->rnum" it will be returned to the record visible prior, using rnum.

My fear with browses is that the edit was made in , say browse line 5, the calculation picked up data from browse line1*. Commit would save the record at browse line 5 (with an incorrect value) and then your test would return one to the same browse line, line5. Which it never left in the first place.

*this is the most common experience I have had, before I avoided form calcs on browse line fields where some or other form calc parsed the browse records.

The difficulty is then replicating the scenario for publishing here, in so doing the thing works correctly.
Going back to the live db and trying to eliminate various things, it begins also to work properly. Sometimes for a while. Then seems to stabilize.
Now since I am still using v10 I can't very well present a case, if I did nail one example down to being replicable.

Previously, when it has done that, I have done a check for the record number browse to table, it checks always - but still, a field value from a linked child table is returned with a value from a record that the first item in the browse is linked to.

I appreciate your interest any how, but wouldn't throw any further effort at it unless you have had some similar experience already. I am circumventing this happening with some avoidance tactics.