Alpha Video Training
Page 1 of 2 12 LastLast
Results 1 to 30 of 36

Thread: Field Rules - Field Events & Record Events

  1. #1
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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 at 10: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. #2
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: Field Rules - Field Events & Record Events

    Quote 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!

  3. #3
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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 at 02: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."

  4. #4
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: Field Rules - Field Events & Record Events

    Quote 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.

  5. #5
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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."

  6. #6
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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 at 05:17 PM.

  7. #7
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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 Attached Files
    Last edited by SNusa; 05-12-2012 at 02: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."

  8. #8
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: Field Rules - Field Events & Record Events

    Quote 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?

  9. #9
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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."

  10. #10
    "Certified" Alphaholic Keith Hubert's Avatar
    Real Name
    Keith Hubert
    Join Date
    Jul 2000
    Location
    London, UK
    Posts
    6,930

    Default 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!

  11. #11
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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.

  12. #12
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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 at 03: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."

  13. #13
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: Field Rules - Field Events & Record Events

    Works for me and shows in the trace window.

  14. #14
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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."

  15. #15
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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-13-2012 at 12:16 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."

  16. #16
    VAR
    Real Name
    Martin W. Cole
    Join Date
    Apr 2000
    Location
    Terrell, Texas (near Dallas)
    Posts
    5,956

    Default 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
    martin_w_cole@msn.com

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

  17. #17
    VAR
    Real Name
    Martin W. Cole
    Join Date
    Apr 2000
    Location
    Terrell, Texas (near Dallas)
    Posts
    5,956

    Default 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
    martin_w_cole@msn.com

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

  18. #18
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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."

  19. #19
    "Certified" Alphaholic
    Real Name
    Tom Cone Jr
    Join Date
    Apr 2000
    Location
    Florida
    Posts
    23,310

    Default 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

  20. #20
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default 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 at 01: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."

  21. #21
    "Certified" Alphaholic
    Real Name
    Tom Cone Jr
    Join Date
    Apr 2000
    Location
    Florida
    Posts
    23,310

    Default 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 at 07:43 AM.

  22. #22
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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."

  23. #23
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default Re: Field Rules - Field Events & Record Events

    Quote 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?

  24. #24
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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 at 08: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."

  25. #25
    "Certified" Alphaholic G Gabriel's Avatar
    Real Name
    G. Gabriel
    Join Date
    Oct 2004
    Posts
    7,204

    Default 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.

  26. #26
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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."

  27. #27
    "Certified" Alphaholic Ray in Capetown's Avatar
    Real Name
    Ray Hendler
    Join Date
    Jan 2009
    Location
    South Africa
    Posts
    2,036

    Default 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

  28. #28
    "Certified" Alphaholic
    Real Name
    Cal Locklin
    Join Date
    Mar 2000
    Location
    S.E. Michigan
    Posts
    5,763

    Default Re: Field Rules - Field Events & Record Events

    Quote 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.

  29. #29
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & Record Events

    Quote 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 at 03: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."

  30. #30
    Member SNusa's Avatar
    Real Name
    Robert Tupper
    Join Date
    Dec 2007
    Location
    Northeast, USA
    Posts
    893

    Default Re: Field Rules - Field Events & 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."

Similar Threads

  1. Field Rules - Field Events
    By enstorms in forum Alpha Five Version 9 - Desktop Applications
    Replies: 6
    Last Post: 02-23-2010, 04:04 PM
  2. 1724_3092 & field Events
    By turbojack in forum Alpha Five Version 8
    Replies: 21
    Last Post: 07-30-2007, 09:15 AM
  3. Field Rules Record events mix up
    By G Gabriel in forum Alpha Five Version 7
    Replies: 6
    Last Post: 09-14-2006, 03:00 PM
  4. Field / Record Events
    By Bill Lewis in forum Alpha Five Version 5
    Replies: 2
    Last Post: 02-13-2004, 01:07 PM
  5. Field Rules - Events
    By by5751 in forum Alpha Five Version 5
    Replies: 4
    Last Post: 02-02-2003, 06:57 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •