Hi, bit of advice needed. I have a group of 5 controls on a form with about two doxen controls in total. When focus is with any one of the five controls I want to have another window display without focus "on top". I can put the window up "on top" OK. Other than calling code from all five controls, is there an easy way of telling when focus is lost from the 5 controls and code run to destroy the "on top" window.

Sort of , I need a "LOSTFOCUS" event on the group box containing the 5 controls.

J

Jonathan,

I had a similar example once - an edit line with an options or help button. The button was there to help the user fill in the edit line. It would bring up a list of possible values for the edit line, or some other help - I don't remember exactly.

The problem was that the edit line was required, or had some validity check - again I don't remember exactly. When the user pressed the options button I wanted the system to ignore the fact that the edit line hadn't been filled in properly yet. I wanted the system to treat the edit line and the button as a group, and not act until the group as a whole lost focus.

Now wouldn't it be nice if there really was a way to group several controls into one component and have common handlers for the whole group?

There are of course OI groups, but an OI group isn't more than a dumb panel/frame for other controls - with one exception: When you set change the VISIBLE or ENABLED property of a group it affects the the VISIBLE or ENABLED of all the other controls in the frame.

So you can't have a common handler for your five controls - as far as I know. But you can have a promoted event that runs at every LOSTFOCUS, but checks what the current control is and only acts if it's one of the five. That's the closest you get.

- Oystein -

I've never tried this but I think you could force these five specific controls to call a common handler if you edit the SYSREPOSWINEXES record and change the name of the LOSTFOCUS event that each one calls to some unique event name. You would start with giving each control their own scripted event, so the event gets embedded in the record, and then just replace those events with a custom named event using the System Editor. It's a bit early for my brain right now so I can't say for certain whether the name change will lose the ability for this "group" event to be triggered automatically by a real LOSTFOCUS.

Creating the "group" event would be similar to the approach of creating a Promoted Event in that you would have to write your own code for this "group" LOSTFOCUS event and then copy the object code to the SYSREPOSEVENTEXES table.

Of course you have to always remember that this custom "group" event will get removed from the SYSREPOSWINEXES record everytime it gets recompiled.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

A comment.

Here's the promoted handler:

- What is it that lost focus? Is it one of the controls in the group?

- In that case - did it lose focus to a control outside the group?

- In that case - do the stuff.

So it's a bit like every control has its own copy of the LOSTFOCUS handler.

The ideal situation would be to have the group of controls as a new object with its own LOSTFOCUS handler. The individual controls in the group should not have any LOSTFOCUS handlers. Here's the group handler:

- Do the stuff.

This is possible in tools like HyperCard (possibly extinct) and ToolBook.

- Oystein -

Promoted Events and Editing the event pointers are techniques to route disparate events to common code. A third way is to simply call a common subroutine ( a commuter module to us Arev types ) from lostfocus of each control. What is important is to get the event-driven mindset: there may be a multiple physical events that trigger a single business event. Buttons, menus receiving clicks, controls losing focus – These controls are the receptionist at the front desk, they can process simple events that only affect themselves, but should delegate window-level events to the window or to a businees object.

In this case, you could use a naming convention, the misc property or a custom window property to identify the list of controls in the group, then have code like

Function MyWindow_Events(CtrlEntID, Event, P1, … P6)

win_name=Field(CtrlEntId, '.', 1)

ctrlName=Field(CtrlEntId, '.', 2)

retval=1

locate event in Valid_Events setting Event_pos then

  On Event_pos Gosub ....

end else

  Return 1

end

return

LostFocus:

group_ctrls=Get_Property(Win_Name, '@GROUP_CTRLS')

locate CtrlName in Group_Ctrls using @vm setting gpos then

 ... do the group stuff here

end

retval=0

….

Return

Each control can then call MyWindow_Events from the lostfocus event.

If you do not want to write a separate program, then put the common code in the windows OMNIEVENT, have the controls send OMNIEVENT, '@SELF','LOSTFOCUS' to the window.

Hope this helps,

Bob

Another idea is to work in the event itself, not the quickevent. The FocusID parameter tells you what control has focus next, and if it's the one you wish, you can execute a different branch of code.

Much easier than playing with promoted events or hacking the compiled window.

The Sprezzatura Group

World Leaders in all Things RevSoft

Thanks all.

I wrote some code following the Sprezz suggestion. Seemed the easiest, and ended up being only a few lines of code.

J

View this thread on the forum...