When do events really fire????

[enstorms]

Am still trying to get a handle on this and have a couple of questions. In trying to determine (on entering a form) whether or not to do a lookup into another table, was using the ui_msg_box (umb) to return the tbl.mode_get(). Well, for me, that brings up another question. The form was called to add a new record, but get a return value of 0. Now, for this post, my code is on the first field of the form and it is a field rules lookup field and it is in the OnDepart event of that field. However, I get the "umb" popping up before my first field even gets focus to enter data. Is all the behind the scenes lookup stuff causing this OnDepart event to fire? Get same results with Modal or Modeless and no restrictions set for the form.
Would also like further explanation on entry modes. I come from a background where the entry mode was set to either view, insert, change or delete when the form was called. I think that is what is messing me up on this new way of doing things.
Thanks for any help.
Ernie

[Tbaker]

Re: When do events really fire????

Ernie

First of all, the ondepart event fires when the field loses focus.

Look in the help file object, events. (I am sure you already have looked there)


You questions puzzles me as far as the ondepart and the lookup is concerned. If the lookup for the first field is shown as a lookup in the field rules , then why would the code for the lookup be in the ondepart event. At that point you would have left the field?

I am a little confused as to what you want to happen.


As far as enter, view, mode etc.

if you are entering a field into a blank form, then the form is enter mode (the xbasic would be tbl.enter_begin(), tbl.enter_end. If the table's field have data in them and you fetch that record - then you are in view mode. If you begin to change an entry in one of those fields, the mode shifts to change mode (xbasic tbl.change_begin(), tbl.change_end().

Enter mode - nothing in any field - new record
View - fields have data but not doing anything to any field
Change - with focus on a field begin changing the fields value

Tom Baker

[enstorms]

Re: When do events really fire????

Tom,
I was just wanting the code to fire as focus was moving to the next record. Just doing some investigating trying to figure when stuff happens. Now, this form is called from an embedded browse. Have a button by the browse "Add" and use action scripting, call companion form, add a new record. Don't know if this is proper or not, but doesn't seem to be right cause the form actually has data loaded when it opens, which is why I'm seeing the view mode returned, I guess. Am passing values to the form also. Does this make a difference?

"it is a field rules lookup field"

This is just for information purposes. I guess I need to find out what is causing it not to open in Enter Mode.
Have an edit button in one of the browse colums that opens this same browse. The form opens normal with the record loaded. The event doesn't fire until I tab out of the first field. Will try to work up a database to zip up and send.
Ernie

[enstorms]

Re: When do events really fire????

Tom,
Here's the two forms I'm working with. It opens the Reservations form from which the Lodging form is called (Lodging/Fees tab). I just left my code in there. It's on the first field (Facility) of the form.
Whenever you get a chance, would greatly appreciate some help. Thanks.
Ernie

[Tbaker]

Re: When do events really fire????

Ernie

I didn't forget about you, but I was busy last night ( babysitting grandkids) and work has been hectic.

First, I looked over your app (reservations and facitlity use). It is quite a comples application with the setting of variables across two forms.

Not knowing what you want to accomplish other than what I see - it is taking me some time to review your code (action scripting and inline basic) to determine just what is supposed to happen and what is supposed to appear on the facility use form brought forward from the reservations form.

The first thing that I encountered is on the facility use form. You have an OnArrive event and an OnDepart Event on the use_date (one to refresh cost and the other to set the value of use_date0, but these are not type in or tab to fields so the two events will not fire. I changed the OnDepart event that sets the value of use_date0 in the set field value in the onpush event of the add button of the reservation form. I changed to the OnArrive event of use_date to the On_depart event of the Fac_id field to refresh the cost.

That is about as far as I have gotten. By the way there are lookups in the reservations table that need grp_types.dbf and a status type. I just made up my own grp_types with one field in it so that I could put the group type in the reservation form and I just skipped the status field.

You have a lot going on between those two forms, there are a lot of fields and variables being updated between forms which I feel is causing somewhat of a refresh problem. But like I said I haven't gotten that far yet.

Oh and one of your questions about the "Add" button entering a new record - that is not a problem as far as I can see. You may want to go with a Form.load -set the fields and the variables and then form.activate - form.show to place the form on the screen. You may want to look into something like that. There have been a few posts on the forum about setting fields and loading variable while the form is not visable.

I will keep working on this whenever I have time. But in the meantime you might to look at the facility use form on the onArrive and onDepart event of the use_date.

Keep me posted and I will certainly keep you posted.

Tom Baker

[Tom Cone Jr]

Re: When do events really fire????

Ernie, the trace window has an option to trace events. This can be useful in figuring out the exact order in which various events fire. -- tom

[CALocklin]

Re: When do events really fire????

To add to Tom Cone's comments. Events fire in a very logical order. It's just that the logic isn't immediately, or intuitively, obvious to most users - including me. Some events can even fire two or three times when you would think they should only fire once. Sometimes when and how often an event fires depends on what actions are in other events.

If you think this is confusing, join the crowd.

The only real way to find out in any given situation is to do as Tom suggests and use the Trace window.

When I've run into really strange problems like this I've been known to put something like
trace.write_line("<Event_name>")
in each event. In some cases "each event" even included some events that I didn't have code in just so I could determine what was happening.

I've also been know to put a ui_msg_box("","<Event_name>") in each event BUT be aware that sometimes this can change the sequence of events. I think the reason is something like, for example: "the OnDepart event runs and creates a ui_msg_box() but then the field gets focus again when the message box closes so the OnDepart event fires again." Hence the need to use the Trace window to get the sequence.

[enstorms]

Re: When do events really fire????

Thanks so much for all the replies and help. Tom, sorry for the confusing app I zipped up for you. It's all my fault in trying to do some troubleshooting and forgetting about event code I had written and then changed the field from a typein field to a read only field since I don't want that value changed on this form. Got sidetracked when I started trying to figure out why events weren't happening when I thought they should. Using ui_msg_box to do my troubleshooting and I guess, as was so graciously pointed out, this can sometimes produce unexpected results. Tom, yes I have used the debug/trace window, but not for this yet, so will get back to doing that. This app is an idea/app I am bringing to a5, so am trying to convert my former way of doing things to a5's way. Quite a steep learning curve. It is enjoyable and frustrating at the same time.
Thanks again for all your help and I welcome any suggestions.
Ernie

[G Gabriel]

Re: When do events really fire????

Events fire when they are supposed to fire and I for one have never had them fire at the wrong time or when they are not supposed to.

As in most environements, the first and most common mis-diagnosis of operator's error is "machine defect" which is hardly ever the case.

[G Gabriel]

Re: When do events really fire????

Reading this thread is like watching "Real Time with Bill Maher", which has nothing to do with "real" but rather a venue to vent frustrations!

So that I am not viewd as being "hard" on anyone in this thread who might have made any comments to the contrary, I opened your zip file to see if by any chance the events are firing when they are not supposed to but as expected, it proved, yet one more time, what I just said in my previous post.

In your "onDepart" script of the field "classid", you have multipe Action Scripts that do the following:
1-The first one has an if() statment and also says: tbl=table.current()
2-The second one sets values for certain objects in the form
3-The third one says:
tbl = table.current()
ui_msg_box("Entry Mode",tbl.mode_get())

Your question(s) seem to be centered around:
1-Why the error message?
2-How come the OnDepart fires when the form loads?

The error message is very obvious:
tbl.mode_get() is a numeric value. You simply needed to change it to character which I did and the error went away.

When I saw the OnDepart event of an object on the form fires when the form first loads, two things immediately came to mind:
a-That field must be the first one in the tab stops and
b-That field must be an auto-incrementing one.

Sure enough, both assumptions were true. That's why the event "seems to" fire when the form loads because alpha is doing what you told it to do:

When you first load the form, alpha stopped at that object (classID) first, it auto-incremented and entered the value in that field, it departed and then fired the OnDepart event.

It is not a machine error.

[enstorms]

Re: When do events really fire????

Hi G.
Thanks for you input. Seems it's been so long since I made that post, I downloaded the zip myself to see where your statements apply. Just a couple of things, as I mentioned in reply to TBaker, I had changed a typein field to a readonly field (use_date) and forgot to remove the scripts from a couple of events on that control.

1-The first one has an if() statment and also says: tbl=table.current()

the tbl = table.current() was leftover from trying to figure out how to refererce values on forms. Finally figured out I had to reference via the form pointer and not the table pointer.

3-The third one says:
tbl = table.current()
ui_msg_box("Entry Mode",tbl.mode_get())

The error message is very obvious:
tbl.mode_get() is a numeric value. You simply needed to change it to character which I did and the error went away.

Not sure what error you're talking about and what needs to be changed to a character.

When I saw the OnDepart event of an object on the form fires when the form first loads, two things immediately came to mind:
a-That field must be the first one in the tab stops and
b-That field must be an auto-incrementing one.

Sure enough, both assumptions were true.

a. Yes it is.
b. No it isn't. The auto-incrementing field isn't even showing on the form. This field is a lookup into another table as shown in the field rules.

I will admit to some frustration in these posts, but they have only come after several hours of reading the help file and trying different things to figure out the behind the scenes mechanisms. So I really do appreciate you taking the time to read my post and look at the zip and will take all the help I can get.
FWIW, never did figure out why the ondepart event was firing before the first field even got focus. Have gone to calling the add with a form.load and loading all the variables then doing a form.show(). That works fine.
Thanks again for you inputs.
Ernie

[G Gabriel]

Re: When do events really fire????

See explanation below.

[G Gabriel]

Re: When do events really fire????

never did figure out why the ondepart event was firing before the first field even got focus

The form Facility Use is based on Facility use set which has:
Parent: Facility Use
Child: Facilities
Link: 1-1
Linking Field: Fac_ID

In the parent: Fac_ID is user entered
In the child: Fac_ID is autoinc.

When you add a record to a set that has 1-1 link,you could add values in the child before the parent.
Since Fac_ID in the child is autoinc, it gets filled.
Since Fac_Id in the parent is lookup from the child's Fac_ID, it also gets filled up and the onDepart fires.

To see what I mean:
Instead of opening Facility Use form from reservations_form, open it separately, the OnDepart event does not fire. It will only fire when you add a new record.

[G Gabriel]

Re: When do events really fire????

What you are doing, which is a bit unusual, you are unwittingly putting the cart before the horse:
You are adding a new record to the form which is based on a set, but by virtue of the fact that Fac_ID is an autoinc field in the child, the child field gets filled before the parent, which forces the parent to be added. You couldn't have done that in a 1-M set, but in a 1-1 you could. Once the parent is added, the OnDepart fires!
What a conundrum!

[G Gabriel]

Re: When do events really fire????

I have to leave for a good while so I won't be able to respond soon, but the morale of the story is:

The Linking field in a child should not be autoinc.

When you enter a new record in a set, the child's linking field gets it's value from the parent. Here you have the child gets it's value from the parent which gets it's value from the child!