new <Layout>.Refresh() function

[reynolditpi]

I have been trying to use the new <Layout>.Refresh() function but always get an "object does not support requested interface" error.

I have been trying: topparent.refresh()
It is attached to a button push event and is used at the end of a short script that deletes the current record from the db.

Is topparent.refresh() improper syntax?
Thanks
Tony

[Raymond Lyons]

Re: new &lt;Layout&gt;.Refresh() function

You might try parentform.refresh() or maybe use .resynch() instead of .refresh()

[MikeC]

Re: new &lt;Layout&gt;.Refresh() function

I could be mistaken but seem to recall that .refresh() is for objects not layouts....at least in prior versions....and is not a new function. You may be wanting .refresh_layout() ...which also is not a new function.

My mistake as far as not for layouts---guess I did not relate a layout as being an object. And have not used it as such either....maybe I should??!! :)

[reynolditpi]

Re: new &lt;Layout&gt;.Refresh() function

Maybe I need to be trying something else?.?.?

Here is my problem:
I have several fields on a form which are based off of a child table. I have a button on the form that uses xbasic to delete the record from the child table.

As long as thier is another record to be shown, the fields will refresh to the new data. However, if I delete the last record the fields do not refresh to show that thier is no data. They still display the last record deleted. If I navigate to a new parent record and come back, the fields are blank as they should be.

I have tried the action script to refresh the form but the form then moves to the first record in the parent table instead of staying on the current parent record. I suppose because of the topparent.commit() function.

I have also tried to use topparent:fieldname.refresh() and parentform:fieldname.refresh() and it does not refresh the fields.

I have also tried topparent:fieldname.resynch() and the parentform version and nothing works.

So...if you are deleting the last record in a child table for a parent record, how do you get the fields in the form to clear? I am sure it is something simple.
Thanks
Tony

[MikeC]

Re: new &lt;Layout&gt;.Refresh() function

Tony,
A sample would help...Is this a child embedded browse by chance?

If so try a browse1.fetch_last() followed by a browse1.fetch_first()...or even maybe just the latter if you have it play when the last record is deleted...and if something is found to work, it could be made to run only if the last record is going to be deleted. (Sure seems I had to do something similar once for someone.)

[reynolditpi]

Re: new &lt;Layout&gt;.Refresh() function

Thanks Mike.
I do have a browse based on the child table, but it is refreshing as it should after deleting the last record.

I would rather not post this form to the forum if I dont have to. Could I email you a copy?

Thanks again.
Tony

[reynolditpi]

Re: new &lt;Layout&gt;.Refresh() function

here is the solution:

Use topparent.commit() and then topparent.refresh_layout() in the script after the deleting the record from table...NO resynch()

Thanks to Mike C for the help!

[CALocklin]

Re: new &lt;Layout&gt;.Refresh() function

A *very* important part of refreshing is how you are actually doing the deletion but you didn't tell us anything about that. If you are using <table>.OPEN() in the script that deletes the records, refreshing your form will be very difficult. <table>.GET() works much better.

[reynolditpi]

Re: new &lt;Layout&gt;.Refresh() function

Thanks Cal.

I was actually using <table>.current(). It has been suggested to not use <table>current() and to switch to <table>.get() so i am in the process of switching over.

Just for learning purposes, could you please elaborate on why <table>.open() is harder to refresh from then <table>.get?

This priceless type of information is not in the help files so great to get your feedback.

One more thing...Am I right in thinking that <table>.current() is not the best function to use because you might delete a child table which would change the table number of the tables after the deleted child...therefore pointing <table>.current() to the wrong child.

The reason behind not using this funtion was not explained.

Thanks again.
Tony

[CALocklin]

Re: new &lt;Layout&gt;.Refresh() function

Difference between table.current() and table.get():

As far as I know, table.current() does the same thing as table.get() except that table.current() uses a "table number" based on where the table is located in the set and table.get() uses the table name (or alias name if appropriate).

I normally like to use table.get() for two reasons:
1. It's easier to figure out what I'm doing when I see Table.get("invc_detail") than when I see Table.current(3).
2. If I ever restructure the set, the table number may change. That requires correction whereas it would not need to be corrected if table.get() had been used. Also, corrections will be tougher to make if there were other references to Table.current(3) that belonged to a different table/set.
3. There may be some strange situation where table.current() may not be the table that you think it is. If this happens, it's probably your fault (the developer) for not understanding it correctly but it may not be immediately or intuitively obvious. For example you might forget that you started the action from a subform and be thinking that table.current() refers to the parent table of the main form. (Take that only as a possible example. It may or may not happen exactly like that but I know I've been in situations where table.current() pointed to a different table than I had expected.)

I could be wrong, but other than the above I don't know of any differences in the two.

The difference between table.get() and table.open():

It's tough to find a really good example so I'll just do the best I can.

The basic issue is this: Table.get() opens the table in the current session. Table.open() opens the same table but in a different session.

When you already have table "A" open because it's used in the current form, using table.open() opens a separate copy of it. This is rather like saying "I'm using this database called "Fred" but now I want to copy it to a temporary folder and open that second copy so I can make changes." So you copy the whole application to the temp folder, make your changes, then you have to "resynch" the original folder with the changes in the temp folder - difficult but not impossible to do. It would have been much easier if you just made the changes in the original database.

When you use table.get() in your xbasic routine, you are using the exact same copy of the table as the one your form is using. Quite often this means that there is no resynching or refreshing to be done. The results will automatically show up when the xbasic changes are complete. It may sometimes require refreshing (I usually find that Refresh_layout or Refresh_browse works well) but I don't believe it ever requires resynching.

Here's another thing to be aware of when using table.get(). If you are 'getting' a child table of the current set, a "fetch_first()" will generally take you to the first record of just the ones linked to the parent table. Similarly for a "fetch_last()". So, if there are 3,456,789 records in the child table but only 3 attached to the current parent record, a fetch_first() will find the first one related to the parent record and doing "fetch_next()" twice will get you to the last record related to the parent. Often a very handy method to use - HOWEVER, I recommend you always test this before just doing it and letting your customer start using it.

I believe you can also use table.get() then reset the index and get other records not related to the current parent but in that case I'd probably just use table.open() anyway - after all, those other records aren't related to the current parent record so resynching shouldn't be an issue. Plus, (a) I can't guarantee what would happen to your form if you reset the index via xbasic and (b) resetting the index may not yield the results you expect because of some other restriction based on how the form is set up.

DISCLAIMER: The above is intended to give you some general concepts. (Notice my uses of "sometimes", "probably", etc. - these were not accidental!) I myself am not sure exactly when something will or will not work. I believe sometimes it depends on which version of A5 you are using. Other times it just depends - I'm not always sure on what.
TEST, TEST, TEST - then give it to your customer to break.

I hope this helps clear it up a bit.