Refresh Display function not as I thought

[Jeff Fried]

Re: Refresh Display function not as I thought

Cheryl,

I was so excited that this was essentially behind me that I forgot you had mentnioned this. I'll try it, and if it works, I'm home free. Thanks again.

Jeff

[CALocklin]

Re: Refresh Display function not as I thought

Jeff, first, you may need to explain exactly what process you use to accomplish "actions run in the background as part of an external process initiated by a button on the form"? If it's not running in a separate thread (which I rather doubt), then it's not really a background process that is running while you are doing other things on your form.

If this is just a process that runs when you click the button and you want the form to update when the process is done, that's actually fairly easy to accomplish but it's not something most people intuitively do. (I did it wrong for years and it caused me no end of grief.)

The trick is to create a pointer to the already open instance of the table on the form that you want to update and NOT to open a new instance of that table.

If the table is in the current form, you can do that with:

tbl_ptr = parentform:tables:TableName.this
or by using:
tbl_ptr = Table.get("TableName")

If the table is in a different form, use the first method but spell out the form name:
tbl_ptr = FormName:tables:TableName.this

If you update the table using a pointer created by one of these methods, you may not even have to refresh the form. If you do, a simple FormName.refresh_layout() should do the trick.

DO NOT use tbl_prt = table.open("TableName") -- you can use that to update the data in the table but it can be extremely difficult to refresh/resynch an open form to show the new data. (This is what I did for years before I learned to do it right.)

FYI: If you use subforms, "parentform" may not be the main form. In that case, use TopParent instead. Look up either Parentform or TopParent in the Help file for a graphical presentation of how these are used.

[Jeff Fried]

Re: Refresh Display function not as I thought

Cal,

This sounds interesting, and it seems like you've been down the path I am currently experiencing. I'll try to absorb what you said and try this out. It may be the answer I'm looking for. Thanks.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

Cheryl,

I tried your suggestion of placing another button on the originating form which has the objective of executing the external script that completes the operation. It executed, but the result was incorrect, probably because I need to revise how the external script works on the form from which it is called.

Here's what does work. I open another form, the dummy form, which has the button that needs to be pushed. Instead of the user pushing that button, yes, it would be nice to use the push() to make it happen. At that point, however, parentform is not the dummy form, it is the original form. What syntax do you suggest here?

This would be a nice stopgap to achieve the result I'm looking for, but it appears Cal has had experience with the process I'm working on and discovered a solution, which I will study later when I get back on track. Meanwhile, if you have a quick answer to the command I need after opening the dummy form, please let me know. Thanks.

Jeff

[Tom Cone Jr]

Re: Refresh Display function not as I thought

Jeff,

here's an example that illustrates how to update the child table in the current set based form, using a temporary table as data source. As Cal indicates, the trick is to use a pointer to the currently opened instance of the child table. Let us know if you have questions about how this works, since it obviates the necessity for a separate append operation.

Next, reconsider the user of FoxPro to process the memo field text. If you let Alpha Five do the processing the approach could be simplified even further, obviating the necessity for the temp table.

-- tom

[Cheryl Lemire]

Re: Refresh Display function not as I thought

dim frm as p

frm = form.load(dummy_form_name)   

frm:button_name.push()    'push button

frm.resynch()
frm.show()
frm.activate()

I think :)

[Jeff Fried]

Re: Refresh Display function not as I thought

Thanks, Cheryl, I'll try it and let you know.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

Tom,

Thanks for the example. I looked at it and it will help organize my thinking, especially if I move the processing to Alpha from Foxpro.

I agree in principle about shifting over from Foxpro, but for several reasons, I default to using Foxpro for heavy processing (light processing, too). First, I grew up with Foxpro, so I already had this bias. Second, in the Alpha Four days, running a Foxpro routine within A4 enabled things that just could not be done with A4 scripting, or would be done so slowly as to be unacceptable. Third, I always found the Foxpro (dBase earlier) syntax to be very efficient from a development standpoint, and I think it could be argued this way relative to many equivalents in Xbasic. Fourth, early on I tried comparing similar, processing-intensive routines done in Xbasic vs. Foxpro and found Foxpro to complete quicker -- not a large sampling of processes, but nevertheless enough to sway me.

I have sometimes thought, wouldn't it be nice if Alpha Five had the alternative of using Xbasic or Xbase as the development language. I don't see any reason why Alpha should go this way except for the ability to compile Foxpro code and thereby increase performance (though I recall at the DevCon the idea brought up that maybe we will eventually be able to compile an A5 application, but nothing soon). A5 is built on the Foxpro 2.6 model (DOS days), though these days there are later generations of Visual Foxpro. I, like you, love the Alpha Five development environment and wish I had your more extensive grasp of the Xbasic language, which I may get to, but as I said, I always view the Foxpro language as more efficient, love the speed of execution when compiled, and wish it were more tightly integrated with A5 so running a Foxpro routine could keep indexes and memos consistent and stable, just as if Alpha had performed the process. To me, it would be getting the best of both worlds.

Thanks.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

Cheryl,

I tried your revision. It gets close, but I need to work out some pointer issues with my external script to get it exact. I will revisit this later, but for now, since I need to meet with the client this week with a lot more done than this one procedure, I must move on. At least I have a workable solution with the dummy form's button. Thanks.

Jeff

[G Gabriel]

Re: Refresh Display function not as I thought

Is this what you are looking for?

[Jeff Fried]

Re: Refresh Display function not as I thought

Gabriel,

Thank you for your suggestion. It is a nice attempt to translate what I've been talking about into action. I thought I'd share with you some screens related to this operation. It is somewhat more complex than a translation from memo text to field information since it takes a bunch of scenarios into account, such as whether an existing spec will be used, a new spec will be created without eliminating the old, deactivating the old, etc.

First.pdf shows an example of what I've been talking about, the starting point, where someone describes a new spec in the "New spec setup" memo field. This is the case when there is not an existing spec in the library, as I show in third.pdf. Second.pdf shows the result after pressing the "Convert text to spec" button and is the heart of what I've been trying to fine-tune in this thread. I've only been focused on one scenario, the one where no existing spec exists. Fourth.pdf gives you an idea of some of the other scenarios that are covered, as when there is already an existing spec for the line item and it needs to either be replaced or changed, one scenario creating a new spec number, the other retaining the existing spec number but with different specifications.

Thanks for your help.

Jeff

[Tom Cone Jr]

Re: Refresh Display function not as I thought

G,

why password protect the design in your example?

-- tom

[G Gabriel]

Re: Refresh Display function not as I thought

and is the heart of what I've been trying to fine-tune in this thread

My understanding is that the difficulty you are having is in making sure to see all the records in the embedded browse after you broke the memo down into values and passed them to the child table. At least, that's what the title of the thread implies and what all those maneuvers described in the thread suggest.

The example I provided:
a-Breaks down the memo into values and passes them to fields in the child table.
b-Shows those values in the embedded browse.

Isn't this what you are looking for?

[Jeff Fried]

Re: Refresh Display function not as I thought

Gabriel,

Yes, you are correct that I'm trying to create the end result that makes first.pdf go to second.pdf in one step -- just makes it sexier, rather than having an intermediate step (which I didn't show you) of having a screen with a button to click on to complete the operation.

The answer I was originally after is how to refresh the screen after the processing so as to create my desired result. It turned out that refresh didn't do this, then, trying resynch, that didn't work either. I was really trying to solve a simple thing, making the screen refresh the same as if I exited, then re-entered, the form. You know how these things snowball when some very helpful Alpha gurus jump in to assist, but the original idea was, as the caption above says, "Refresh Display function not as I thought". I know what you are suggesting, but I'm not willing to rework the main processing for this in order to get to the one-step transformation I'm after. That would be more like the tail wagging the dog. It was days ago when I first introduced this thread and never thought it would take on the life it has. I appreciate it for it's educational level and thank those who went to the trouble to develop example code to achieve an answer. But I am at a point where my worst case is not so bad (the screen to finalize the operation), and I think when I have time I'll explore some of the ideas that were raised to eliminate even that step.

Right now, my next step is to create the process that does the reverse of the one I've spoken about, namely to take the existing "data" spec and bring it back to the memo field, a client request. I don't see any issues in that.

Thanks.

Jeff

[Jeff Fried]

Re: Refresh Display function not as I thought

Gabriel,

One more thing I forgot to mention. If you look at my first.pdf example (before the process) and the second.pdf (after the process), it wasn't just the browse that needed to be refreshed. It included the fields in the parent form (spec number, spec description, spec type) that were not showing. Basically, after the process completed, I was still left with a screen that looked like first.pdf. Refresh and resynch did nothing to get me to second.pdf. Only exiting and re-entering the form showed me second.pdf. I thought there must be something in Xbasic that could do the equivalent of exiting and re-entering without actually doing so.

Jeff