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

Field Rules - Field Events & Record Events

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

    #16
    Re: Field Rules - Field Events & Record Events

    CANSAVERECORD event - field rules

    if a_deleting_record
    end 'I don't want ANY of the following code to fire if they are deleting record(s)
    end if

    t=table.current()
    n=t.mode_get()
    if n=2 'entering a new record
    msgbox("Note","We just entered and saved a new record")
    elseif n=1 'editing an existing record
    msgbox("Note","We just modified an existing record")
    end if

    Like Gabe said, there may be rules you want applied regardless of what layout you are using, including the default browse
    If you have maybe 10 different layouts for a table that permit enter or edit possibilities, writing code for all of them can be time consuming and error prone
    Cole Custom Programming - Terrell, Texas
    972 524 8714
    [email protected]

    ____________________
    "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

    Comment


      #17
      Re: Field Rules - Field Events & Record Events

      in your last post you are not realizing that records entered via xbasic, the way you are doing it, will often not "automatically" show up without "refreshing" the layout - like the default browse, etc.

      say for example you have a shadowed database with 5 users entering records in a table. And you make a form or browse showing records for that table, and open it and watch what's happening. you can press the F5 key to "refresh" the layout, but otherwise it will not automatically "refresh" - you can also put a timer event to refresh the layout every n seconds.

      this is not a bug, just the way it is
      Cole Custom Programming - Terrell, Texas
      972 524 8714
      [email protected]

      ____________________
      "A young man who is not liberal has no heart, but an old man who is not conservative has no mind." GB Shaw

      Comment


        #18
        Re: Field Rules - Field Events & Record Events

        PS: Interesting that table.enter_end() presumably has different parameters depending where you look for help.....

        See Auto/bubble help image here: Snap 2012-05-12 at 23.28.00.png
        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


          #19
          Re: Field Rules - Field Events & Record Events

          Robert, looks like the auto-complete is ahead of the wiki. I'm pretty sure the default parameters (for the optional terms) would be TRUE for commit and FALSE for update the UI. Would be nice if the helps were up to date. -- tom

          Comment


            #20
            Re: Field Rules - Field Events & Record Events

            Hi Martin & Tom;

            Did you view the screencast in post #15 regarding the events not recording when going field to field [in the same record]. (within the default browse) ~In this scenario, the field events are not triggering the function to write to the event file. Nor are they appearing within the trace window.....

            Interestingly enough, I am uncovering this stuff as a result of working with this training material by Peter Wayne.
            (I'm just trying to establish exactly "what happens when." ~Because I think it's important regarding a solid foundation in a5 & Xbasic.)
            Last edited by SNusa; 05-13-2012, 12:38 AM.
            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


              #21
              Re: Field Rules - Field Events & Record Events

              Robert,

              Regarding post 15 -

              Alpha doesn't expose all the "events" that are occurring in Windows as the user works with our forms and embedded browses. So far as I know we've never been able to see things like canArrive, OnArrive, canDepart, OnDepart when tabbing from field to field ( column to column ) in an embedded browse object. It's a limitation of the browse control. Place your form in design mode. Select the column in an embedded browse. Right click to see column properties and events. These are the tools we are provided. It should be noted that we can create _on_Change events for embedded browse columns now. This has been a helpful addition to our programming toolkit. Details here. Furthermore, the lack of a full panoply (sp?) of "events" within the column structure of an embedded browse is often what causes some of us to eschew data entry through embedded browses, in favor of single table based forms. We have more "control" over field objects in the form than we do over columns in the browse, if you see what I mean.

              I suspect you are correct about the timing issue and index corruption you mention. OPening and closing the target table is among the slowest things our computers do. Yet, Windows fires events at Alpha at a very high rate. No way the hard disk activity can keep up. If I were exploring the things you are studying, I'd change the function to simply store the information you're collecting in a string (character) variable, and at the end of a particular session I"d display it on screen or write it t to disk. I would forego realtime, line by line, disk writes or screen displays.
              Last edited by Tom Cone Jr; 05-13-2012, 06:43 AM.

              Comment


                #22
                Re: Field Rules - Field Events & Record Events

                Originally posted by Tom Cone Jr View Post
                Robert,

                Regarding post 15 -

                Alpha doesn't expose all the "events" that are occurring in Windows as the user works with our forms and embedded browses. So far as I know we've never been able to see things like canArrive, OnArrive, canDepart, OnDepart when tabbing from field to field ( column to column ) in an embedded browse object. It's a limitation of the browse control. Place your form in design mode. Select the column in an embedded browse. Right click to see column properties and events. These are the tools we are provided. It should be noted that we can create _on_Change events for embedded browse columns now. This has been a helpful addition to our programming toolkit. Details here. Furthermore, the lack of a full panoply (sp?) of "events" within the column structure of an embedded browse is often what causes some of us to eschew data entry through embedded browses, in favor of single table based forms. We have more "control" over field objects in the form than we do over columns in the browse, if you see what I mean.

                I suspect you are correct about the timing issue and index corruption you mention. OPening and closing the target table is among the slowest things our computers do. Yet, Windows fires events at Alpha at a very high rate. No way the hard disk activity can keep up. If I were exploring the things you are studying, I'd change the function to simply store the information you're collecting in a string (character) variable, and at the end of a particular session I"d display it on screen or write it t to disk. I would forego realtime, line by line, disk writes or screen displays.

                Thank you Tom ~ You are an "Alpha-God with a sense of compassion!"

                Your reply created "resolution" at many different levels..... It all makes sense! I can't wait to look into the details regarding browse _on_Change events....
                Thank you again for sharing your "plethora of know-how, experience & knowledge!" ~ Great suggestion regarding collecting the info in a string manage to avoid "data I/O overload."

                PS: You got the spelling right!
                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


                  #23
                  Re: Field Rules - Field Events & Record Events

                  Originally posted by SNusa View Post
                  Here's the video: http://screencast.com/t/YjQb8b9xgF

                  This is apparently a limitation of the browse. Notice the events not triggering when moved from field to field within the same record.
                  You did not follow the steps I described.
                  You are giving focus to the field...that is not EDITING..
                  You need to start EDITING....then check your trace window.
                  CanFieldEdit will take advantage of that point in time (as in "Somewhere in Time") right after you started editing and before the edit is committed and give you the opportunity to CANCEL anythng you want to cancel. Could be something you want to cancel if somebody enters "Lucifer"! i.e. enters "L", or enters a character in a numeric field.
                  OnFieldEdit: the edit has been committed.
                  See the difference?
                  See any potential benefits?

                  Comment


                    #24
                    Re: Field Rules - Field Events & Record Events

                    Originally posted by G Gabriel View Post
                    You did not follow the steps I described.
                    You are giving focus to the field...that is not EDITING..
                    You need to start EDITING....then check your trace window.
                    CanFieldEdit will take advantage of that point in time (as in "Somewhere in Time") right after you started editing and before the edit is committed and give you the opportunity to CANCEL anythng you want to cancel. Could be something you want to cancel if somebody enters "Lucifer"! i.e. enters "L", or enters a character in a numeric field.
                    OnFieldEdit: the edit has been committed.
                    See the difference?
                    See any potential benefits?
                    BINGO ~ Thanks G.

                    I had become side-tracked as I began experiencing the index corruption issues and wasn't following your help literally as I should have. ~I SEE NOW!

                    The following field & record events do register (in this order) when you begin to edit the field data, in this order:
                    CanEditField -> OnEditField -> CanChangeRecord -> OnChangeRecord

                    Good to know & understand....
                    Last edited by SNusa; 05-13-2012, 07:14 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


                      #25
                      Re: Field Rules - Field Events & Record Events

                      Glad you got it..the index stuff, I didn't even look at..that's the topic for a different thread.

                      Comment


                        #26
                        Re: Field Rules - Field Events & Record Events

                        Originally posted by G Gabriel View Post
                        Glad you got it..the index stuff, I didn't even look at..that's the topic for a different thread.
                        Ever played "Whack-A-Mole" at the fair? ~As I'm absorbing all this stuff, occasionally I think I know what it's like to feel like the mole! ;-)
                        ~You might say that sometimes it just takes "a few more [thumps] on the head to get there from here." ~ Resolution & Enlightenment!
                        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


                          #27
                          Re: Field Rules - Field Events & Record Events

                          I have just started using browse field onChange events. In preference to table field rules.
                          I now have it working perfectly.

                          After struggling with the browse Row level events for a long time, as Robert covers, the default record doesnt trigger, and exiting the browse to a form object doesnt trigger the last field.
                          Using field onChange, reading, as expected worked fine.

                          A (probably unnecessary) word of warning
                          I'm pretty sure others do, but I didn't use the Object Explorer and just referenced the objects in code.
                          Writing values to fields didnt work. I eventually found that improper address punctuation was the cause.
                          A couple of days went on this and whilst preparing a cut-down to post, I discovered the problem.

                          Ray

                          Comment


                            #28
                            Re: Field Rules - Field Events & Record Events

                            Originally posted by martinwcole View Post
                            CANSAVERECORD event - field rules

                            if a_deleting_record
                            end 'I don't want ANY of the following code to fire if they are deleting record(s)
                            end if

                            t=table.current()
                            ...
                            For what it's worth, "table.current()" when used in the TABLE field rules, will always refer to the table the field rule is in even if that table is part of a set at the time it's invoked.

                            At one time, I was concerned that it might find the parent table if used when in a set but that's not an issue as long as we are talking about TABLE level rules - not form level.

                            Comment


                              #29
                              Re: Field Rules - Field Events & Record Events

                              Originally posted by CALocklin View Post
                              For what it's worth, "table.current()" when used in the TABLE field rules, will always refer to the table the field rule is in even if that table is part of a set at the time it's invoked.

                              At one time, I was concerned that it might find the parent table if used when in a set but that's not an issue as long as we are talking about TABLE level rules - not form level.
                              Hi Cal, ~ Interesting you mentioned that. As one of the question I had is loosely related:

                              What "session is the table itself actually running in?" ~ Put another way, if you attach code to the tables record/field events and use shared (session) variables, you are not creating/working with them from within the form itself. -THE ANSWER FOR THIS IS YES.... ~ So if you create a shared variable in one record/field event, can you refer to it directly from another event on the same table! And how about the possibility of this variable being accessible from events and scripts on the form? -THE ANSWER FOR THIS IS ALSO YES....

                              Even so,..... Would code like this also work when placed within the tables record/field events:

                              Code:
                              dim vp_Table as P
                              dim vp_SessionHandle as P
                              dim vp_SessionVars as P
                              
                              vp_Table =table.current() ' ~ to get pointer to to table
                              'vp_Table = this.this ' ~ THIS WON'T WORK, I'M A BIT SURPRISED.
                              vp_SessionHandle = vp_Table.SessionHandle() ' ~ get pointer to session
                              vp_SessionVars =session_variables(vp_SessionHandle) ' ~ get pointer to variables
                              showvar(vp_SessionVars.<VariableName> ' ~ display variable value.
                              I'm going to do a bit of testing.......
                              Last edited by SNusa; 05-14-2012, 02:17 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


                                #30
                                Re: Field Rules - Field Events &amp; Record Events

                                Noticed something very strange about the CanEditField Field event....

                                If you place certain Xbasic code within this event, such as msgbox("This is the CanEditField Event") ~ a5 goes bonkers and gets stuck......
                                (The exact same msgbox() placed in the OnEditField behaves fine).....

                                Also happens with the UI_msg_Box() function, and even loading non dialog forms ie: form.view("AnyForm"). ~ Strange as it may seem, this CanEditField event seems to work fine when manipulating data, but not when presenting things within the gui...

                                Also: Although a form can access shared variables defined within the table events..... By opening a second form via this event (not that you would probably want to anyways) also messes up all the shared variables.) ~Once the form opens, all shared variables declared within the tables events events become lost..... (Lost not only within the coded events of the table itself, but also from the form that the table is based on.)

                                This unexpected behavior seems related to adding any/all UI_ functions getting, or presenting visual info to/from the user..... Timing issue here again?

                                I had created some very basic code to control browse data entry, but once I documented it with a few msgbox() popups, things stopped working as expected. ~Actually, a5 got caught in some loop where I can't easily get out of the existing record.... Removing the one line of code [ msgbox("This is the CanEditField Event") ]from the CanEditField Field event returned everything back to normal!

                                The only other thing I can think of is that I don't have an end statement placed on all of the scripts in the table.... [I know they should be there] ~I put a few in, but am still experiencing the same wacky behavior....
                                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