Refresh embedded browse on Enter?

[CALocklin]

Yes, this issue has been brought up many times before and I know there are browse issues but, nevertheless, I'm hoping to get lucky and find a solution to my problem. After much searching on this board and much trial and error, I still can't find a method that will properly refresh an embedded browse in a "parent" form when a new child record is added via a "child" form.

No, adding the new records directly into the embedded browse is not feasible. The child table has about 51 fields and the form is used with conditional objects to dynamically display only those fields that need to be filled based on previously entered data. For anyone interested, the forms can be seen at www.aimsdc.net/Posts/st_Forms.htm. The Work Order form shown is just one version of the conditional objects - the one that displays the most fields. The embedded browse is on tab 2 of the Master Order form. (For anyone reading this in the future, the page name will probably change in a month or so when this is finished and the website is updated.)

I did think of adding the new record into the embedded browse via xbasic then immediately popping up the "child" form to edit it but this eliminates the ability to cancel the new entry and I've already been through that problem with a user of the current app - it raises too many other issues.

I tried every combination of resynch(), refresh(), repaint(), refresh_browse(), refresh_layout(), etc. that I could think of but nothing would work. Even doing a Page_up/Page_down on the parent record didn't do it and I noticed that changing the form to design mode and back didn't do it either. I eventually found that a query method (from the Help file) would work but it shows a "Record is past end of file" error every time the FIRST child record is added. (It's OK on the 2nd and subsequent records.) Here's the method: (the error occurs on the query() line)

rec = fp:tables:ord_head.recno()
.....(various data checks)
fp:tables:ord_item.filter_expression = ".T."
fp:tables:ord_item.query()
fp:Tables:ord_head.Fetch_Goto(rec)
fp.resynch()
fp.activate()
fp.show()
parentform.close()

I did find one thing that works without error messages every time but I hope I don't have to go back to it:
Get the record number of the parent form, Get the ID number of the new child record, Close the parent form, Re-Open the parent form, Fetch the original parent record, activate the browse.

Anybody know a better way?? Perhaps another version of a query? (Note: it would be greatly preferred that the query not limit the parent records.)

[Daniel Weiss]

RE: Refresh embedded browse on Enter?

Hi Cal
Maybe I don�t understand what you are trying to do, but I don�t seem to have a problem in the following case;
I have a set with a form that has a sub form for the child table on it, the sub form is also based on the set not on the child table (I don�t remember why I did it so originally, but something did not work correctly, if I based on the child table) the sub form has a browse on it, not for entry purposes just to give the user a quick glance of what was entered so far. I don�t seem to have any problems with it the browse refreshes correctly after every entry or even when they press next or previous on the sub form the browse goes along with it

Daniel Weiss

[Steve Dentler]

RE: Refresh embedded browse on Enter?

I believe the only sure method is to have the browse update from the current session. You can do this by opening the work-order form using the dialog option and reading the form values when the user closes the form (but before you close the form using Xbasic from the calling form).

You might be able to set a global variables to indicate what portion of the fields need to be updated so that you don't have to write all 51 field values back to the current table.

Example Only:

p = parentform.this
t = table.current(1)
s = table.current(2)
f = form.load("WorkOrder","dialog")
v = f.variables()
v.cond1 = "MyCondition"
f.resynch()
f.show()

Select
case v.cond1 = "MyCondition"
s.change_begin()
s.workorder_number = f.workorder_number.text
s.change_end(.t.)
Case v.cond1 = "OtherCondtion"
S.change_begin()
s.addr1 = f.wo_addr1.text
S.change_begin(.t.)
end select
f.close()
p.browse1.refresh()

[CALocklin]

RE: Refresh embedded browse on Enter?

My main form already has 3 tabs just to hold the main data and is not used for data entry. The "child" form is a separate form - partly because of development problems I had when using conditional objects on top of a tabbed form. Another reason for using a separate form is the complexity of the set for the main form. Data entry using forms based on a single table or simple set seems to be more robust.

Although it's not terribly pertinent here, my ultimate goal will be for all data entry to be done in a form that contains nothing but variables. Then the data will be stored in the table using Xbasic so the table will only be open a split second for each data entry/change.

[CALocklin]

RE: Refresh embedded browse on Enter?

Thanks Steve, I'll give it a try later. I'm working on another problem for someone else right now but I'll post my results.

[Stephen Andrews]

RE: Refresh embedded browse on Enter?

>

Cal,

I've found that for some mysterious reason, refresh() alone doesn't seem to work as expected with embedded browses. If, however, you supplement it with a fetch_last() and fetch_first() it will behave as expected.

If the other suggestions are not full solutions, give this a try.

Steve

[martinwcole]

RE: Refresh embedded browse on Enter?

with 4.5 the only way I could consistently get the correct refresh for the embedded browses was to get the pertinent parent key and store it in a variable (cnum for customer number) and when entering or editing a record for the browse open the 2nd form, close the first form, and then when exiting the 2nd form open the first again, and have it check to see if the variable had a value, and then fetch that record if it did

with V5, however, this has worked consistently, so far:

browse3.resynch()
browse3.fetch_first()

or, if you want it to focus on the correct record in the browse, you could get the record number, etc. when closing the other form.

[Peter.Greulich]

RE: Refresh embedded browse on Enter?

fetch_last() and fetch_first() will not always work - in my experience. Sorry.

[Stephen Andrews]

RE: Refresh embedded browse on Enter?

Peter,

Did you use those in along with a refresh()? These three methods together have worked consistently for me.

Steve

[CALocklin]

RE: Refresh embedded browse on Enter?

Thanks everybody for your comments.

Somebody sent me an e-mail saying they had found that it was critical for the browse to have focus BEFORE doing a resynch. I tried it and it worked! I wish I could remember who it was so I could give credit where due but I deleted the message. (I'm almost embarrassed by how simple it was - but I apparently had plenty of company!)

This works:
fp:ord_item_browse.activate()
fp.resynch()

But this does not:
fp.resynch()

Since the user presses a button to open the "child" form, the browse does not have focus. Adding the line to activate the browse was apparently all it took.

I certainly hope this helps someone else AND if anyone finds this doesn't work, please post a message with details here or send me an e-mail. I'd like to think this is "The Answer" - I'd also like to know if it's not.

[JohnZaleski]

RE: Refresh embedded browse on Enter?

Just a note here:

Adding child records in the background ( a different form or using xbasic ) and then refreshing or resynching the embedded browse on the main form has been known to cause index corruption in busy multiuser environments.

Jerry Brightbill has discussed this on the board and I have dealt with rhe matter on several applications. Even though a methodology might successfully resynch an embedded browse every single time in a testing situation, in very busy environments, this continual resynching seems to result in increased index corruption.

[Peter.Greulich]

RE: Refresh embedded browse on Enter?

I'd like to think this is "The Answer" - I'd also like to know if it's not.

Again, in my experience this method does not always work. Sometimes, yes, sometimes, no.

Peter

[Peter.Greulich]

RE: Refresh embedded browse on Enter?

Like Cal, I think I have tried every combination out there. Some methods works sometimes under certain conditions, but then inexplicably fail in other circumstances. I have yet to see a method that works in all cases every time.

Peter

[whanigsberg]

RE: Refresh embedded browse on Enter?

My recent experience is in line with Stephen's: fetch the last record, fetch the desired record and then resynch() refresh() works. There is a bit of a difference in my application, however.

From the parent form with child records in an embedded browse I
-call a modal xdialog, get values into variables;
-open a second instance of the child table;
-create a new record using the variables as the basic for the field values;
-close this instance of the table, and then
-parentform.fetch_last()
-fetch the original parent record
-resynch.

I suppose a lot depends on the circumstances but it does work reliably for me in this situation and it does sound similar to what works for Stephen.

Bill

[CALocklin]

RE: Refresh embedded browse on Enter?

This was an interesting test.

Since I had previously tried combinations of Fetch_Next and Fetch_Prev, I didn't think this would work but it did. However, there were two interesting things about this....

1. Since the parent form was always working from a "just created" record, it was already on the last record so Fetch_Last shouldn't move the pointer at all. Similarly, the subsequent Fetch_Find also should not move the pointer. Because of this, I had never even considered using Fetch_Last.

Because of the above, I tested it with just the Fetch_Last and the Resynch did not work.

I then tested with only the Fetch_Find and it worked once then quit.

2. I did get a corrupted index after my first attempt and this was the only index corruption I've seen in the past 3-4 days of working on this. (I really love spending time on things like this! And, yes..., I have been known to make facetious statements.)

I should add that about 10 more tests yielded no further index problems so maybe this index problem was just one-of-those-things.

Finally, for what it's worth -- although it's not obvious why a resynch should create index problems, I remain concerned that this will become an issue as John pointed out earlier. For now, I just want to get a single user version of this app working correctly and we'll see about the network issues later.