Hi All

I need to:

during a LOSTFOCUS event, test for a forthcoming CLICK event from another control.

I am currently:

On LOSTFOCUS testing for a value change by comparing the current value against the GOTFOCUS_VALUE. This has worked well up to now.

I am now using a "browse type" button to the right of controls for my mouse loving users, which fires the OPTIONS event. The name of this button is controlname:'_BROWSE'. Currently i am testing for current focus of controlname:'_BROWSE' and if true do not continue (and do my search). This is flawed if the button control is the next tab order as validation will not occur. Generally this should not occur as these browse buttons are placed last on a form tab-order so the user can quickly skip through edittable controls. However, what I really should be testing is whether the user has pressed the associated button (ie. fired its CLICK event), rather than if it has focus.

Is there a way to do this? Thanks for any ideas here.

I've included the generic function for info:

COMPILE FUNCTION LB_MODIFIED(CONTROL)

DECLARE FUNCTION GET_PROPERTY

WINDOW=FIELD(CONTROL,'.',1) 
IF INDEX(CONTROL,'.',2) THEN
  CONTROL=CONTROL1,INDEX(CONTROL,'.',2)-1    ;* remove radio button setting
END
CHECK.VAL=GET_PROPERTY(CONTROL,'GOTFOCUS_VALUE')
CURRENT.VAL=GET_PROPERTY(CONTROL,'DEFPROP')
MODIFIED=(CURRENT.VAL # CHECK.VAL)
IF MODIFIED THEN
  IF GET_PROPERTY(WINDOW,'FOCUS')=CONTROL:'_BROWSE' THEN
    MODIFIED=0
  END
END

RETURN MODIFIED

The better solution is to remove your browse buttons from the tab order completely. You can do this using the NEXT property. Just set the NEXT property of the last edit control before your browse button to be the first edit control on your form. Then you will have a tab order (forwards and backwards) that will avoid hitten your buttons altogether.

There is no way to detect a forthcoming event from within another event. The best you can do is detect which control has focus, just like you are already doing. Sometimes we have to create our own custom validation routine in order to avoid the unilateral validation that some built-in techniques enforce.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Thanks Don,

That will work. While I am on a roll, do you know if there a way to programatically check the taborder of window controls - specifically those on a particular page?

Regards,

James.

James,

You might first need to know which controls your window contains. For that use the CTRLMAP property, which "returns an @FM-delimited list of control identifiers, as they apply to the specified window." (Quote from the online docs.)

Then you can check the tab order by looking at the NEXT property of each control. NEXT "returns the next object in the tab order." There's also a PREVIOUS property.

- Oystein -

Hi Oystein

Thanks for responding. I am familiar with these properties and functions. It would be handy to gather a list of controls for EACH page within a window. eg. for tabbed window controls, as well as my browse buttons logic.

I just did a bit of checking and thought perhaps I could:

1. check the SIZE of the window against the vertical position of each controls (ie INT(GET_PROPERTY(window,'SIZE')/GET_PROPERTY(control,'SIZE'))+1 but the window size returned appears to be less any menu + titlebar so this doesn't work very well..

2. In the SYSREPOSWINEXES record there is a value in the 6th @vm delimited position for each control which seems to list a page delimited by a colon? I don't suppose anyone knows if this is the case?

Any other ideas appreciated…

Thanks again,

James.

James,

You're wrong about SIZE. SIZE is including borders and stuff. CLIENTSIZE is without.

- Oystein -

Hi Oystein,

Thanks for that, I should have done more research before guessing. The reason I said it was because of the unexpected (to me) vertical origin position SIZE property of controls on subsequent pages. eg. I have a window 416 pixels high (SIZE), CLIENTSIZE 370. If I check the SIZE property of a control at the top of the 2nd page it returns a vertical position of 721, a discrepancy of around 300. This additional 300 odd pixels seems to occur between the end of each page and the start of the next.

Does anyone know why this is the case?

And if/how this value can be calculated or if it is a constant?

Regards,

James.

James,

Some sort of twilight zone? Gateway to another dimension? Try move a control there programmatically and see what happens.

Or perhaps it's like a stretch of no-man's land between sovereign countries. You could set up a duty-free business there or something.

I checked my only multi-page window and it seems my zone is about 500 pixels high. So I don't think it's a fixed height. My second page starts at 748 and that's close to your 721. My visible client area is 240 pixels high.

If nobody else can help I suggest you put an invisible control at the top of your second page and use that control's position in your programmatic calculations.

- Oystein -

Aha! So thats where my tax receipts went.

Does anyone else has some feedback re: this strange vertical position of controls on subsequent pages?

Regards,

James.

View this thread on the forum...