Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Keeping record pointers on target

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    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
    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

    Comment


      #3
      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.

      Comment


        #4
        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

        Comment


          #5
          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.

          Comment


            #6
            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

            Comment


              #7
              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.

              Comment


                #8
                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.
                Peter
                AlphaBase Solutions, LLC

                [email protected]
                https://www.alphabasesolutions.com


                Comment


                  #9
                  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!

                  Comment


                    #10
                    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.

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        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...

                        Comment


                          #13
                          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))


                          Comment


                            #14
                            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

                            Comment


                              #15
                              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

                              Comment

                              Working...
                              X