Refresh Display function not as I thought

[CALocklin]

Re: Refresh Display function not as I thought

G,

Your method will work. Essentially you are opening the table separately, adding or modifying the records, then rerunning a query on the form. This is also the technique presented by Peter Wayne in his discussion on refreshing browses. (I don't have the exact name or link.)

The query in your example simply filters all records (.T.), however, that may not always be the case and can result in two issues: (1) a noticeable time delay on very large tables - especially if the filter is such that it can't use LQO, and (2) the user has to be able to set up the filter correctly when rebuilding the query. Of course, the function "Current_filter_expression()" can be used but the user has to understand that it's there and how to use it.

As I said earlier, it can be done more easily by NOT opening the table in a separate "session".

In your example, you can change this in the inline xbasic:

t=table.open("metals")
to
t = parentform:tables:metals.this

and delete the line "t.close()" since you can't close the table session for the currently opened form.

Finally, delete the query. It isn't needed.

I know this works. I tested it in your app by updating record 3(?) and a couple others I created myself just to be sure.

[G Gabriel]

Re: Refresh Display function not as I thought

Tom:
I thought the password was removed!

Jeff:

You are asking an age old question, a question that each and every alpha user has asked at some point or another. there is no other issue that generated so many questions, so many suggestions and no answers and for which every one is waiting for v8 to hopefully resolve this issue.

I have used couple of tricks to get around this issue, this is one of them and it is fool-proof. It works each and every time.

You do not need to rework your design, just incorporate this simple step.

Cal:

I just wanted to introduce the general concept. The programmer will need to refine the script to their particular needs.

I found in the latter versions of alpha that detaching the queries is not necessary, but it is not a bad idea.

P.S.: I don't know of Dr Wayne's method and incidentally, I lost the link to "Learning Alpha". Do you have it?

[Tom Cone Jr]

Re: Refresh Display function not as I thought

G.

Search the A5v4 forum for "Browse Challenge", look for thread called something like "Refresh browse challenge" or maybe "Freshen browse challenge".

Dr. Wayne's site is different, and can be found at www.learn alpha.com

-- tom

[G Gabriel]

Re: Refresh Display function not as I thought

Tom:
Thanks for the link.

Cal:

I had to leave so I wrote a quick response, now re-reading your reply: I did use .t. because in this example there is not much to filter for, in real life I use specific queries.

When you think about it, if alpha is to fix this nagging issue, what are they to do? they need to make sure the "Current" index or query is rebuilt after the new entry and the screen will repaint properly. I am not sure where the snag is, but one way or the other you have to rebuild what's in front of you, in essence, running a query of sort or rebuilding an index.

If you wish to improvise, you could save your query.

I mentioned also that I use other tricks that do not involve any queries. One I used for a long time and was able to duplicate among tables, but for some reason could not duplicate it to others and currently researching it to see why that is. But when it works it works.

There are few others but I have not test them long enough to feel comfortable to vouch for them.

Jeff:
The refreshing issue aside, I think the approach you are taking is fraught with major hazards:
To use a memo field as a repository for input data then go back and break these data into it's different elements and then pass these elements to different fields is not the best way to go about doing that. Any mis-step in the part of the user will mean not only entering the wrong data for one field, but for every field that follows.

I think a better approach is to present the user with a simple form based on the child table in which they could enter the data directly and better, have lookup table for the metals. Then save this information and use the technique described above where you will be able to see it immediately.

[Jeff Fried]

Re: Refresh Display function not as I thought

Gabriel,

Fraught with major hazards? Not really.

First, you're suggesting the traditional approach, the standard header and detail setup. The beauty of my memo approach is it becomes a quick way to enter data for specs and assays. We stumbled on it one day when one of the managers wanted to enter in a large number of these, so I told him to freeform enter into a text editor using a simple syntax rule (e.g., symbol,min,max per line). I could easily take that form of input and convert it into a traditional database format.

We then went a step further and wondered how it would work if we simply left a memo field there for entering with the simple syntax rules I suggested. The beauty of the approach is speed and ease of data entry. Believe me, I had never considered using anything but a traditional data entry approach, enabling field rules to trap errors and otherwise keep a formal structure to this. Then, as an offshoot to that data entry exercise in the text editor, we came upon the memo field idea. I've been in the throws of executing the idea, and now it works nicely.

Error trapping is not at all an issue. I accomplish this in code, the very process that takes the memo field data, parses it, and reconstructs it into import files. Worst case, after the user sees the conversion result a split second later, he will know if he messed up. Then, because I have a reverse function to revise the data in the structured database format and then convert it back to the memo field, there is maximum flexibility for the user. The user can, for example, copy and paste a spec to another record as the starting point for setting up a different spec. They love the idea.

As for a lookup table for the metals, not necessary. The people entering these are either entering them from a reference document or know exactly what the element symbols are. I do have a lookup table as part of the process of bringing in the element name based on the element's symbol (for example, Tin's symbol is Sn, but they only need to type in Sn and Tin will appear. If there's no match, that error will be brought out and easily fixed.

Sometimes you have to think outside the box. That's what this is about.

Jeff

[G Gabriel]

Re: Refresh Display function not as I thought

I am not saying it's a bad idea. It just makes me nervous. If the user does not pay close attention, you could have some mishaps. For example, if the user enters:

Sn then entered the min, but forgot to enter the max, then proceeded to enter the second element, then when you parse, you might enter the second element in the field of the max and it goes downhill from there.

So long as you have good error trapping and smart enough users, I guess you will be OK. My philosophy in development is a bit different: my criteria for a good software is if it passes the "Monkey Test" . I develop software with monkeys and baboons in mind. If a monkey could use my software, then it's ready.

[Jeff Fried]

Re: Refresh Display function not as I thought

The people who are going to do this are not in the "monkey" category. I, too, design for the lowest common denominator. In this case, the people who deal with specs and assays know what they are doing, and between that and the error trapping, no issues.

Thanks for the concern.

Jeff

[CALocklin]

Re: Refresh Display function not as I thought

WHY DO I FEEL LIKE EVERYBODY IS MISSING THE POINT???

In case anybody here feels picked upon, this is not the only thread this has happened on. My solution has been ignored before.

"Refreshing the browse" seems to be one of the biggest complaints about Alpha. I had the same complaint. However, I finally discovered that I was doing it wrong and I'd like to get that message across to others.

I solved 99% of my "refresh the browse" issues with one simple change. In the vast majority of the cases, there is NO need to worry about what query is active or refreshing the query. I used to do that and I used to close and re-open forms - but not any more.

The solution is simple. Just start using the table pointer based on the form that needs to be refreshed rather than doing a Table.Open(). That's all there is to it - no need to refresh queries or to close and re-open forms. Try it; you'll like it. At the most, a parentform.refresh_layout() should be all that's needed but most of the time even that isn't necessary.

Gabriel said (and others have said somewhat the same thing) (emphasis added), "if alpha is to fix this nagging issue, what are they to do? they need to make sure the "Current" index or query is rebuilt after the new entry and the screen will repaint properly" but that isn't true. Instead, just do it the correct way.

This solution make perfect sense if you think about it. By using a pointer [to the table] that is based on the form, there is no need to resynch things for the form. However, using Table.Open() creates another "instance" of the table which the form doesn't see and doesn't know what to do with - hence the need to rerun the query or close and re-open the form.

I can't guarantee that this will solve every "refresh the browse" issue but I can guarantee that it has made my life much, much easier. Now, if you prefer doing things the hard way....

[G Gabriel]

Re: Refresh Display function not as I thought

Cal:
It seems that YOU are missing a BIG point here:

YOU DO NOT NEED TO OPEN THE TABLE TO RUN THE QUERY!

You could run the query from planet Mars if you want to. The purpose of table.open() has nothing whatsoever to do with running the querry. It has everything to do with adding the records to the child table, something you CAN NOT do without opening the table. Notice, I closed the table before running the query!

My script does not close or re-open the form either!

I know it's Labor day, but lighten up on the beer & BBQ!

[CALocklin]

Re: Refresh Display function not as I thought

You're either not listening or not understanding what I've been saying. (And I don't think other people have been either.) There is no need to even run the query. Please read EVERYTHING below then try it yourself.

1. You CAN add records, edit records, or delete records using tp = parentform:tables:TableName.this just like you can do it with:
tp = table.open("TableName")
2. Table.Open() has everything to do with it. Using that function is the reason you need to run the query.

The big difference is that you DON'T need to run a query after adding/editing/deleting records IF you use the <form_pointer>:tables... method. Just add a parentform.refresh_layout().

You said,

It has everything to do with adding the records to the child table, something you CANNOT do without opening the table.

That is almost correct BUT you're missing the fact that the table IS already open. It had to be opened in order to show the form. What I'm saying is - don't open it again; just use the 'session' that is currently open. (I'm not sure that 'session' is technically the correct term in this case so don't beat me up on that one - that's why I put it in quotes.)

The attached file is your previous app modified to use my method. (It's smaller because I compacted the data dictionaries after editing it. I didn't change anything but the script.) Try updating record 1 or 3 (record 2 has no info in the main table) and you will see that it works without ever running a query or closing and re-opening the form. (Since you said, "I thought the password was deleted", I also removed the password and the OnActivate script that was hiding the control panel so others can see the solution also.)

[G Gabriel]

Re: Refresh Display function not as I thought

Cal:

I am not sure why you are getting hung up on the issue of opening the table vs using the current session. This has nothing to do with running the query. I said, and say again, I closed the table before running the query, so how is it essential to running the query that the table be opened in another session?!

What I'm saying is - don't open it again

You are beating on a side issue: if you wish to use the current session as opposed to opening (then closing) another instance of the table, that's fine. But for the embedded browse to update, which is the topic of this thread: you need to run the query, period.

There is no need to even run the query.

I opened your zip file, added a new parent record & saved it, pressed the "update" button and I am sorry, but I did not see the newly added records (child records parsed from the memo field) in the embedded browse, which is the goal of this thread!

The difference between what you are saying and what I am saying, is not whether to open another session of the table or use the one that's already open: either way is fine by me. The difference is, you think you do not have to run a query and what I am saying (using this method) you HAVE TO run a query for the embedded browse to update and show the newly added records. You have to.

I think the trouble that alpha engineers are having (this is pure guess on my part), and they are not stupid they could have solved this issue long ago, the trouble is to update the index, alpha needs exclusive access to the table. So it's a catch 22, the form is open, i.e. the table is open and yet the user wants to see the update take place which entails updating the index which the layout is using. Running query gets around that since it does not require exclusive access to the table. This is my guess and a plausible explanation as to why query works.

In your script, simply pointing to the table or adding child records, does not update the view. It does not. Try it.

[Tom Cone Jr]

Re: Refresh Display function not as I thought

G,

In your script, simply pointing to the table or adding child records, does not update the view. It does not. Try it.

The form will update without running any query simply by adding "Parentform.refresh_layout()" to the end of Cal's script. This is often necessary when xbasic scripts manipulate the data in tables supporting a form directly, rather than through the gui.

Xbasic supports writing directly to objects in the form layout as an alternative to writing directly to the table(s) beneath the form layout. Here's how your script could be re-written if one chose to write to the field objects in the layout, in the same way the end user might when entering data through the keyboard:

dim count as n=1
dim mcount as n=w_count(rtf_to_text(Header->INPUT))/3

'form is based on a two table set.  Link is 1:N.
'script assumes presence of a parent table record, and
'assumes no changes are pending to it.

'enter new records directly into the browse object just as 
'though the user were entering them from the keyboard.
for i=1 to mcount
   hdr:browse1.new_record()
   hdr:browse1:metal.text =word(rtf_to_text(Header->INPUT),count)
   hdr:browse1:max.value=val(word(rtf_to_text(Header->INPUT),count+1))
   hdr:browse1:min.value=val(word(rtf_to_text(Header->INPUT),count+2))
   hdr:browse1.commit()
   count = count + 3
   next i

Notice that this approach does not require updating (refreshing) the form layout, nor does it require any query to be run. It simply enters the data into the table "through" the gui.

-- tom

[CALocklin]

Re: Refresh Display function not as I thought

My apologies. I posted the wrong zip file. You will note that the one I posted also did not have the password removed like I said it did.

The correct one (re-verified and restored to the original data just now) is attached for anyone who wants to see the details.

I did test it and it does work without the query. (If I don't test things before posting them on this board, I usually say so in the post.) However, it doesn't always work without the Parentform.Refresh_Layout() and the version I posted didn't have that as the last line - even though I did mention it in my message.

And, thanks for the verification Tom.

[CALocklin]

Re: Refresh Display function not as I thought

Actually, I like Tom's method better for entering/editing data when you only want to work with the data that is visible on the form.

I usually only use the table pointer method when either working with other fields as well (another option is to add the field to the form but make it hidden) or if I want to delete records but not see the built-in Alpha deletion warnings. By deleting the record via xbasic, I can control the warning messages.

Another benefit to using the GUI as Tom suggests is that ALL field rules will be checked. If you edit records through table methods, some field rules are not checked. (On the other hand, sometimes this is useful.)

FYI: I usually disable the user's ability to delete records unless they click my Delete button. That way I can (a) make sure they don't delete something that shouldn't have been allowed to be deleted at all and (b) I can provide better warnings by displaying the info for the record they are about to delete in a verification message without the user getting a second prompt that was generated by Alpha.

[G Gabriel]

Re: Refresh Display function not as I thought

Tom:
Your script produced the following error: see image.

The following will work, but it is very slow compared to my script. This might not be a fair comparison though, my script might slow down with a large number of records. I use it on tables with several thousand records and have not seen and delay at all.


for i=1 to mcount
Topparent:browse1.new_record()
Topparent:browse1:metal.text =word(rtf_to_text(Header->INPUT),count) Topparent:browse1:max.value=val(word(rtf_to_text(Header->INPUT),count+1))
Topparent:browse1:min.value=val(word(rtf_to_text(Header->INPUT),count+2))
Topparent:browse1.commit()
count = count + 3
next i

So, take your pick!