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

Question - variable scope between forms

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

    Question - variable scope between forms

    If a form's object event runs a script (ie: a button on_click event), and that script opens a second form using:

    1.) script_play_local()
    Are pre-existing local variables available to this newly opened form?

    2.) script_play()
    Are pre-existing session variables available to this newly opened form?

    I'm thinking only global variables are visible to the second form.
    Robert T. ~ "I enjoy manipulating data... just not my data."
    It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
    RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

    #2
    Re: Question - variable scope between forms

    Hi Robert,

    Originally posted by SNusa View Post
    If a form's object event runs a script (ie: a button on_click event), and that script opens a second form using:

    1.) script_play_local()
    Are pre-existing local variables available to this newly opened form?

    2.) script_play()
    Are pre-existing session variables available to this newly opened form?

    I'm thinking only global variables are visible to the second form.
    Script_play_local() allows access to the local variables (as well as the session (same as shared) and other variables that were available before that line.

    Script_play allows access to the session variables and other variables that were available before that line.

    BUT, when you start a form or other layout, in most (if not all) cases, you are starting a new session (synonomous with the word thread), which has it's own shared and local spaces. There are a few other things that implicitly or explicitly open new sessions (typically indicated by a new modeless window within Alpha Five), so when that code runs, the variable spaces don't follow into that window.
    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


      #3
      Re: Question - variable scope between forms

      Wouldn't the use of global variables solve the problem?????
      D

      Comment


        #4
        Re: Question - variable scope between forms

        Originally posted by SNusa View Post
        I'm thinking only global variables are visible to the second form.
        If both forms are based on the same table, then shared variables will be visible to both. If based on 2 different tables, then you need global.

        The other 2 functions you referenced make the local variables dim'd in the original script (or function) visible to the calling script. It's a long winded way if your only goal is to make variables visible to both forms. If you use any of these 2 functions, then you have to save these scripts in the library (give them names) then call them with these functions in the second form!

        Just dim the variables shared or global. These function serve a purpose, but in this scenario, you don't need them.

        Comment


          #5
          Re: Question - variable scope between forms

          Hi Dick,

          Originally posted by dik_coleman View Post
          Wouldn't the use of global variables solve the problem?????
          Robert wasn't expressing a problem, just what was accessible. But, yes, global variables would be accessible from any session. And if not dimensioned, it effectively bubbles up to looking at the global space for the variable name.



          Originally posted by G Gabriel View Post
          If both forms are based on the same table, then shared variables will be visible to both.
          This is incorrect. Create 2 forms with init events, 1 setting a dim'ed shared variable to a value, the 2nd displaying the value of a dim'ed value of the same name. Open up the 1st, which will set the value. Open up the second, and the value will not be there. Different sessions do not normally share the session variables

          However, proper use of WITH/END WITH can be used to make other variable spaces within the current code
          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


            #6
            Re: Question - variable scope between forms

            Ira:
            That's not the scenario he described.
            Originally posted by SNusa View Post
            If a form's object event runs a script (ie: a button on_click event), and that script opens a second form
            Per help file:
            Session
            SHARED
            (e.g. dim SHARED NAME as C)
            A window is open. Even if you change the layout that is loaded in the window (by using the File > Open… command from within the Form or Browse window), the variable continues to exist.

            Comment


              #7
              Re: Question - variable scope between forms

              Originally posted by G Gabriel View Post
              Per help file:
              Session
              SHARED
              (e.g. dim SHARED NAME as C)
              A window is open. Even if you change the layout that is loaded in the window (by using the File > Open� command from within the Form or Browse window), the variable continues to exist.
              That replaces the form in the current session with a different form, and since the session (thread) has not terminated, the shared (session) variables still exist.

              But it's not the same as opening a second form, which creates a new session and Alpha Five window, which is what Robert said.
              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


                #8
                Re: Question - variable scope between forms

                Originally posted by csda1 View Post
                That replaces the form in the current session
                Isn't that what he is talking about?
                What would be the point of opening 2 different forms, based on the same table, simultaneously?

                Maybe I shouldn't ask. Recently, there was a thread about opening multiple forms based on the same table all at the same time. None of this make any sense to me, but I am sure someone will argue that it is necessary under certain circumstances.

                Comment


                  #9
                  Re: Question - variable scope between forms

                  All the feedback and replies are extremely enlightening...
                  I know the "simple answer" is "just use global vars."

                  That being said, I guess a better way to word my question would be to present the folliwng scenario:

                  If form1 button calls script in the code library. (passes all vars to script using script_play_local() function.).....
                  Then this script opens Form2. (a different form)......

                  Form2 can only see existing global variables, along with variables it (form2) creates. Concequently form2 can not "see" any of the variables that the script "sees" except for global ones.

                  Bottom line:?????
                  Forms can pass variables "down" to scripts
                  Scripts can pass variables "into" other scripts called by the script.
                  BUT generally speaking, scripts cannot pass variables up to forms (opened by the script.)

                  (althouth there may be some way to do it, but not not by design - that's what global variables are for.)

                  Right?

                  ALSO...
                  You presented two (2) interesting side questions...

                  1.) What about opening a modal window? Same thing?

                  2.) Exactly when are variables "destroyed?"
                  Specifically, what happens to "passed" variables when form1 closes, but the script called by form1 is still running? Will this create errors within the script? Or do the variables passed from form1 remain intact for the life of the script? (Since the script "received them" prior to form1 actually closing?)

                  These questions may seem "funky" but they provide much insight.

                  I appreciate your responses.
                  Robert T. ~ "I enjoy manipulating data... just not my data."
                  It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                  RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                  Comment


                    #10
                    Re: Question - variable scope between forms

                    Hi Robert,

                    Originally posted by SNusa View Post
                    Form2 can only see existing global variables, along with variables it (form2) creates. Concequently form2 can not "see" any of the variables that the script "sees" except for global ones.
                    This is correct. You can pass a pointer to form 2 of the variable space of form 1 either through a global pointer, or if you identify the form 1's window, you can can get the shared and local pointers of form 1's spaces.

                    Originally posted by SNusa View Post
                    Bottom line:?????
                    Forms can pass variables "down" to scripts
                    Scripts can pass variables "into" other scripts called by the script.
                    BUT generally speaking, scripts cannot pass variables up to forms (opened by the script.)
                    This is correct as well. But you are better using functions, as they isolate it's variable spaces and allow better debugging. See my tips page.

                    Originally posted by SNusa View Post
                    (althouth there may be some way to do it, but not not by design - that's what global variables are for.)

                    Right?
                    Again, correct. If you can get a pointer to the window of the form, you can get everything that it contains and do everything just as if you were on that form. But remember, they are running independently. So if you were to write multiple values from form 2 to form 1, it's possible form1 might read partially written block of values as you are writing them. Thus you need to include a (semaphore or atomic) flag that says basically you are in the process of writing them followed by saying you are done. The real trouble here is Alpha 5 has no "test and set" instruction or something that can be used as such. (Only the locking of a record going into change mode accomplishes this). This means that just before you set the flag, your other window was reading the flag, both the read and write could proceed as if it was OK. It's a very small window, but possible. This makes inter-thread (read as session/window) communication potentially dangerous any time more than 1 item needs to be passed. Fortunately, it is never possible in Alpha to get a partially written single item. But if you extrapolate this, this same problem of inter-thread communication exists as well, even if you are using global variables to pass values. There are many that don't get this (and will never get this).

                    The best method I can think of is to have a pointer to a bunch of empty variables, and then in 1 write, change the pointer to another pointer's value with all the correct values. At worst, the other thread will think that the values have not changed.

                    Originally posted by SNusa View Post
                    ALSO...
                    You presented two (2) interesting side questions...

                    1.) What about opening a modal window? Same thing?
                    If it opens up another session/thread, it is the same.

                    Originally posted by SNusa View Post
                    2.) Exactly when are variables "destroyed?"
                    Specifically, what happens to "passed" variables when form1 closes, but the script called by form1 is still running? Will this create errors within the script? Or do the variables passed from form1 remain intact for the life of the script? (Since the script "received them" prior to form1 actually closing?)
                    When the window/session/thread closes, all of it's local and session variables go away. However passed pointers still point somewhere, so the variables under that pointer may possibly exist after that time, for some time, but I wouldn't count on it. Code containers that are executing at the close time contained within the window/session/thread will continue to their end, but anything needed by it contained within the window, and I say this with only 80% confidence) will be gone (with the exception of local variables to that code).

                    Originally posted by SNusa View Post
                    These questions may seem "funky" but they provide much insight.
                    Actually, they are not "funky" at all. These are key programming concepts that few ask, and fewer understand. I suggest reading wikipedia and searching for atomic operations and semphores to understand multi-thread communications further.

                    In most cases, Alpha programmers do not see this problem at all, because only 1 A5 window is active at a time, and the windows are all normally waiting for user input. But add a timing event on a form, and suddenly, you are potentially in a very dangerous world talking to other threads!
                    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


                      #11
                      Re: Question - variable scope between forms

                      Robert,

                      Just to add my 2-cents to this rather enlightened discussion, here are two sample code snippets showing how to get at variables in another session, one for local, the other for shared.

                      Local:
                      Code:
                      DIM f as P
                      DIM vLocalVars as P
                      
                      f= form.load("ProjContEntryDialog","Dialog","","center","center")
                      vLocalVars = f.variables()        ''get the local vars
                      vLocalVars.vCond1 = "Contact"
                      f:cond1.refresh()
                      Shared:
                      Code:
                      DIM f as P
                      DIM s as P
                      DIM sVars AS P
                      DIM vDesc AS C
                      
                      f = form.load("AcctgBillMemos","dialog")
                      f.show()
                      
                      ''Get the session variable in the loaded form namespace, so that we can fill in the invoice description
                      
                      s = f.SessionHandle()
                      sVars = session_variables(s)
                      vDesc = SVars.vInvoiceDesc
                      
                      f.close()
                      
                      ''other stuff here
                      This is one way of avoiding using global variables.
                      Peter
                      AlphaBase Solutions, LLC

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


                      Comment


                        #12
                        Re: Question - variable scope between forms

                        Hi Peter,

                        It was good showing the technique. I'll add 1 other recommendation for people in general. Very often they'll do a form open or similar, but never take the result from the operation, i.e.
                        form.view("formname")
                        This is bad, because you have no idea of what the window's name is (it could be an "alias" like formname0, if formname was already an object. Hence, it is always wise to save the pointer from the open, and then you can easily reference the form's session in the future, as in;
                        formpointer=form.view("formname")
                        By doing as you have, the form pointer can then be used with all the other needed code to operate in the session of the form.
                        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


                          #13
                          Re: Question - variable scope between forms

                          CORRECTION NOTE: Peter G's Shared: code example (in post #11 above) incorrectly declared the local variable "s" as type P (pointer).
                          It should be type N (numeric).

                          Code:
                          DIM f as P
                          'DIM s as [COLOR="#FF0000"][B]P[/B] ' - INCORRECT[/COLOR]
                          [COLOR="#FF0000"]DIM s as [B]N[/B] ' - CORRECT[/COLOR]
                          DIM sVars AS P
                          DIM vDesc AS C
                          
                          f = form.load("AcctgBillMemos","dialog")
                          f.show()
                          
                          ''Get the session variable in the loaded form namespace, so that we can fill in the invoice description
                          
                          s = f.SessionHandle()
                          sVars = session_variables(s) ' [COLOR="#FF0000"]- this function returns a numeric value[/COLOR]
                          vDesc = SVars.vInvoiceDesc
                          
                          f.close()  ' [B][COLOR="#FF0000"]* don't close form too soon! (explained below)[/COLOR][/B]
                          
                          ''other stuff here
                          ~This is a great technique/learning example! It's also important to realize: The sVars pointer is only a pointer to the original variables in the other layout..... Hence, when you close form "f" (regardless of whether or not it's modal/dialog) the values pointed to (by sVars) are destroyed.... * (So don't close form "f" before using/re-assigning these values!)

                          PS: If you're having problems with Dialog (modal) forms not stopping code in the original calling form, (ie: not behaving "modal") here is the problem.
                          Last edited by SNusa; 02-21-2012, 03:19 PM.
                          Robert T. ~ "I enjoy manipulating data... just not my data."
                          It's all about the "framework." (I suppose an "a5-induced" hard drive crash is now in order?)
                          RELOADED: My current posting activity here merely represents a "Momentary Lapse Of Reason."

                          Comment

                          Working...
                          X