I am revisting my attempt to get the background color of prompts and edittable cells to change when the cursor is in lostfocus/gotfocus.

(As I set the background colors of columns of EDITTABLE in a promoted create event depending if required or protected, i was having problem finding how to get my orig colour to be able reset back, then, accidently discoved that if colour is null in color_by_pos then it will go back…docs are not clear on that)..anyway…

The problem i am now having is when a validation error pops up and returns focus to the lostfocus prompt/cell , the orig gotfocus prompt/cell is still the new backcolor and the new 'error' focus cell is not.

So i need to be able to capture this "EVENT". What event/events do i use to know this has occured.

How have others got around this.

I usually set @props on where I was and where I was going to on the lost and gotfocus controls. Lostfocus has a parameter on where the system is going, and gotfocus on where it came from. By tracking them, and itself on the form, when there are errors and controls are popped back, things can always be found.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Doesn't the window control have the prevFocus?

The "error message" doesnt generate a got focus when it returns bach to the prompt.

Are you saying this effect is not a problem in your systems using your method.? Any idea what event would be generated during the "VALIDATION" process.

Barry,

The underlying problem is that OI is not firing the GOTFOCUS event when the failed validation returns focus. In and of itself that's a good thing. Otherwise a whole mess of other problems can (and would likely) occur. So what you are looking for is a way to trap an "event" that is connected to a validation error.

In theory, the SYSMSG event should suffice. The docs suggest that the msgCode parameter will be populated with the appropriate value based on the IO logic that created the warning. It even lists VALIDERR$ (cf. PS_EQUATES) for data validation errors as one of those values. However, we have never gotten this event to work for validation error (and many others in this list as well).

As far as we can tell, validation checking is handled by the LOSTFOCUS system event handler. However, it doesn't seem to call the SYSMSG event at all. So we suspect the fix needs to be done in the LOSTFOCUS system event handler.

The only solution I can offer is to "promote" your LOSTFOCUS event so that it executes after the LOSTFOCUS system event handler. My guess is that your current promoted LOSTFOCUS event is keyed like this:

LocalApp*LOSTFOCUS..OIWIN*

This executes prior to the LOSTFOCUS system event handler which is keyed like this:

SYSPROG*LOSTFOCUS..OIWIN*

Therefore, your event key needs to be even more "generic" to execute after the system event handler. All that is left is this:

LocalApp*..OIWIN*

We refer to this as an application level promoted event. It will execute after event specific system handlers and prior to the SYSPROG application level promoted event (i.e. SYSPROG*..OIWIN*) which is where QuickEvent processing is handled.

Since this event handler will execute after the LOSTFOCUS system event handler, any validation errors will prevent this code from executing and your logic to remove the background color will not interfere.

One final note, since this promoted event executes at the application level (i.e. it is not event specific) it will capture all enforced events. This is a good thing because it allows you to promote virtually all events in OpenInsight with one promoted event. If you require pre-system event handler processing (e.g. READ, WRITE, DELETE, etc.) then you still need to create your promoted events in the typical way.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Great, Thanks, I will play and report back.

]]LocalApp*..OIWIN* ….Generic event processing

How do you know what the event is and what are the parameters…or have I missed something

Barry,

Many many code years ago, my good friend Oystein helped me with this problem. Here's a link that may get you going.

Maybe this will help.

HTH,

Ray Chan

P.S. Oystein, if you're listening, thanks buddy! Hope to see you soon.

oh yeah .. great reminder .. thanks

Don,

The Revelation community regards you as the authority on event processing methods. Will this event calling information be added in a revision to your famous white paper?

Regards,

Gerald

Hey, if I remember, you'll be in BBQ territory soon.

Drive safely and take care.

Ray

No way man .. i wised up (must've been too much grey goose) ..

How do you know what the event is and what are the parameters…or have I missed something

To get the current event use Event=Get_Current_Event().

You will need to provide enough generic parameters for all possible events. We just name them as Param1, Param2, …, Param13.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Barry and Ray,

Oystein's code will not resolve the problem when a validation error restores focus back to the control. However, it did give me an idea for another workaround. By using the Forward_Event() subroutine (as Oystein does), this will allow you to call the system event handler prior to your own promoted LOSTFOCUS event logic. You can then use the Get_EventStatus() to determine if there were any problems and go from there.

The benefits of an application level promoted event are numerous so I still recommend going in that direction. However, this is an easier and quicker way to get your problem resolved.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Gerald,

That accolade is appreciated, but I must confess that I am standing on the shoulders of giants (I think we ALL are in various degrees).

Regarding a white paper, we've actually had a new one published for quite some time. Kevin wrote it in preparation for his presentation at the last User's Conference. For a variety of reasons we haven't released it yet but we plan to do so very shortly. It will cover this event calling method. In fact, the R&D that went into this white paper became the basis for how FrameWorks was redesigned from an event management point of view. I covered this during a SoCalRUG meeting earlier this year and hope that I can make a presentation of this technique at the next User's Conference.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

OK,

Got the prompt tabbing working correctly (no color change if error) using the application level event.

But the same 'logic' does not appear to work for the POSCHANGED event.

Barry,

Are you using a promoted POSCHANGED event to to facilitate the cell color coding? If not, where is this logic?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Yeah, but old habits die hard.

And, without having event script, there are times when the quickevent might not be called, and, well, I like to know where things are most of the time. Now…where'd I leave those marbles….

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I probably shouldn't post when I'm this sleepy, but validation should happen in the generic lostfocus logic, so I think it would happen after your event script, but before the quick event. In any event, a failure would not generate a gotfocus on the new control.

support@sprezzatura.com

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I created a LocalApp*..OIWIN* promoted event

where I put LOSTFOCUS, GOTFOCUS and POSCHANGE for the colourisation.

LOSTFOCUS is unsing PrevFocus to reset to orig colour.

I know what the problem is. The error message is coming from my ssp in the CHANGED event where I just set SELPOS back to prev focus and null the cell. I dont normally set any event status as I have not had any reason to.(which I assume what the problem is..as If create a dummy validation in the window, then it works fine.)

Looks like I have an extra line of coding to add in my ssps' if I want this to work properly.

"Ah , but the strawberries ! That's , that's where I had them ."

OK guys,Whooo Hoo - I take back this bit:

"I dont normally set any event status as I have not had any reason to.(which I assume what the problem is..as If create a dummy validation in the window, then it works fine.)

Looks like I have an extra line of coding to add in my ssps' if I want this to work properly."

The screen I was testing it on is a conversion from AREV I did. written by a 3rd party(Arevcode). They had a utility("FLUSH") in the error message routine. Took that out and it now works in an edittable.

Barry,

Glad to see you solved all of this problem. The issue of GOTFOCUS control settings is not at all trivial due to the nature of event synthesis, but who would have known about the "Utility" call? Now I am just slightly curious – in my AREV code, which was (almost) never released, I had a 'Utility( "FLUSH" )' programming feature. So who did your 3rd party coding? Hmm…

Gerald

]]So who did your 3rd party coding?

A company in australia over many years and many people.

It is an Auction System.

Looking back at the orig AREV code it was a FLUSH they had and I blindly converted it to utility("FLUSH") forgetting it was flushing events and not memory.

Undoubtedly, This call represents just a weird coincidence of code convergence.

Barry,

Aah! Not blind convergence after all – more like an even a blinder blunder. I had some issues with OI conversion because I used program names like UTILITY and XQ in my AREV code. Similarly Linux people detest Windows because of the tens of thousands of name declarations. Well, I wish you great luck in your conversion.

Gerald

View this thread on the Works forum...