Refresh Display function not as I thought

[Jeff Fried]

I'm using Refresh Display to update a form for actions run in the background as part of an external process initiated by a button on the form. The problem is, it doesn't update the form, as I thought, and to do the update I need to close and re-open the form, which then shows me everything.

In the external process, some of the fields in the form are populated, as well as a linked table. The correct data is actually in the fields of the form, which I can check separately, but they neither appear in view nor show the data from the linked table (linked by one of the field values of a field updated by the external process). At the end of the sequence is a Refresh Display, but it doesn't show the results of the external process. As I said earlier, in order to show the result of the process, I need to close, then re-open, the form.

Is Update Display not the equivalent of a close and re-open? Do you know of an alternate command that will achieve this without closing and re-opening, which has some coding overhead with it that I want to avoid. If you have experience with this, please advise. Thank you.

Jeff

[Al Buchholz]

Re: Refresh Display function not as I thought

Jeff

Have you tried an <object>.resynch()?

[Jeff Fried]

Re: Refresh Display function not as I thought

Al,

I tried parent.resynch(), but it had no effect. I'll go back and try to refresh specific objects to see if that works. Thanks.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

I tried variations of resych() and refresh() to achieve the same result as if I had exited the form and returned, but nothing worked.

In order to show the new status (updated field data, updated link) I need to exit the form, then return back to the same record.

To achieve this result in an automated way, I developed a standalone script that, when executed, goes to the correct record and displays everything correctly. I am trying to run that script at the end of the procedure on a button within the form, but it ends up on the control panel at the script. I have to execute it separately. I tried setting this up on a form event OnExit and OnDeactivate, but nothing "pushes" this script to action. What am I missing?

Thanks.

Jeff

[Cheryl Lemire]

Re: Refresh Display function not as I thought

Jeff,

This may not be the best solution, but it should work. Add another button to your form, in the OnPush play your custom script, and hide the button. Then in your other button that runs the other process, at the end push your new hidden button. I don't know if there is any action scripting to push the button, if not the xbasic would be: parentform:button_name.push()

Good luck

[Jeff Fried]

Re: Refresh Display function not as I thought

Cheryl,

In the OnPush sequence, just before I run the independent script to open the form (FormA), I close the form (FormA).

On FormA, there's a button saying "Convert text to spec" which performs a process that manipulates data in a memo field and results in transforming the memo data to "data" data, with certain fields filled in on the form. The data is in the fields, but it cannot be seen until FormA is exited, then re-opened, this being my issue.

I created an independent script that, when executed, will open FormA and go to the correct record based on pulling the record's key value from an external table in order to find the correct record.

The solution you suggest requires pushing a button on the form that has already been closed, so it won't work.

What I don't understand is why the external script won't play and open up the form, i.e., why can't the baton be passed from the initial script to the independent script. In Alpha Four, there was a need for "Trigkeys" to make certain events "trigger", but I'm not aware of the need for a "Trigkeys" in A5. So bottom line, what do you need to do to push a button on a form that both closes the form and executes another script?

Thanks.

Jeff

[Cheryl Lemire]

Re: Refresh Display function not as I thought

Jeff,

I apologize for misunderstanding what you needed. I thought you wanted to run your independent script without closing the form.

You mention when the form closes it goes to the control panel, I understand this to be a normal process if no other forms are open and the control panel is not hidden. When you run a backup, or pack tables, or reindex, etc, all tables and windows need to be closed and focus normally goes to the control panel. You could always ControlPanel.hide() if you don't want it seen.

You could create a dummy form that is blank based on a dummy table, shift focus to that form, close your current form, run your standalone script by pushing the hidden button on the dummy form, close the dummy form, and return to the original form when done.

Not sure if that made sense. Unfortunately, I am not totally sure of what you are trying to accomplish as I cannot determine when in your process you are closing FormA or why.

[Tom Cone Jr]

Re: Refresh Display function not as I thought

Jeff, if you can post a stripped down version of the database, with instructions for us to follow to see the problem (using dummy data if needed) we may be able to suggest solutions. -- tom

[Jeff Fried]

Re: Refresh Display function not as I thought

Tom,

This is difficult to strip down, but I'll try to explain what I'm doing and maybe this will help you help me.

It's a purchase order form for ordering materials with a certain chemical composition, called a chemical spec. Various elements found in the material are given with their minimum and maximum percents. To create a new spec, I am giving the sales people a shorthand way to describe the spec within a memo field. When the memo field is set up to their satisfaction, they press a button on the form that is supposed to magically show header information on the form (spec description, spec number, etc.) and a browse (child table) showing each of the constituent elements with their mins and maxs.

The procedure I run when the button is pressed includes a foxpro executable I set up that has the logic to form the field values for the header and detail. This foxpro routine works properly by depositing the proper values in a temporary header import and detail import table, which I then import via import operations I have set up within Alpha, which run after the exe completes. Everything lands where it should, which I know because I can check these values independently of Alpha, using Foxpro, but the form containing the header and detail tables does not display the data unless I exit, then re-open, the form. I have tried resynch and refresh, but so far they have not done a refresh that equals closing and re-opening. So, as a workaround to achieve the result (where the user presses the button and their screen is updated with a spec created from the memo field), I created an external script that uses a parameter-passing file to retrieve the correct purchase order and item number, then I open the form and arrive back at the same location, showing the data. The problem is, I can't figure out how to run that external script as part of the same process that does everything else, including closing the form. The reason I need to run that external script as part of the same process is to make it seamless for the user. They press the button, and new data appears.

If the refresh had worked the way I thought it would, I would have been there days ago. Now, I'm so close, even without it, but I simply can't trigger that external script to run while is occurs after I close the form that contains the process. I scoured the Xbasic reference manual and the Action Scripting docs but could not find anything addressing the subject of running a script from a script that ends (because the form is closed) before the line that runs the external script is invoked. I have tried placing the external script in the OnExit event of the form, but it does not run. The external script doesn't do much. What it does is 1) set the search key variable from an external table 2) open the form 3) set the proper index 4) find the record 5) go to a certain field on a tab. This works correctly when I run the script, but it doesn't run unless I phycally click it.

I know there must be a way to do this within the power of Xbasic and Alpha, but I just can't find it. I hope this clarifies my problem. If you have any insight to share, please do. Thanks.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

Cheryl,

Yes, I'm trying to close, then re-open, the form as part of the same process. Going to the control panel is not the issue. It does that because I close the form, and that's what shows.

You did trigger something I'm going to try, though, which is to open a dummy form and run my external script from that dummy form.

I'll let you know if this works. A more direct approach (first, seeing refresh or resynch do the job, second, having a way to run the external script within the OnPush sequence of the form button) would be best.

Thanks.

Jeff

[Tom Cone Jr]

Re: Refresh Display function not as I thought

I suggest you create another button and use it to enter dummy data of the type Foxpro is doing, filling the appropriate header and item records. Use this to create a dummy app for us to play with here. We don't need to see the memo parsing routines, or the foxpro data entry routines.

Your sequence resembles what would occur over a LAN if a separate workstation entered a new header record, with a number of related child table item records. Your form should be able to see the newly entered data, but it may have to navigate to it.

What steps are you taking to update the Alplha Five index files for your header and child tables when the Foxpro app populates the records ? If Alpha was doing this on another workstation the indexes would be automatically updated. If your Foxpro sequence is not doing the same thing, or if you're not forcing the index to be rebuilt in Alpha after the foxpro sequence populates the records, that might, possibly, explain what you're getting.

This is speculation which could be endless without a dummy app to see and work with.

-- tom

[Jeff Fried]

Re: Refresh Display function not as I thought

Tom,

I'll try to set up a dummy app, but to answer your question about indexes, I don't believe that Foxpro can reliably be used to update the Alpha indexes, so I don't do that. Rather, I use an Alpha append operation to append the child records to the child table. This keeps the indexes updated (which is verified after I exit, then re-enter, the form).

Jeff

[Tom Cone Jr]

Re: Refresh Display function not as I thought

Jeff, right. As I thought about the problem later I realized that in my previous reply I missed that step.

Once this problem is cleared you may want to do the processing of the memo field text directly in Alpha Five. That would simplify things immensely because you wouldn't have to use the temp table or append op.

-- tom

[Jeff Fried]

Re: Refresh Display function not as I thought

Just to share with you the results of further digging on this problem.

First, a key missing piece to this puzzle was, after closing the form, let's call it FormA, then re-opening the form, I failed to indicate that it should open a new instance of FormA, believing I didn't need to since I already closed the original FormA.

Regardless, I still have some clean-up procedures that don't seem to be working properly, like assigning variables to a key for lookup, and getting the proper index, and setting the insertion point to arrive at my intended destination. I can figure this out later, thought it mystefies why it doesn't just work the way you would expect.

Lastly, in the interest of moving on from this multi-day puzzle, I can temporarily open a new dummy form, as suggested by Cheryl, and place on it a button aptly named "Press to complete" which will run my external script and return the user to the original place on the original form, with all transformations shown -- everything I thought I would achieve with refresh or, as Al suggested, resynch.

You've probably experienced at some point the disproportionate spending of time on solving a relatively minor part of the overall application. This was in that category, but at the point of obsession. I was determined to solve it because the client will love this capability. The "Press to complete" may not seem to the client to be a compromise, but to me it is, so I'm determined to figure this out and make it one fluid step. So close, yet so far.

Thanks, Tom, Cheryl, Al.

Jeff

[Cheryl Lemire]

Re: Refresh Display function not as I thought

Jeff,

If you are going to create the dummy form, when that form loads you can have the button pushed without user intervention as I suggested with my original suggestion.