Refresh/resynch revisited

[Jeff Fried]

I have raised this issue before, but there does not seem to be a viable solution I have seen to solving this, but maybe someone has an insight.

This relates to screen refresh or resynch not truly refreshing a form under certain conditions where a "true" refresh is needed, equivalent to closing the form, then reopening the form. I have so many situations where it would be useful to "refresh" exactly as if the form had been closed and reopened.

The example is where I am building a capability to duplicate the content of a set (header and items in a purchase order) by setting up operations that export the header and items to temporary files, update the po number in the temporary files, then import the temp header into the header and temp items into the item file. I then set the index to po number, do a find, and no, it's as if the record has not been created. All I have to do is exit the form, then re-enter the form, and I then easily find the new po. Why is there not an equivalent action that I can write into an action script or xbasic routine that will do a true refresh so the user doesn't need to exit and re-enter?

If you know of a way to make this work, please help. Thanks.

Jeff Fried

[brett s]

Re: Refresh/resynch revisited

Jeff, I'm sure you are not the first one to experience this difficulty with refreshing information displayed on a form. But the solution is not always straight forward. Can you post here a small application that demonstrates the problem? Then someone may be able to help out.

[Barry]

Re: Refresh/resynch revisited

Hi Jeff,

If it's the problem where you have close the form and re-open it to display
the correct records, I use a button on the form to refresh the index, works
in my case.
Hope this helps

Barry

[Jeff Fried]

Re: Refresh/resynch revisited

Barry,

I know what you're saying. I have the same setup, where the user needs to press a button to "straighten it out". This is exactly what I'm trying to avoid by eliminating this step for the user by doing the "equivalent of pressing that button" in the code that runs the procedure. This whole thing is a big mystery to me. For example, when you select an index on the form you are going to, even though you have already opened that form, you still need to select an index for "another form", which is counter-intuitive. You select a variable not from the form you just opened in the script but from "another form". Somewhere in this process must be the answer to how you straighten out the indexes that make the final result of the actions resynched. I've spent countless hours trying to figure this out but can't come up with a stable environment for the user unless I do as you're saying, place a button on the form that the user needs to press.

Thanks.

Jeff

[MikeC]

Re: Refresh/resynch revisited

Jeff,
Could be just my novice mind but until a viable solution is found why couldn't you use a button but simply have it hidden and use "button.push()" in your code?

Mike

[Jeff Fried]

Re: Refresh/resynch revisited

Bingo! Mike, this is the essence of what I need. I have not used button.push(), but I assume it is the equivalent of a physical mouse click. I will try it. Thanks.

Jeff

[Jeff Fried]

Re: Refresh/resynch revisited

Mike,

Can you give me an idea of the syntax to use this button.push() method? I tried it, but I'm missing something. I'm clicking on the button of a form that opens the form named "SpecEntry" with the button I want to push, the object name of the button being "button22". What code would I add to an inline xbasic script? Thanks.

Jeff

[MikeC]

Re: Refresh/resynch revisited

Jeff,
Usually you could simply use button22.push(). If this doesn't work try using topparent:button22.push() . Depends on where your button is located so if topparent doesn't work try to use the explicit----your form name:button22.push() .

Mike

[Jeff Fried]

Re: Refresh/resynch revisited

Mike,

It works beautifully. As it turns out, I did need the explicit form name to make it work [specentry:button22.push()].

This will become my standard workaround when a true refresh is needed.

Thanks.

Jeff

[CALocklin]

Re: Refresh/resynch revisited

FWIW: I solved most of my refresh/resynch issues by using table.get() instead of table.open(). (I won't say *all* yet until I get more examples under my belt but certainly most.)

For example, instead of:
tp = table.open("Invoices")
tp.enter_begin()
...enter values...
tp.enter_end()

Use:
tp = table.get("Invoices")
tp.enter_begin()
...enter values...
tp.enter_end()

Since you are working with the current "session" of the table, resynching and refreshing becomes much easier and does not seem to require re-running the query or closing and re-opening the form [as I've done, and recommended, in the past].

HOWEVER, it may require xbasic rather than using action scripting for these operations.

[Tom Cone Jr]

Re: Refresh/resynch revisited

In case some may be missing part of Cal's point, it should be noted that if you're using saved operations to copy records to a temp table, and then import them back into the current set of tables, then each operation will open a new instance of the table, rather than use the same instance which is already open supporting the current form. -- tom

[Jeff Fried]

Re: Refresh/resynch revisited

Cal,

Thanks for the code. It's looking like you're zeroing in on a solution to the problem.

Tom,

What you describe is exactly the situation I'm working with. An operation creates temporary header and detail records that I then import back to the original files. Getting it to settle properly has been the challenge. Is there a way to maintain the same instance of the form in action scripting, or do you need to code it? Most of my hangup is with opening a new instance of the same form each step of the way through a series of action scripts.

Jeff