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

BUG? Deleting last child offers prior Parent's-Child records for deletion in Browse.

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

  • BUG? Deleting last child offers prior Parent's-Child records for deletion in Browse.

    Hello,
    In the attached Parent 1:M Child example, with the parent record fixed in view, deleting all the records in a many Child table viewed through a child browse, the program progressed to the prior Parent's Child records after all the child records are deleted, and display the prior Parent's Childs records with the ability to delete, changed, etc. these records. I believe this a MAJOR bug. It happens in v7 and v8. Could someone please confirm.

    The actions I found most consistently exemplary are these:
    Try this. It doesn’t happen every time but try it, play with it.
    1. Open database.
    2. Open Manage Form
    3. Press LastRecord button on the form.
    4. Delete all the Training records of the last Staff record with the Remove button and after removing the last child record, watch it move into the prior parent's child records while the parent still shows the last parent, (check emplid) and watch yourself be able to delete the prior parent's child records. EOF function issue??
    5. Work in the last record. Add a new person and then delete all the records in the Child. More times than not after deleting all the child records, the Browse displays the prior Parent Child records and available to be deleted.

    Please confirm, comment. Same in v7 and v8. Thank you.


    Is this known? an oddity of this application?
    Last edited by Mike Wilson; 02-06-2007, 12:35 AM. Reason: typo
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

  • #2
    Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

    Hi Mike,

    I use A5V5 and it happens there as well.

    A "fix" for this which may help lead to an answer I would think as to why it happens is to add the following script to the Remove button's OnPush event in lieu of what is there currently which is just topparent:browse1.new_record():

    Code:
       dim t as p
       t=table.current(2)
    
       if .not. table.fetch_eof() then
           topparent:browse1.new_record()
       else
           topparent:browse1.fetch_last()
       end if


    Mike
    Mike
    __________________________________________
    It is only when we forget all our learning that we begin to know.
    It's not what you look at that matters, it's what you see.
    Henry David Thoreau
    __________________________________________



    Comment


    • #3
      Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

      Mike W.,

      I see the same behavior and recommend you submit a bug report using the Send a Bug Report utility in A5v8's help menu.

      You are deleting records in the embedded browse object. The problem seems to be occurring because of the interaction between the properties you specified for that object and the behavior of Alpha Five when it deletes a record.

      When the delete occurrs Alpha Five moves the record pointer to the "next" record. If there is no "next" record because you're at the end of the file, Alpha Five begins a new record. Here, your embedded browse object has been restricted against "Enter Records". You specified in the design of the layout that the user cannot enter records through the browse object. Yet, when the last child table record is deleted Alpha wants to begin a new record... hence, the conflict. You can prove this by removing the restriction against "enter records" for the browse object.

      I think this should have been handled by Alpha Five, so I recommend you submit a bug report.

      If you add a "Refresh Display" action to your Remove Record button script the problem goes away even if you leave the restriction against "Enter Records" in place. This action is in the Form/Browse category of action scripts.

      -- tom

      Comment


      • #4
        Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

        Mike, Tom,
        Thanks. I will send this in as a Bug report.
        Mike W
        __________________________
        "I rebel in at least small things to express to the world that I have not completely surrendered"

        Comment


        • #5
          Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

          This has been tracked down - the browse repopulate logic fails to resynch to the current record, and subsequently attempts to find a valid record by fetching the prior record, and then the next record (i.e. when the current record goes away, we attempt to keep its sibling records in view) - however, deleting the last record of a empty browse was failing, so it reverted to the last known good record.

          Now if It appears that the last record in the browse view is going away, we attempt to reposition ourselves at the end of the current browse contexts' data - and if no records exist, we clear the record cache. This fixes the problem you are describing, and will be available in the next build.

          Comment


          • #6
            Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

            I was able to replicate the error. This seems like the "Perfect Storm" scenario. Tom did a good dissection and description of the problem. Good to know it's been fixed.

            Comment


            • #7
              Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

              Originally posted by Tom Cone Jr View Post
              Mike W.,
              If you add a "Refresh Display" action to your Remove Record button script the problem goes away even if you leave the restriction against "Enter Records" in place. This action is in the Form/Browse category of action scripts.
              Tom,
              Nice analysis! Gave Cian and team a good start. For completeness sake, the action of "Refresh Display" does not work in this situation because it fires first, changes the pointer to the first record, and it is then always the first record deleted. However, Object Refresh does work.

              MikeC,
              I tried three ways to Sunday to get your idea to work, and although I would have thought it should, in some iteration, this amateur's hands couldn't get there. As described, it is not recognizing eof(). 'nuf said.

              Cian,
              Good work! I look forward to seeing/testing it. Thank you.
              Mike W
              __________________________
              "I rebel in at least small things to express to the world that I have not completely surrendered"

              Comment


              • #8
                Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                Mike,

                :o sorry about wasting your time with my erroneous script! The line in red should have been topparent:browse1.delete_record().


                Code:
                dim t as p
                   t=table.current(2)
                
                   if .not. table.fetch_eof() then
                       topparent:browse1.new_record()
                   else
                       topparent:browse1.fetch_last()
                   end if

                But..went back into it and for some reason it stopped working for me as well.

                Added what Tom had suggested replacing the "topparent:browse1.fetch_last()" with "topparent.refresh_layout()" and works. So a combination of my script and Tom's suggested function works. An alternative to your much simpler ".refresh_object()" that also works.


                Mike
                Mike
                __________________________________________
                It is only when we forget all our learning that we begin to know.
                It's not what you look at that matters, it's what you see.
                Henry David Thoreau
                __________________________________________



                Comment


                • #9
                  Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                  Originally posted by Cian Chambliss View Post
                  This has been tracked down - the browse repopulate logic fails to resynch to the current record, and subsequently attempts to find a valid record by fetching the prior record, and then the next record (i.e. when the current record goes away, we attempt to keep its sibling records in view) - however, deleting the last record of a empty browse was failing, so it reverted to the last known good record.

                  Now if It appears that the last record in the browse view is going away, we attempt to reposition ourselves at the end of the current browse contexts' data - and if no records exist, we clear the record cache. This fixes the problem you are describing, and will be available in the next build.
                  I am having a similar problem in v7. I have an embedded browse. When I delete the last record in the browse using delete_record() and then try adding a new record using new_record() the parent record reverts to a previous record. Is there a work around that I can use for v7? I have attached my app.

                  To re-create my problem do the following:

                  1. Open the form called Main
                  2. Click on the tab labeled Order Confirmation
                  3. Select the record with 6004 in the OconfirmID field (1st field in the browse)
                  4. Click on Edit (this should open a form)
                  5. Click on the tab labeled Piece Breakdown
                  6. Click the Add button
                  7. Click the Delete button, then click Yes
                  8. Click the Add button again

                  This should revert the parent record back to 6000 and the embedded browse freaks out.

                  Is this the same problem? or am I doing something else wrong? Please help! Thanks.

                  Comment


                  • #10
                    Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                    I tried the example with the latest build, and the browse reverts to the first record when the Add button is pressed (which is correct given that the last line of the add button script is a .fetch_first() command).

                    The browse looks ok on my end (I was unable to exit this form - but I assumed it was due to some canExit event).

                    Comment


                    • #11
                      Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                      Originally posted by Cian Chambliss View Post
                      I tried the example with the latest build, and the browse reverts to the first record when the Add button is pressed (which is correct given that the last line of the add button script is a .fetch_first() command).

                      The browse looks ok on my end (I was unable to exit this form - but I assumed it was due to some canExit event).

                      Cian,

                      Thanks for looking at my problem. Did you click the add button on the "Billing Info" (the first tab) or on the "Piece Breakdown" (the last tab) tab?

                      The .fetch_first() command is the last command in the Add button on the "Billing Info" tab. My problem seems to be on the "Piece Breakdown" tab.

                      I did find that by putting topparent.change_mode() at the end of the script attached to the delete button on the "Piece Breakdown" tab seems to fix the problem. Although, I really don't fully understand why that fixes it.

                      After re-reading my initial post I realize I wasn't completely clear... The problem occurs when you delete the last (final) record from the browse.

                      Thanks again!

                      Comment


                      • #12
                        Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                        Originally posted by Jeff@Listbrokers View Post
                        To re-create my problem do the following:

                        1. Open the form called Main
                        2. Click on the tab labeled Order Confirmation
                        3. Select the record with 6004 in the OconfirmID field (1st field in the browse)
                        4. Click on Edit (this should open a form)
                        5. Click on the tab labeled Piece Breakdown
                        6. Click the Add button
                        7. Click the Delete button, then click Yes
                        8. Click the Add button again

                        This should revert the parent record back to 6000 and the embedded browse freaks out.

                        Is this the same problem? or am I doing something else wrong? Please help! Thanks.
                        Jeffry,
                        I recommend you download a copy of what you posted and try following your directions. Can't. First the 6004 record is not the first record in the browse. Second, there is no delete button (step 7). Third, whatever your scripting is is not Kosher because there is no way to cancel and leave the form. There is no form close, escape or exit method and to exit the form, I had to Ctrl-Alt-Del. Also, I remember writing the font color progression on this with Tim Keibert, and you have the conditions for editing messed up because if you wished to keep the first color and edit the second color, the lookup is blank, and if all you wished to do is edit the second color, you get locked in the form because you must have some conditions and lock downs misaligned.

                        That said, whatever you have going on is not the same as the bug related in this thread.
                        Mike W
                        __________________________
                        "I rebel in at least small things to express to the world that I have not completely surrendered"

                        Comment


                        • #13
                          Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                          Originally posted by Mike Wilson View Post
                          Jeffry,
                          I recommend you download a copy of what you posted and try following your directions. Can't. First the 6004 record is not the first record in the browse. Second, there is no delete button (step 7). Third, whatever your scripting is is not Kosher because there is no way to cancel and leave the form. There is no form close, escape or exit method and to exit the form, I had to Ctrl-Alt-Del. Also, I remember writing the font color progression on this with Tim Keibert, and you have the conditions for editing messed up because if you wished to keep the first color and edit the second color, the lookup is blank, and if all you wished to do is edit the second color, you get locked in the form because you must have some conditions and lock downs misaligned.

                          That said, whatever you have going on is not the same as the bug related in this thread.

                          Mike,
                          If you look back at my instructions you'll see that I said
                          3. Select the record with 6004 in the OconfirmID field (1st field in the browse)
                          Not the first record.

                          The second issue you raise is indeed my mistake... I believe you're talking about step 7.
                          It is supposed to be
                          7. Click the Remove button, then click Yes
                          My apologies...

                          The third issue you raise,
                          Also, I remember writing the font color progression on this with Tim Keibert, and you have the conditions for editing messed up because if you wished to keep the first color and edit the second color, the lookup is blank, and if all you wished to do is edit the second color, you get locked in the form because you must have some conditions and lock downs misaligned.
                          I'm not using a lookup on the colors. I took a slightly different approach from what you guys suggested. I call a funtion from each dropdown box's OnArrive() Event. Here's the function:

                          Code:
                          FUNCTION SetInkColors AS V (form as C, field as C)
                             DIM pObj as P
                             DIM fld as C
                             DIM arrayFld as C
                             DIM color[20] as C
                           
                             ' Build a string containing the field name.
                             fld = ":"+form+":"+field
                             pObj = eval(fld+".this")
                             ' Same as fld but doesn't include the last character of the field name.
                             arrayFld = substr(fld, 1, len(fld)-1) 
                           
                           
                             ' Initalize the color array with all of the possible color choices.
                             color.initialize(<<%list%
                          Yellow
                          Autumn Orange
                          Red 185
                          Flag Red
                          Rubine
                          Burgundy
                          Rhodamine
                          Purple
                          Violet
                          Reflex Blue
                          Turquoise
                          Process Blue
                          Medium Blue
                          Sunlight Green
                          Green 347
                          Green 357
                          Irish Green
                          Dark Brown
                          Gold
                          %list%)
                           
                                ' Loop through the comboboxes and remove all colors that have 
                                ' already been selected from the five color fields on the form.
                                FOR i = 1 TO 3 STEP +1
                                   color.delete(color.find(strip_trailing_char(eval(arrayFld+alltrim(st(i))+".value"),crlf())),1)
                                NEXT
                                ' Return a CR-LF string of the colors left in the original array.
                                pObj.settings.dynamic_list = color.dump("R")
                          END FUNCTION
                          I have notice that when clicking on the dropdown box's arrow it doesn't populate the box. You have to click in the actual text area of the box and then click the dropdown arrow. Not sure how to fix that.

                          Sorry about the lack of a close button on my form. There is a global variable that gets set by the main form and later gets changed by the "edit", "add", and "remove" buttons on the form in question. The state of this variable determines whether or not the save button in the bottom left corner will actually close the form. I started to implement it but ran into this other problem so it's not working correctly... Again, my apologies.

                          That being said, were you able to recreate what it was that I was talking about?

                          Comment


                          • #14
                            Re: BUG? Deleting last child offers prior Parent's-Child records for deletion in Brow

                            Jeff,
                            No I could not. You have so much going on there I can't sort it out. And it started throwing tablecount errors, incorrect data type. Do this.

                            Follow your directions and add a record. Then save and exit, come back in and press Add button, and then Edit button, and then Cancel button. The prompt for Remove record comes up. You've got stuff out of synch, and your script is a bit too complex for me to guess at what you are trying to do. I might recommend that if you are going to assign different tasks to a button under various conditions, like in your OConfirm_remove function, you might want to segregate the scripting so the assignments for functionality is together and then easier to capture the functionality under the set conditions:



                            if <the conditions are so the button should be "Remove" > then
                            GOTO BTNREMOVE
                            else
                            <the conditions exist for the button to be "Cancel" > then
                            GOTO BTNCANCEL
                            end if

                            BTNREMOVE:
                            ... do all the things for the button for REMOVE
                            GOTO COMPLETE
                            BTNCANCEL:
                            ... do all the things for the button for CANCEL
                            GOTO COMPLETE

                            COMPLETE:
                            ........ DO ALL THE THINGS IN COMMON

                            Continued...Good luck!
                            Last edited by Mike Wilson; 03-14-2007, 06:07 PM. Reason: accidently posted before complete
                            Mike W
                            __________________________
                            "I rebel in at least small things to express to the world that I have not completely surrendered"

                            Comment

                            Working...
                            X