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

TopParent vs. Parentform

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

    TopParent vs. Parentform

    A recent posting by Bill Parker has peaked my curiosity about a question that has come to mind a few times during the past year or two...

    Why do people use TopParent and/or Parentform? Yes, I've read the descriptions. The reason for my question is to improve my, and maybe someone else's, understanding of when to use each of them. What are the relative advantages/disadvantages? Are there specific reasons that some people generally use TopParent while others generally use Parentform?

    My method has been to always use Parentform because it seems to be the most direct link to what I want. I seldom look for data that isn't on the current form and Parentform seems to work whether I push a button that's directly on the main form or one that's on a tabbed form. The only time I use TopParent is if my button is on a sub-form (rare) and I want to access something on the parent of the sub-form.

    #2
    RE: TopParent vs. Parentform

    I never really did get the idea behind aliases. I have preferred to use the object pointer method, since it seems most times I need it for something else anyway. I guess this stems from doing a lot of things from global scripts where aliases won't do much good anyway.

    Tom Lyon

    Comment


      #3
      RE: TopParent vs. Parentform

      Interesting comment, Tom. I always thought of Parentform, etc. as "special pointers". For example, the following (nonsense scripts) both do the same: (assume Menu_main is the current form)

      p = obj( "Menu_main" )
      p:util_btn.push()

      parentform:util_btn.push()

      However, I checked the documentation and found that it says this about Parentform, Topparent, etc. (bold added):

      The relative addressing scheme lets you use aliases for objects and their parent objects.

      So, are these really aliases or pointers?

      Also, I use Parentform in global scripts all the time. I never use direct addressing because of (a) the possibility of having multiple copies open, and (b) during development, if you change a form and test it without saving it first, a direct address won't work but Parentform will. (I generally try to avoid multiple copies but users sometimes do things you never thought of during development.)

      While proof-reading the previous paragraph I began to wonder if there is an issue using TopParent in global scripts? I'll give it a try later and let you know what I find.

      Comment


        #4
        RE: TopParent vs. Parentform

        I hear you on the multiple instances thing. I solved that by creating a global script for loading forms. It first checks for existence of the form and activates that if found. Each button or call to a form passes the name of a form to a global variable, then calls the global script. The downside is that a form can't be opened twice, even if the user needs it.
        A bit of a side note: When I load the form, I also recall the last size/postion that the user had specified as well as logging the process. This enables easier error troubleshooting for me and takes little overhead to accomplish. Multiple users can have different size/position preferences for each form. If a form is already open, the script restores the saved size/position settings for that form.

        I was not aware that an alias could be used from a global script. I have tried this, but obviously I was not using the alias properly.

        Tom Lyon

        Comment


          #5
          RE: TopParent vs. Parentform

          Hi to you both,

          I too have wondered about topparent vs parent and about aliases generally. Like Tom, I have used pointers rather than aliases in global scripts run from form controls because I have assumed that each such script created a new session and did not inherit the context of the calling form.

          I wonder whether some of the remarked on unreliabilty of certain aliases reflects this issue, if indeed it is an issue.

          I hope Ira sees this thread because I seem to remember a posted request from him that scripts inherit the context of the calling object. I am not sure of my recollection but if it is accurate the implication would be that they do not reliably do so at present.

          Bill
          Bill Hanigsberg

          Comment


            #6
            RE: TopParent vs. Parentform

            Yes, I too use a script that checks to see if a form is already open. Unfortunately, some customers still insist on having access to the Control Panel where they can open another copy manually - so ends 'control'.

            I agree that aliases are a pain to use in global scripts. I generally use pointers as well. Therefore, since Parentform seems to work so well, it seems to me that it should really be considered a pointer rather than an alias even though the documentation seems to be calling it an alias. On the other hand, I believe Parentform does not work well in a global function. Maybe the issue there is that the 'pointer' needs to be passed to the function?

            Comment


              #7
              RE: TopParent vs. Parentform

              All aliases, e.g. parentform, are a generic (relative) name for a current object, e.g. myform. Since aliases effectivly point to the desired object, they are just like pointers. I would have said they ARE pointers, but I just did a test putting typeof(parentform) in the watch window of a debug session, and did not get a value. I would have expected a P.

              Some objects are manipulated through either pointers (aliases), e.g. parentform:lastname.value or through direct reference to the object, e.g. :myform:lastname.value. The advantage to using an alias is that if the form name changes from myform to Customer, parentform:lastname.value still works.

              Some objects are manipulated only through pointers, e.g. t=table.open("mytable").

              If a global script is called from a form, then the script can use aliases such as parentform successfully. If that same script is run standalone, it will fail because it now has no idea what parentform refers to. In this case, using myform:lastname.value would work, assuming the form is open.

              I find I always use aliases in order to give my code more portability. If I am trying to figure out a bug in my code, I may use the explicit object name temporarily until I solve my problem.

              One other thing. Notice the first character of :myform:lastname.value. The : says to start at the top of the object tree. You can never put : in front of parentform or topparent. Since they are at the top of the object tree already, there is nothing above them.

              Bill.

              Comment


                #8
                RE: TopParent vs. Parentform

                Bill,
                In theory I know you are right, but here's an example of the alias not working for me in a global function.I have a UDF MODENOW: here's a piece of it.

                function MODENOW as C(GETCODE AS C)
                select
                case getcode = "1"
                MODENOW = :Edit_Policy_Transaction4.mode_get()
                case getcode = "2"
                MODENOW = :Edit_User_Info.mode_get()
                end select
                end function

                On a form I have a calculated field showmode with the expression modenow("1") or "2" etc.This calc field is used to display the mode on the form.I wanted to use the parentform or topparent alias to make it work without referencing the form name. I couldn't.
                John

                Comment


                  #9
                  RE: TopParent vs. Parentform

                  John, I played around with it a bit and confirmed my suspicion, mentioned above, that functions cannot use Parentform - instead, the parentform pointer must be passed to the function.

                  Here's a script I put in a button on a form to test it:
                  ptr = parentform.this
                  res = testit( "1", ptr )
                  ui_msg_box( "RESULT", res )

                  The ".this" is required or an error will be generated. I remember somewhere in the documentation it says that this is the syntax required to get a pointer to the parent form.

                  The "testit" function looks like this: (some is unnecessary but I wanted it to look somewhat like yours.)
                  FUNCTION Testit as C(input as C, formp as P )

                  IF input = "1"
                  Testit = formp.mode_get()
                  ELSE
                  Testit = "NOT FOUND"
                  END IF

                  END FUNCTION

                  Again the advantage of passing the pointer is that you no longer need to worry about customers like mine that open multiple forms thus ending up with multiple possible aliases like "FormName", "FormName1", and "FormName2". (Or, is it "FormNam1" and "FormNam2". Who knows? Using my method, I don't care.)

                  Comment


                    #10
                    RE: TopParent vs. Parentform

                    Cal,
                    Thanks.Staying with the function I previously posted, I did the following and it works:

                    In the oninit form event I put:
                    dim shared formpointer as p
                    formpointer = parentform.this

                    The global function modenow code:
                    function MODENOW as C()
                    dim shared formpointer as p
                    modenow = formpointer.mode_get()
                    end function

                    The calculated field "showmode" on the form uses the expression: modenow(). It properly displays the mode of the form as it changes. Not having to reference a form name certainly made it more flexible.

                    John

                    Comment


                      #11
                      RE: TopParent vs. Parentform

                      Perhaps everyone but me already knew this but I just verified that a toolbar item can run a script which uses an alias to the current form.

                      I created a form with a single button. I created a custom toolbar with an item to run a script "push_button" which consisted of the code
                      this:Button1.Push()
                      where "this" should refer to the form to which the toolbar is attached.

                      I am happy to report that it works perfectly.

                      Bill
                      Bill Hanigsberg

                      Comment


                        #12
                        RE: TopParent vs. Parentform

                        Bill,
                        "I am happy to report that it works perfectly."
                        I think you'll even be happier if it works perfectly every time.
                        John

                        Comment


                          #13
                          RE: TopParent vs. Parentform

                          Hi John,

                          Are you suggesting that it may not? My demo of this was very very simple.

                          In practice, I have never gone this way in a real application and have used pointers instead.

                          I continue to fear that I do not fully comprehend A5's behavior in this area.

                          Bill
                          Bill Hanigsberg

                          Comment


                            #14
                            RE: TopParent vs. Parentform

                            Bill,
                            Nor do I.What I meant was that there is always some kind of combination of objects, variables etc that can make something behave strangely. Bill Warner had a recent situation on the board that is an example of that.Wasn't suggesting that once you got it working it wouldn't continue that way.
                            John

                            Comment


                              #15
                              RE: TopParent vs. Parentform

                              Bill, John, Cal, Tom et al.

                              I'm doing this from memory, so don't take this for gospel, however, this is what I recall.

                              Although I am not sure why it evolved this way, Toolbars and menus (which are sort of attached to a form or browse (and perhaps if only opened by form as opposed to a separate open) inherit the context of the parent form. This means that a script of one of their items inherits the aliases that underly them. However, if an item has a script run or function within it, I believe it will not continue the inheritance in these sub-uses

                              One way for a global script or function to get the context of it's call is to pass a pointer, another way is to use A_FORM_CURRENT and build a pointer to use in lieu of parentform(or a prefix to use whereever needed to specify the objects). Sometimes, for reasons I can't ascertain, A_FORM_CURRENT is blank. It may have something to do with not reopening a form after editting it, but I've never been able to track this down. I generally handle it as an error if it returns blank in a function.

                              A browse can use parent and top parent, but I believe it has problem with parentform (why this stuff is not consistent is one of the more annoying aspects of A5 to me - but hey, you have to take the bad with the good.) Also, if you use F8 or the buttons to switch to the browse/form, I believe that it sorts of inherits the parent of the originally opened layout, not the one you are on (meaning it has a bug in changing the context). I believe there is no way to tell if the current display is browse or a form, so your code can't differentiate the context switch either without putting in other layout variables so that youir code can try to sort it out.

                              As Cal surmized, Topparent goes all way to the top item, rather than just the current form of the object, which is what parentform does. Many times these are the same, but for subforms it would not be.

                              If an object is not fully specified, it first looks for an object below the level it is on. If it doesn't find one, I believe it starts looking at higher levels and searching down there for an object by the same name. Thus, it is possible to access you were not expecting if you use the same object names for objects in different places of the whole form. This means that if you have objects of the same name (e.g. on different subforms), it's possible to access the wrong object potentially. Specifying the complete object path, either explicitly, with pointers, or using aliases, can prevent this.

                              I did ask Selwyn if future versions could have scripts and functions properly inherit the characteristics of the calling object in this regards in all areas. I don't know if this has been done for Version 5, so I just continue to use the A_FORM_CURRENT method I described before for now. I'd like to always have pointers to the parent object (menu, toolbar, form, browse etc), top parent, The calling script or function name, the current script or function name (useful for generic error message handlers). I'd like all objects to return their type properly (e.g. reports, letters do not tell you what they are if you get their class) I WANT THE WORLD OF INFORMATION!!! :?)

                              I hope this, possible not totally correct as outlined, dissertaion gives you a clue as to what is happening.

                              Regards,

                              Ira J. Perlow
                              Computer Systems Design & Associates
                              [email protected]
                              Regards,

                              Ira J. Perlow
                              Computer Systems Design


                              CSDA A5 Products
                              New - Free CSDA DiagInfo - v1.39, 30 Apr 2013
                              CSDA Barcode Functions

                              CSDA Code Utility
                              CSDA Screen Capture


                              Comment

                              Working...
                              X