Field Rules - Field Events & Record Events

[SNusa]

Re: Field Rules - Field Events & Record Events

For any of those who are interested...

I put together a little application that traces browse events and provides some control & much insight as to how the browse interacts with the underlying table. (I used the methodology that Tom Cone Jr. suggested.)

There is one caveat, these are table events: If you open the table using the default browse instead of the form/embedded browse (which autoruns), the first (and only the first) record can not be changed as expected. I could have coded this problem out, but I didn't bother. As far as I can tell, the one form with the embedded browse works correctly and shows in real time as it displays the table events as they are firing..........

Due to a5 limitations, you must enter in some text into the CUSTDESC field. (Alpha will not allow you to save any records that do not have at least one manual entered field.... (Although I might have been able to add a browse based event/trigger to take care of this too.)

All the events that display can be viewed at the table level, by looking at the field rules....
(The one function "fnEventsToString()" records the events that are displayed in the right pane, and dings the bell as it displays which events fired, along with a running count.)

Note: There are also a few other functions and script examples which are partial "hacks."

BrowseEventTracing.zip

[SNusa]

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

Wow, in reviewing some notes, I just saw this post. I guess I missed it last May. Thanks for the tip. It ties things together with regards to my testing table field & record events....

PS: Since that time, I cleaned up that mini events app which shows the table level events triggering in real time. Anyone wants it, I'll resubmit it.

[Ray in Capetown]

Re: Field Rules - Field Events & Record Events

Noticed something very strange about the CanEditField Field event....
This unexpected behavior seems related to adding any/all UI_ functions getting, or presenting visual info to/from the user..... Timing issue here again?
..

Probably more to do with UI box appearance, closing causes a refresh.
(ie - a form repaint is used to make it "disappear" when closed)

[Ray in Capetown]

Re: Field Rules - Field Events & Record Events

PS: Since that time, I cleaned up that mini events app which shows the table level events triggering in real time. Anyone wants it, I'll resubmit it.

Robert - it would be interesting to see the workings. I would appreciate it.
Ray

[martinwcole]

Re: Field Rules - Field Events & Record Events

One other thing to note is that in all CAN events, whether table level or form level, the code for the event will sometimes fire multiple times.
This can be quite problematic.
Selwyn, way back in version 4.5 offered the following simple solution:
in the autoexec define a global variable - Busy, Logical
then, in the can event code, put the following, at the top:

if busy
     end 
end if 
busy=.t.
'event code goes here
busy=.f.

[SNusa]

Re: Field Rules - Field Events & Record Events

One other thing to note is that in all CAN events, whether table level or form level, the code for the event will sometimes fire multiple times.
This can be quite problematic.
Selwyn, way back in version 4.5 offered the following simple solution:
in the autoexec define a global variable - Busy, Logical
then, in the can event code, put the following, at the top:

if busy
     end 
end if 
busy=.t.
'event code goes here
busy=.f.

Thank you & here is the mini-application. I suspect it will come in very useful for those who want to know what is really going on (all those triggers firing) within an embedded browse..... (I spent the afternoon cleaning up the display so that it's "easy to look" at.) ~ Also added some notes.....

As for the events triggering multiple times, I'll have to go back and take a deeper look..... It's amazing how much is going on (sometimes) with just one click! Here is the upload.

One region I did encounter some strange results were with regards to how records are deleted. (The two buttons show this.) Even more strange is how marking records (unmarking too?) "trigger" some very different results depending upon how you mark the records. Using Control-M is very straightforward, but if you right click and do it via the mouse, you get all sorts of unexpected results.

I know there is some "sloppy coding" in spots. I left it in, in case I wanted to try something else. (And sometimes, I kept "failed experimental code" in place, remarked out. (So that I can go back to it if necessary.) That being said, much of my time on this (today) was getting the presentation to line up in columns.... (As all the data is presented in one huge and "ever growing" string character.) Good or bad, I'd love to get feedback.

There is some "odd code" I added in there which is not standard by any means. Just for kicks, I added in some code to the tables "OnWrote" event which prompts the user to cancel changes to an existing record. It works fine, but I wouldn't recommend it. I think I began messing with it because I had originally seen some strange results from a logic error that gave me the idea. From that point on, I decided to see what I could do with the code.

Note:
Because of the way it was written, any object that makes changes to the Customer Name field will result in the variable vc_String creating an "audit trail" of what triggers are firing from the table. (You'll want to remove the "OnWrote" code near the bottom though if you don't want to get my "home-grown" cancel/undo prompts.) I checked & confirmed that you can simply double click on the table (to open the default browse), make edits, additions etc.... (And then look at the variable vc_String from the IW, once you set the correct IW window session. ~ You'll see what events fired. (Newest ones at the front of the variable.

PS: With the exception of all browse events being recorded (regardless of field), only the CUSTOMER DESCRIPTION record field is being tracked via the table record/field events. I didn't go the "extra distance" to enumerate everything.... Wouldn't be hard to do though.)