I have a couple of edit tables in the same window and both have an event handler defined for their GOTFOCUS event.

When I click in an edit table, I need to know which previous edit-table had focus. The GOTFOCUS_CONTROL property of @window reports correctly the name of the first edit-table I was in but then keeps reporting the same name when I click immediately afterwards in the next edit-table, i.e. consecutive clicks in different edit-tables keep reporting the name of the first edit-table.

Example: when I'm in the 1st edit-table, I click in the 2nd edit-table. GOTFOCUS_CONTROL reports correctly the name of the previous control. Then if I click once more in the 1st edit-table, GOTFOCUS_CONTROL does not give me the name of the 2nd edit-table but insists on reporting the name of the 1st edit-table.

A) Is this a bug?

B) Is there any event that literally reports every position change? I have tried working around this situation with no luck.

Thanks for any help suggested.

Godfrey,

Your GOTFOCUS event has a parameter called PrevFocusID which may work better. However, this is supposed to return the last value of GOTFOCUS_CONTROL so it may not work any differently. FYI, the Programmer's Reference guide says that the GOTFOCUS_CONTROL "Identifies the last control on the window that had an event handler defined for the GOTFOCUS event." So, unless every control has a GOTFOCUS event this method may not work for you.

We have a promoted GOTFOCUS event that always sets a user-defined property with the name of the control that got focus. This is how we always know the previous control with focus.

[email protected]

SRP Computer Solutions, Inc.

Godfrey,

Don's suggestion of using a promoted GOTFOCUS event sounds like what you need.

But perhaps there are other ways. Even though it's difficult to know since you haven't told us what this clicking business is about.

But let's say the purpose is to move or copy data from one edit table cell to a cell in a different edit table. The user first clicks a source cell, in any of a number of edit tables, and then a target cell, in any of a number of edit tables. After that the user is free to click a new pair of source and target cells. Etc.

Or perhaps the purpose is to establish a relation between two cells, or a relation between the cell's values, or similar. Again with pairs of clicks in source and target cells.

Then my naive question is: Couldn't you make do with a CLICK handler for each edit table, and a couple of global variables or window user defined properties to keep track of (1) which cell/value was clicked (NOTIFYPOS), and (2) if it was a source cell or a target cell (every second click will be a source click, every second a target click).

You must of course have something to initialize the thing so the first click will be correctly interpreted as a source click and not a target click.

Now you might object that the user can click other controls too - not just the edit tables. You don't want to allow the user to click somewhere else inbetween the source and target clicks. A click somewhere else after a source click should be interpreted as the user aborting the process, cancelling the source click. Is that it? The consequences being you need handlers for every single control in the window?

If so - are you really sure the program must be that strict? What if you had some control(s) that clearly showed the state of the system - if it's waiting for a target click or not? E.g, if the purpose of this clicking business is to copy values from source cells to target cells you could have some control(s) representing a clipboard at a visible and central place above the edit tables. After the source click the program should show the source value in the clipboard control(s). After a target click the clipboard should be emptied. The clipboard control would clearly tell the user whether there was a value waiting to be pasted. Even if the user sidetracked with clicking in other controls after a source click, the contents of the clipboard would remain, alerting him to the fact the system was still waiting for the target click. If the user really wanted to cancel the process, there should be a separate button or something for that.

Even if you choose to solve the problem with promotional events (which I have no objections to whatever) my idea of a visible clipboard or similar thingamajig to show the current state of the clicking process might be a good idea.

- Oystein -

PS. I assume this was quite a long response being based on so few facts…

Hi all

I had some events that needed to know what control previously had focus before I got to this one. So long as my spelling held up the following stuff worked.

Focus ID for got focus and lost focus events

ie jump to

http://www.revelation.com/WEBSITE/DISCUSS.NSF/09d90959a1a106db8525652c0042cb86/40E5E9388D071165852567300074C41E?OpenDocument

Scott, LMS

I would suggest that you set a common variable, or @USER variable to the control id when you lose focus on the edit tables.

This way, you can control it manually, and just check this when you get focus.

Colin

Thanks everybody for your information. It has enabled me to achieve my objective.

PS. I assume this was quite a long response being based on so few facts…

Not if you have "delirium" ;0

Bånnski!

Ray

Ray,

I'm still saving it. Can't bring myself to open it. It's just too cute. Think the posting was fuelled by some local brew.

- Oystein -

View this thread on the forum...