Alpha Video Training
Results 1 to 16 of 16

Thread: Keeping record pointers on target

  1. #1
    Member
    Real Name
    Stephen Williams
    Join Date
    Apr 2000
    Location
    Oakland, CA
    Posts
    930

    Default Keeping record pointers on target

    I am working on a form based on a set with one to many relationships.
    JOB
    ==>TASK
    ...==>PUNCHLIST
    I have an embedded browse of the PUNCHLIST table.

    When I save a GRANDCHILD record (either after entering or editing) the form resets to look at the first CHILD record, thereby hiding the data I just added-edited. It is very disconcerting, and not intuitive.

    What do others do to keep the record pointers pointing where you are working?

  2. #2
    Jeff Moses
    Guest

    Default RE: Keeping record pointers on target

    Steve, Not sure what is happening in your system but you could invert the record order Z to A in the probem browse and that way even if your browse does revert to the first record it will actually be the last one entered. Might work until you figure out a better solution.
    Jeff

  3. #3
    Member
    Real Name
    Stephen Williams
    Join Date
    Apr 2000
    Location
    Oakland, CA
    Posts
    930

    Default RE: Keeping record pointers on target

    JOB 1.(Develop Database Application)
    ==>TASK 1.(Add Scheduling module)
    ........2.Add Punch list system)PUNCHLIST 1. Add Punch list to Schedule set
    ................2. Add browse to Estimate form
    ................3. Ask Alpha Forum how to keep browse record pointer on target.

    Jeff -
    In the above set, if I edit PUNCHLIST 3. to "Ask Jeff how to keep record pointer on target", then save the record, the form will reset so I am staring at the Punchlist of items for the Task 1. record. I never touched the Task list - just edited the punch list.

    Maybe I will make a dummy database and post it to play with. But I am NOT the first to have to deal with this, and thought I would try to save myself some time.

  4. #4
    "Certified" Alphaholic
    Real Name
    Tom Cone Jr
    Join Date
    Apr 2000
    Location
    Florida
    Posts
    23,312

    Default RE: Keeping record pointers on target

    Stephen, this is a good topic. I'll be watching with interest.

    In my own work I try to keep it simple by avoiding data entry into such a complex form. A button push will open a second form, using a script to pass necessary values to it. The user can play there as long as they want, and then when the form is closed, they are returned back to the original form. The second form is based on the grandchild table only. This may not work for others, but has worked pretty well for me.

    I started thinking along these lines after reading an article Dr. Wayne posted at his web site recommending simpler data entry structures. I think the article was called Simplifying Your Application, or something close to that.

    -- tom

  5. #5
    Member
    Real Name
    Stephen Williams
    Join Date
    Apr 2000
    Location
    Oakland, CA
    Posts
    930

    Default RE: Keeping record pointers on target

    Tom and Jeff -
    I just made a little set to play - and the default form doesn't behave the same way. It must be a result of filtering, indexing or some such. I will play around till I either eliminate it in one or create it in the other...
    It might be a few days before I get back - I have paying business to attend to.

  6. #6
    Former Alpha Employee JerryBrightbill's Avatar
    Real Name
    Jerry Brightbill
    Join Date
    Apr 2000
    Posts
    5,173

    Default RE: Keeping record pointers on target

    Stephen,
    Just a thought, but do you have a resynch() anywhere on an event? My memory is a little fuzzy, but I once ran into a problem with a browse showing the wrong child records after a resynch(). I have since avoided using it unless there is no other method possible.

    Jerry

  7. #7
    Member
    Real Name
    Jack Wheeler
    Join Date
    Apr 2000
    Posts
    570

    Default RE: Keeping record pointers on target

    Stephan, simply create a small script that saves the record number and at the very end use the browse78.find(recNO). ALWAYS Works for me. I by the way use the invert(date) or recordno to keep the newest record at the top of a congested browse.

  8. #8
    Volunteer Moderator Peter.Greulich's Avatar
    Real Name
    Peter Greulich
    Join Date
    Apr 2000
    Location
    Boston, MA
    Posts
    11,649

    Default RE: Keeping record pointers on target

    I have sets where I pop up a dialog to enter data into the child. Closing the dialog saves the record, but when the user returns to the read-only set, the child pointer reverts to the first record. This is true even when one tries to force a fetch on the new child based upon the child record no. It seems that the fetch and resynch/refresh, etc. don't execute properly at the tail end of the dialog script. Manual F5 key shows the new child record, but not a sys_send_key("{F5}") in the script.

  9. #9
    Member
    Real Name
    Stephen Williams
    Join Date
    Apr 2000
    Location
    Oakland, CA
    Posts
    930

    Default RE: Keeping record pointers on target

    Jerry
    dollars to donuts you have it. I have a number of resynchs. I might try refreshing individual objects. But first I will pull the resynchs and see if that settles it down. Thanks for the idea.

    Also - Peter - I use the sys_send({F5}) at times. It's not very reliable for me either. And Jack - I am using xbasic queries a bunch on another related form. I use them to filter the schedule by crew and sort the browse by job. I will probably do something like this on the punch lists as I get them into action and see how I want them to work.

    Again - thank you. This board is a phenominal resource!

  10. #10
    Member
    Real Name
    Jack Wheeler
    Join Date
    Apr 2000
    Posts
    570

    Default RE: Keeping record pointers on target

    Im sorry I wrote browse78.find(recno) this should be find the current index (usually the exact link with date in the formula) let us know if this is troublesome to understand.

  11. #11
    "Certified" Alphaholic
    Real Name
    JohnZaleski
    Join Date
    Oct 2000
    Posts
    1,736

    Default RE: Keeping record pointers on target

    I didn't quite understand Jack,s second message so I might be saying the same thing in a different way.

    Here's how I've done this type of thing. You have to do a find ( as Jack said ) or a locate_next in a child browse, I don't think the child record number will ever get you there. It's not a bad idea to always have a unique value on a child record. I do it with field rules that generate line numbers, but you could have an autoincrement field rule on the child record number also ( only used for uniqueness ). Make sure that the unique field is in the child browse so you can save that value to a variable when entering the grandchild browse and do a browse1.find or a browse1.locate_next to reposition the child record to the unique value.

  12. #12
    Member
    Real Name
    Stephen Williams
    Join Date
    Apr 2000
    Location
    Oakland, CA
    Posts
    930

    Default RE: Keeping record pointers on target

    This is interesting. Alpha Five is SO powerful, and all these machinations which are not necessary on the simple default forms with no refinements, and were the only way with basic and dBaseIII, end up being the last resort. Most of my tables have date fields for "Entered" and "Changed". Now I am going to add my own record counters. I could add a user id also. The code overhead certainly hefts up! But hey, it works! Nothing succeeds like success!

    There is a most excellent "White Paper" in here. The topic is "Maintenance of Data and its Integrity beyond Field Rules". or something like that...

  13. #13
    Member
    Real Name
    Jack Wheeler
    Join Date
    Apr 2000
    Posts
    570

    Default RE: Keeping record pointers on target

    Hey John, I don't think you need a separate field since you have the recno(). You can fetch_find(recno()) or you can fetch_first or fetch_last or fetch_previous. However it is far easier to use the current index (linking fields) as the filter.

    Set consist of Parent = Teachers (room + Grade)
    Child = Notes (room + Grade + invert(cdate(date))

    form has browse for notes. Since we want the first record in a browse to be the last record in the notes database (we have hundreds of notes and are only concerned with the most recent 10 entries) Here is the code for onpush event of a button: NEW NOTES 'users enjoy separate fields located on a form to enter data directly. They find browse data entry as combersome. The for I have to enter the linking fields with xbasic to keep the new record properly linked'

    BROWSE1.new_record()
    dim dat as d
    if parentform:day.text="Thursday" then
    select
    case dow(date())=1
    browse1:date.value=date()-3
    case dow(date())=7
    browse1:date.value=date()-2
    case dow(date())=6
    dat=date()-1
    case dow(date())=5
    dat=date()
    case dow(date())=4
    dat=date()-6
    case dow(date())=3
    dat=date()-5
    case dow(date())=2
    dat=date()-4
    end select
    elseif Parentform:day.text="Tuesday"
    select
    case dow(date())=1
    dat=date()-5
    case dow(date())=7
    dat=date()-4
    case dow(date())=6
    dat=date()-3
    case dow(date())=5
    dat=date()-2
    case dow(date())=4
    dat=date()-1
    case dow(date())=3
    dat=date()
    case dow(date())=2
    dat=date()-6
    end select
    else
    dat=date()
    end if
    browse1:date.value=dat
    browse1:teacher.text=parentform:teacher.text
    Browse1:room.text=parentform:room.text
    browse1.Commit()
    :Garden_Main:Date.Activate()
    browse1.find(parentform:teacher.text+parentform:room.text+cdate(dat))



  14. #14
    "Certified" Alphaholic
    Real Name
    JohnZaleski
    Join Date
    Oct 2000
    Posts
    1,736

    Default RE: Keeping record pointers on target

    Jack,

    I know that you can fetch a record number for the parent in a an embedded browse, but I had no luck fetching a child by record number in an embedded browse and putting focus on it in the browse. Have you??

    I too rarely use a browse for date entry. My reason for suggesting a unique field in each child record was that you could easily save a single field value in a child record t as a pointer and get back to it with some kind of "find" in the child browse. I think it's easier than concatenating more and more fields in order to save a unique element in order to refocus a child browse to a specific record.

    By the way, thanks again for the example of smart fields you recntly posted on the board.

    John

  15. #15
    Member
    Real Name
    Jack Wheeler
    Join Date
    Apr 2000
    Posts
    570

    Default RE: Keeping record pointers on target

    You can activate a record with parentform:browse1:date.activate() Is this not working for you. The point of my additions to the discussion is that alpha has already done the work for you all you have to do is figure out what they have done. Once you understand how alpha links records you will be able to easily keep the associated records within focus and view the last record you entered. If you give me your problem as a download I will work on it and send it back

  16. #16
    "Certified" Alphaholic
    Real Name
    JohnZaleski
    Join Date
    Oct 2000
    Posts
    1,736

    Default RE: Keeping record pointers on target

    Jack,
    The light went on, thanks. I see exactly what you mean. I recently did some stuff allowing the user to resequence the order of some line items in an embedded child browse with clicks and doubleclicks. In order to get back to a particular record in the browse after resequencing I used a browse.locate_next. It was impossible, for me that is, to do any resetting in the browse using the child record number. It's nice to know that I could do a browse.find() with a variable matching the set link.
    John

Similar Threads

  1. Target Page and GridLinker problem
    By Brett in forum Web Application Server v6
    Replies: 3
    Last Post: 07-06-2005, 07:12 AM
  2. response.redirect w/ target
    By Steve Wood in forum Web Application Server v6
    Replies: 5
    Last Post: 10-08-2004, 06:01 PM
  3. forms and record pointers
    By geoff m in forum Alpha Five Version 5
    Replies: 6
    Last Post: 06-15-2004, 02:53 AM
  4. Keeping Current Record Values
    By forskare in forum Alpha Five Version 4
    Replies: 3
    Last Post: 07-15-2002, 06:37 AM
  5. Is this “record = target.recno()”safe on network?
    By Daniel Weiss in forum Alpha Five Version 4
    Replies: 1
    Last Post: 08-15-2001, 12:41 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •