Hi guys,

After 5 years of being a couch potato I have decided to try and finish a project I started in OI3.4. So even though i am quite versed in Arev I am still learning my way around OI8.0x.

I have a form with two part key:

key1=parent id

key2=a detail line number

so 070100*1 as example.

I have a custom validation routine on the editline control for key1 which works fine.

I added a default function on the key2 editline to generate the next detail ID number.

AFter I added this function to the DEFAULT for key2, I find that if the user types in an inappropriate key1 sequence, thereby forcing an invalid state for key1, the invalidation routine on Key1 fires BUT the default for key 2 also fires and tries to populate the key2 control.

The final result is that focus remains on the invalid information in the KEY1 control but Key2 has also been populated with the next detail line which is 1 (since no other details exist for the invalid KEY1 id

so if a users types in o70100 (ie invalid) then focus remains on the the key1 "o70100" but KEY2 now shows "1" instead of a null.

Is this proper event logic? (I have read everything I can find on the sequence of events and it can be confusing!)

Will the default routine always run even though the validation routine on the proceeding control is attempting to stop the flow?

If so it seems that default logic may not be too useful or am I missing something?

Thanks

ed

Hi Ed,

Welcome back to OpenInsight development!

In theory, what you are doing should work. That is, the validation of the Key1 control *should* prevent the default logic of the Key2 control from firing if there is a problem. This is how the flow of event logic works. However, there is something interfering with this and I think I know what it is.

My first guess is that you are using the Msg() function to display the validation error message. My second guess is that you are not setting the Status() flag. However, even if you *are* setting Status() correctly, the use of Msg() will prevent it from doing its job.

Here's the situation: Msg() uses the Dialog_Box() function to call up the OpenInsight form called MSG. The Dialog_Box() function is designed to display a child window while disabling the parent window (thus giving us "modal" functionality.) However, in order for the child window to process events, the Dialog_Box() logic processes a loop with embedded Yield() statements until the child window is closed. While this prevents the calling routine from continuing forward, it allows OpenInsight to process *other* events out of order. Thus, the GOTFOCUS event of the Key2 control will fire and this in turn calls the default logic you added.

So, you basically have two options to resolve the situation. First, you could update your validation and default routines to use a named common (or global) variable that you'll use for "status" purposes. You would set this variable before calling Msg() in your validation routine. Another alternative is to replace Msg() with Message_Box(). This is a wrapper around the MessageBox Window's API function call and therefore is not affected by the Dialog_Box() function’s use of the Yield() statement.

If you think this situation is bad, wait until you get into an infinite loop of two validation routines fighting each other for focus control!

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

Thank you for the explanation of what is going. You were correct about using MSG() for a custom invalidation message. I did finally figure out that STATUS() was being reset by the message so, I am around that obstacle.

Now that I know I am not going bonkers and with the insight you provided I think I can move forward with the invalidation stuff. It seems that using the built in hooks of validation, default, etc might be more truble than it is worth and one should just handle everything yourself on Focus events.

In all honesty these are the type of "gotchas" that put me on the couch to begin with.

I also learned a lot from your stuff on promoted events. thanks

Ed,

I also learned a lot from your stuff on promoted events.

That's how I've learned a lot about the interal workings of OpenInsight. It's also why I continue to encourage others to incorporate them in their own applications.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

View this thread on the forum...