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

    Field Rules - Field Events & Record Events

    With permission from the "Department of Redundancy Department" I am posting: this link here to a question recently posted in a v.10 thread. (Hoping that someone who hasn't seen it can help.):
    Having researched the matter, I'm wondering why some of the "table level" events exist in the first place, as some appear "redundantly redundant." (Along with a few other questions regarding events at the "atomic level" when working with "table level" events in Xbasic.) ~After reading through the wiki documentation, it appears that several events are essentially unnecessary, and one useful event appears to be "missing."

    In actuality, I'm sure I'm the one who is "missing something."
    Last edited by SNusa; 05-11-2012, 09:37 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."

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

    Originally posted by SNusa View Post
    I'm wondering why some of the "table level" events exist in the first place, as some appear "redundantly redundant." [/COLOR][/I]
    From the Federal Register pertaining to the Department of Redundancy in Washington DC (AKA GSA):
    Table level events=Federal Government.
    Meaning, their rules apply to ANY window you create based on that table and supersedes the State laws.
    Sorry if my answer lacks redundancy!

    Comment


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

      "I see said the blind man as he walked off the cliff."

      Hi G.;

      ~I'm aware of what you are saying. I'm referring to "Record Level Events" in general as they operate at the "atomic level." (Independent upon whether they are on a form or within a default browse.) ~From what I've read, you can do everything you need to without even needing to use the canDelete and onDelete record events as the trigger. (CanSave and OnSave record events provide the exact same functionality, since A_DELETING_RECORD is always required to detect a delete operation.)

      ALSO: I've been working with this all morning. I believe I have found a bug in the OnEditField & CanEditField events (Field Event in Table Field Rules)! ~ Try this on the Alpha Sports Invoice_Items table......
      • Place ui_Beep() in both the CanEditField and OnEditField Field events of the price.
      • For safe measures, add an index to the price field in the table too.
      • Open the default browse for this table.

      Click on the first price field. ~ No beep! (Problem/Issue)
      Click on the second price field. ~ Beeps as expected.
      Click back on the first price field. ~ Now it beeps.
      Click on the third record description. (not the price field) ~ No beep. (beep not expected here)
      Click on the third price field. ~ No beep! (Problem/Issue)
      Using the scrollbar, scroll down to the last record & click on price field. ~ No beep. (Problem/Issue)

      What is happening: If you (or Alpha5) happen to be in/on a field (within the same record) and you click on the price field, these events don't trigger. ~To make them trigger, you must be on a different record. And when a browse opens, you are automatically on the first record.

      Consequently, the first record of any embedded browse will never respond to either of these events the first time, unless you have moved to a different record. More importantly, whichever record you are presently on, will also never trigger unless you first move to a different record!

      Weird... ~ Just like physics, something here appears to break down at the "sub-atomic level?"
      Last edited by SNusa; 05-11-2012, 01:20 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


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

        Originally posted by SNusa View Post
        you can do everything you need to without even needing to use the canDelete and onDelete record events as the trigger.
        Yes you can..."Yes we can!".
        But then, using the same logic, you could say: Why does alpha have Action Scripts"? You could do everything with xbasic, can't you?!

        I didn't read the latter part of your post as I am multi-tasking, and Fridays are not a good day for me. Maybe later.

        Comment


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

          Originally posted by G Gabriel View Post
          Yes you can..."Yes we can!".
          But then, using the same logic, you could say: Why does alpha have Action Scripts"? You could do everything with xbasic, can't you?!

          I didn't read the latter part of your post as I am multi-tasking, and Fridays are not a good day for me. Maybe later.
          Cool ~ Have a great weekend.... (& as for the problem above, I'm submitting it as a potential browse bug.)

          Also, as posted here:http://msgboard.alphasoftware.com/al...l=1#post610277

          Based on the wiki, what seems impossible [at the table level], (or at least unexplained) is an event that can "trigger" just before you save a NEW RECORD.

          The events CanEnterRecord (before moving to the new record) and OnEnterRecord (after moving to the new record) are not related to saving the record, only moving to a new record... Is there some special variable like A_ADDING_RECORD to trap for this during the CanSaveRecord/OnSaveRecord events?
          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


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

            What exactly is "Just before" you save a record?
            What moment of time is that?
            That require clairvoyance, doesn't it?!
            You could create one and call it: OnCalirvoynce event! Or for those, like myself, who are vocabulary-impaired: ONCrystalBall Event.
            How is alpha, or for that matter anyone except for God if you believe in him/her, knows when is it that nano, and while we are at the subject of redundancy, that split nano second right before you save?
            Hold your horses on that bug thing. I don't think there is a bug there, but don't have a whole lot of time to play with it right now.
            Last edited by G Gabriel; 05-11-2012, 04:17 PM.

            Comment


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

              Hi G...

              What I'm trying to accomplish is "set a trigger" (using Xbasic within the Table Field Rule Events) to only occur when a new record is about to be saved.
              I don't want the "trigger" to fire when an existing record is about to be changed, only when a new record is about to be saved.

              For "shiggles" I created a function [fnRecordEvents] to capture all events to a new table [events_tv1] from the [invoice_items] table in AlphaSports.
              I wanted to see exactly what events were occurring when, so I wrote them to a table.....

              ~I just noticed that the add new record event triggers the CanEnter and OnEnter events..... (It also indicates the bug [I thought I found] may be legit, as the field events are not always registering as expected.)

              The script (function below) is missing vp_Table.close(). ~Must be added on a line right above END FUNCTION.
              Attached Files
              Last edited by SNusa; 05-12-2012, 01:27 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


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

                Originally posted by SNusa View Post
                when a new record is about to be saved.
                I will concur with myself:
                How does alpha know when a new record is "about to be saved"?
                Right after you finish typing?
                After you finished typing and decided to have a cup of coffee first then save the record?
                Alpha could sense when you start a new record, when you change it, when you save it ..etc (i.e. user's actions) but cannot foresee user's intentions.
                I am not trying to be cute, but it seems that you are thinking of alpha as your shrink, not your software.
                That said, what you want to accomplish is already there. It's called OnChange event. And if you want to limit it only for a new record, then check the mode or set a flag to true once you hit a new record.
                As to that "bug", what is your understanding as to when the CanEditField event is supposed to trigger?

                Comment


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

                  CanEditField: Before the cursor enters the field.
                  OnEditField: After the cursor enters the field.
                  But this is only the case if you move to the field from another record. (moving to the field from another field in the same record does not trigger this)
                  (So when you click on the first field of a browse, these events should, but do not trigger.)
                  http://wiki.alphasoftware.com/Attach...ipts+to+Events

                  As for the trigger: I was looking to test (at the table level) when table switches into enter mode. (new records)
                  (The CanEnterRecord and OnEnterRecord can & do indicate table is in "enter mode.") ~ Problem solved on this.
                  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: Field Rules - Field Events & Record Events

                    Hi Robert,

                    A wise man (Peter Wayne) once wrote, some of these Can events should be named "May I". So, May_I_Edit this field if the logged in user_name()="Keith". Just a question of semantics, not redundancy.

                    As Gabe, pointed out Alpha has given us many ways to crack the egg. Just because you don't use every part of Alpha, it does not make that unused part redundant for other people. Not a Bug, it works the way you make it work.
                    Regards
                    Keith Hubert
                    Alpha Guild Member
                    London.
                    KHDB Management Systems
                    Skype = keith.hubert


                    For your day-to-day Needs, you Need an Alpha Database!

                    Comment


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

                      Robert:
                      Your understanding is semi-complete and is not to be blamed on you as there are so many confusing things about those can events.
                      The first confusing part is the name: Can. It is not can as in "Yes we can" but can as in Cancel.
                      CanEditField occurs right before you start editing. I know the docs says before gaining focus (second confusing part), but a more accurate description is before an edit is performed, i.e. a user enters the field presses a key (put the record in edit mode), before alpha applies that key to the field it triggers the CanEditField event thus allowing the user the opportunity to cancel. And this is the third confusing part, not cancel the CanEditField event itself ( since it has already been triggered), but whatever else the user wants to cancel in the course of their code.

                      part of what might be further confusing in your examples is the use of ui_beep(), instead write the events to the trace window:
                      1-Give focus to the field
                      2-Start editing by pressing any keyboard key
                      3-View your trace window.

                      Comment


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

                        Originally posted by G Gabriel View Post
                        Robert:
                        Your understanding is semi-complete and is not to be blamed on you as there are so many confusing things about those can events.
                        The first confusing part is the name: Can. It is not can as in "Yes we can" but can as in Cancel.
                        CanEditField occurs right before you start editing. I know the docs says before gaining focus (second confusing part), but a more accurate description is before an edit is performed, i.e. a user enters the field presses a key (put the record in edit mode), before alpha applies that key to the field it triggers the CanEditField event thus allowing the user the opportunity to cancel. And this is the third confusing part, not cancel the CanEditField event itself ( since it has already been triggered), but whatever else the user wants to cancel in the course of their code.

                        part of what might be further confusing in your examples is the use of ui_beep(), instead write the events to the trace window:
                        1-Give focus to the field
                        2-Start editing by pressing any keyboard key
                        3-View your trace window.
                        Hi G & Keith;

                        I'll take a look at the trace window. Also I am aware of all the other things you mentioned regarding the can events. (FYI: also had removed the ui_beep() from my examples and fixed the missing table.close() method. ~Actually I pulled the files off the forum and cleaned them up, but never re-uploaded them. (I guess you grabbed them before I removed & fixed them......

                        1-Give focus to the field
                        2-Start editing by pressing any keyboard ke y
                        3-View your trace window. ----> If the CanEditField and OnEditField field events are appearing in the trace window, I'll be surprised! ~Because they are not writing to my trace file.
                        (Unless I'm coming from a different record into the field.)

                        Maybe this is a browse issue..... I'll check for this behavior on a form.

                        ~Even so, moving from field to field (within the same record without the ui_beep(), the field events are not being "triggered" and written to the external table. (Unless you move to the field from a different record within the browse.) ~ As that is the only way to get those field events to trigger. (And since the first record automatically has "focus" within the browse, the only way to get the first browse record to "trigger" is to move to another record and then back.)

                        I'm at work now, but sometime this weekend I will upload the the corrected trace function & tables etc. after creating a simple stand alone example.

                        PS: A long time a go I began thinking of "Can events" as "Can-Cancel events." ~ I understand what they represent.
                        Last edited by SNusa; 05-12-2012, 02:07 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


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

                          Works for me and shows in the trace window.

                          Comment


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

                            Originally posted by G Gabriel View Post
                            Works for me and shows in the trace window.
                            Thanks for trying. I'm really surprised..... I'll have to create a Jing presentation and show you what's happening on my Win7 64bit system later this weekend.....
                            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


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

                              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...... Particularly immediately after I first open the browse and try selecting the first record field. No trigger fired until I move off the first record! It's only when I select a field after moving from another record that the field events trigger.

                              This is apparently a limitation of the browse [which has an effect at the field event level], even when code is placed on the events tab while setting field rules of the table.....

                              ~Is there any way to get around this?


                              Also, throughout all this experimenting, I've found a way to repeatedly recreate index corruption:
                              It may result from a "timing issue" where you need blistering fast hardware to avoid this problem....
                              (Although this system is extremely reliable/solid and "not slow.")

                              For each event available event in the table field rules events tab I have exactly one line of code:
                              fnRecordEvents("events_tv1","<name of event>") ~ which calls fnRecordEvents().

                              Table events_tv1 has only three fields, two of which are indexed [all/ascending]. (And are exclusively written to via the function below.)
                              ~One field [not indexed] is not written to at all, and the other field is the primary auto-increment [indexed] field.

                              Code:
                              FUNCTION fnRecordEvents AS V (vc_Table AS C, vc_Event AS C )
                              	dim vp_Table as P
                              	vp_Table = table.open(vc_Table)
                              	vp_Table.enter_begin()
                              	vp_Table.Trigger = vc_Event
                              	vp_Table.enter_end()
                              	vp_Table.close()
                              END FUNCTION
                              I keep this second table open (viewing the default browse) when I navigate through the first table default browse [triggering the triggers]. Note: To see the events being recorded I have to jump focus from table to table. Frequently, I find that the vertical scroll bar size sizes improperly when viewing the vc_Table browse on subsequent browse openings... [Browse looks fine while it is accumulating data, but once closed and re-opened without records being written, is when I notice the problem.] ~While displaying the default browse, a5 doesn't know how many records are there, so it sizes the vertical scrollbar to 100% of the displayed area.) ~When this happens, rebuilding the indexes fixes it. ~TOO MANY WRITES TO THE SECOND TABLE EVENTS TABLE OCCURRING TOO FAST??? ~ "It feels like a timing thing to me."

                              I've seen this happen before all too frequently yet not easily reproducible. But having written this tiny function, now I can reproduce the index issue on a repeatable regular occurrence. ~ INDEXING ISSUES: AND GIVEN THE SIMPLICITY, THIS IS NOT A GOOD SIGN FOR .DBF TABLES......

                              The only two things that come to mind regarding this indexing issue are: SMB issues, and or the possible advantage of adding a <tbl>.fetch_last() method to the function immediately before adding the records.....???
                              Last edited by SNusa; 05-12-2012, 11:16 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