Problem with Topparent.find(var_key)

[KDM]

I am new to Alpha Five.

I used Topparent.find(var_key) in a form to find and read a record in a table. It managed to find and read the correct record and display its data in the form. Then I used Recno() to check the record number of the current record in the table and discovered that the current record pointer has not been reset to point at the record which has just been read.

How can I reset the current record pointer to point at the record which has just been read ? Thanks in advance.

[aschone]

I will hazard a guess that you are checking the record number from a second instance of the table and not the instance of the table that is opened by the form.

[KDM]

As an example, let's say the table had 500 records. I ran a script to open the form and the current record pointer pointed at record # 501. I tried to read, say, record number 300 and succeeded in doing so. However, the current record pointer still pointed at record # 501.

[aschone]

Let us see the script.

[KDM]

The same thing happened even if I clicked open the form directly.

Allow me to phrase my question in a different way. Are there known bugs with topparent.find(var_key) ?

If I execute topparent.cancel() BEFORE topparent.find(var_key), then topparent.find(var_key) will find the correct record, display its contents and reset the current record pointer to point to that record. If I don't, then it won't reset the current record pointer. Is that how it is supposed to work ?

[Tom Cone Jr]

Need to see the script.

[KDM]

The form has about 20 fields.

The user is expected to input the value of a record key into field # 1 and press <Enter>.

The CanDepart Event of field # 1 contains the following codes :

DIM GLOBAL S_KEY AS c
S_KEY = parentform:Field1.value
DELETE var_key_target
var_key_target = S_KEY
topparent.find(var_key_target)
topparent.allow_change(.t.)

[Tom Cone Jr]

KDM, try this:

S_KEY = parentform:Field1.text

[KDM]

That didn't work.

[Tim Kiebert]

or

maybe S_KEY = this.text

and you might try it in the OnDepart event as well

[Tom Cone Jr]

DIM GLOBAL S_KEY AS c
S_KEY = parentform:Field1.text
'DELETE var_key_target
'var_key_target = S_KEY
parentform.find(S_KEY)
parentform.allow_change(.t.)

The changes in red illustrate how I'd handle this assuming the form is based on a single table.

KDM, if your form is based on a set of tables, or if you're using a subform in your form, these ideas probably won't work, especially if you're searching in a child table. It would help if you showed us the entire script, so we can see the steps that are being followed up to the point you check the record number of the found record. Recommend you zip your database and post it here with instructions for us to follow so that we can trace your steps leading to the problem. This permits us to see the entire script while it's running in context.

[KDM]

I just realized that topparent.find(var_key) did not work because the form was in "ENTER" mode. Topparent.cancel() apparently changed the mode in such a way that topparent.find(var_key) was able to work properly.

Is there another way to change the mode from "ENTER" to "FIND" before executing topparent.find(var_key) ?

[Tom Cone Jr]

I like this approach:

The button script that initiates the find should check the mode of the form and prompt the user to cancel or save pending edits and then end. If the form is not in CHANGE or ENTER mode then the script should proceed to do the find.

[KDM]

I am converting an ancient DOS/clipper program and I am trying to preserve the look-and-feel of the original program. Therefore I am trying to do things that may appear to you to be rather unorthodox.

Having said that, I have no problem with topparent.cancel() except that it displays the data from the record being pointed to by the current record pointer immediately before topparent.find(var_key) finds and displays the data from the record found. As a result, the form appears to blink for maybe one-tenth of a second and I would like to stop that from happening.

Is there any way to stop topparent.cancel() from displaying the data from the record being pointed to by the current record pointer ?

[Tom Cone Jr]

Is there any way to stop topparent.cancel() from displaying the data from the record being pointed to by the current record pointer ?

There are alternatives, depending upon the context in which you are doing this. Are you doing the find as / when the form is opening? I thought you were doing the find when the form was already open, in which case there'd be no blink... the current record would already be on screen. Describe your complete sequence for us.

Are you aware that the message board permits file uploads? This might be one of those cases where attaching a zipped copy of your database would help us help you, provided you also include instructions so that we can find the right form, script / button and run it in the same sequence you're struggling with.

[CALocklin]

Your references to "topparent.cancel()" and the fact that you are "trying to preserve the look-and-feel of the original program" make me wonder - are you perhaps in Enter mode when all this starts? If so, that would be a whole different situation. I would not expect a topparent.find() to work while in either Enter or Change mode.

I also get the impression that you are trying to "look something up in a different record" and are just going to that record to get the info. If that's the case, there is probably a better way to do it.

If you can't upload something for us to work with, please give us the full story of where you are starting from and what you are trying to accomplish. Sometimes a question like, "How do I get the key to turn in my car?" isn't enough. The answer will be completely different if you are trying to start the engine, open the door, or open the trunk. Then, when we find out that you just bought an old Model-T and are trying to start the engine, we will probably suggest other things besides looking for a place to put the key.

[MoGrace]

Cal,
Like where to put the crank? ;)

KDM this is where the script library comes in handy for keeping little snippets of xbasic code that you may want to put in many of your scripts - like testing the form's mode & committing a record first, etc.

[KDM]

You are right. The form is put in ENTER mode when it is opened.

What the form does is accept a record key in field # 1 and then try to read the record if it exists, display its contents and allow the user to change the contents. The user is supposed to enter the value of a record key in field #E 1 and press <Enter>. If the record exists, the contents are displayed and the user can then change the contents. If the record does not exist, the user can proceed to enter new data and save the data as a new record.

I managed to eliminate most of the blinking by using a combination of conditional objects and hide/show objects.

Any better ideas ?

[Tom Cone Jr]

KDM, I think it's asking for trouble to begin a new record just to collect input from the user. There are too many ways the incomplete record will or can be saved. This leads to lots of bad data in your table. A much better approach would be to capture the input using a custom xdialog box, and then let your script validate the input from the user before opening the form and fetching the desired record.

[SNusa]

This oddity occurs in version 10, and probably in version 11 too!

topparent.find(var_key_target) only works when var_key_target value is of type N
~And changing the code to topparent.find(eval(var_key_target)) works even though the record's fields index (the record I'm navigating to) is of type C.

Example:
Auto increment field ("being looked for") is of type character (and displays as 00001, 00002, 00003) in table. (unique index on field is of type C)
Yet you have to pass a numeric value which presumably evals to 2 instead of 00002 in order for the .find method to go to work and go to (find) the correct record on the form.

Note: Without adding the eval(), the debug pops up with error "conflicting data types" The only thing I can think of here is that the .find method is somehow converting all record indexes / fields into some type of numeric representation for searching?

I'm guessing this is not efficient, and there must be another way to specify a specific key to use in the search? I know I could create a query, and filter for the result on the form, but but I want to keep all records available in the record navigation bar. (Kind of like how the super-control dropdown browse can be used to search for / select a particular invoice on a form.)

The only other way (thus far) that I have found is to apply a filter (query) to the form, and immediately afterwards issue the form.show_all() method. ~ Is there a better method without using the super-control?

for example (this is "pseudo-pseudo code", and won't work): topparent.find_by_key(key_name,field_type,key_value)???

[SNusa]

RE:

This oddity occurs in version 10, and probably in version 11 too!

Updated (CORRECTIONS) to my post with explanations (FIX) of my issues trying to use .find() can be found at this link:

http://msgboard.alphasoftware.com/al...numeric-values