container objects and setfocus, gotfocus and lostfocus methods

I've got a set of custom container objects that are held in a FORM.

I'd like to organise these so that, when the user clicks on one of them, it changes the BACKCOLOR property (to be a highlighted yellow).

Clearly I'm not understanding how SET/GOT/LOSTFOCUS work - can someone enlighten me?

What I've tried to do, within the custom container object class is

(1) use the .CLICK() method to execute THIS.SETFOCUS()

(2) within .GOTFOCUS, change the .BACKCOLOR property to be yellow, and do THIS.REFRESH().

(3) within .LOSTFOCUS, change the .BACKCOLOR property back to the default, and do THIS.REFRESH().

But ... this doesn't work. I've inserted SET STEP ON into each of the three methods. Of these, (1) genuinely happens. But if I try tracing the subsequent code, it looks as if .GOTFOCUS doesn't happen. And .LOSTFOCUS doesn't happen either.

I'm obviously doing something stupid here, and don't understand how these events fire. Can anybody point me towards a nice simple explanation?
Who is Participating?
Olaf DoschkeConnect With a Mentor Software DeveloperCommented:
Well, a container isn't really a control being able to get the focus.

I just did a form with a container and a textbox in that container, and put a ? line in gotfocus and lostfocus of the container. Then a second textbox outside of the container. The result is, both events run, but only once.

I don't know if this is a bug or by design, what you could do is bind all inner controls gotfocus to the container gotfocus, but then lostfocus of any of the controls is not necessarily leaving the container.

Maybe you simply setall() in the gotfocus of the other containers to reset the backcolor. Then the gotfocus binding would be sufficient:

container init():
Local loControl
For each loControl in this.objects
    If pemstatus(oControl,"gotfocus",5)
       Bindevent(oControl,'gotfocus', this,'gotfocus')

Open in new window

And in gotfocus():
Thisform.setall("backcolor",rgb(...),"container") && default color
This.backcolor = rgb(...) && yellow

Open in new window

Replace ... with the color rgb values you want.

Bye, Olaf.
pcelbaConnect With a Mentor Commented:
This behavior could be a bug in certain VFP version probably.

I am testing a simple form in VFP 9 SP2 (9.00.0000.7423) and the container back color change works for me when placed in GotFocus and LostFocus of the container object.

I'll try to attach the form and you may test it.
IainMacbAuthor Commented:
pcelba - Thanks for that. When I try running the FORM, it's asking for MYCONT.VCX. Is that supposed to be my customer container?
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Sorry for that, I've used old existing form from some tests and it uses this class library. Here it is:

Olaf DoschkeSoftware DeveloperCommented:
Pavel, thanks for the example. This works in my vfp version.

If I add this to my sample form the backcolor also changes back and forth, but I only once get the output of "?" to print. I changed this to print a random value SYS(2015) and the reason is revealed: ? does reset to the home position, so text is overwritten. If I print SYS(2015) i see the text changing every time.

So I shouldn't use ? to test an event is running. Bummer

Finally, the only events you need to program are gotfocus and lostfocus. Calling This.Setfocus() in the also works for me.

Also, Efuerte, you have one problem in debugging this events with SET STEP ON: Focus changes to the debugger window, so you don't see the normal event behavior, if you debug it.

Bye, Olaf.
Good news.

The ? output is probably directed under the last known cursor position. I am rather using Event tracking feature (even when it reports false events sometimes). Debugout could also be good.

But we still don't know where is the problem on EFuerte's form because we both are using scenario which does not work for him...

Olaf DoschkeSoftware DeveloperCommented:
"... last known cursor position". Well, that would mean the ouptu would continue in the next line, like always, somehow the focus change from container back to the form will need to reset the cursor position.

Well, I know Efuertes kind of debugging cannot work, as it moves the focus. But Efuerte should have tried without the SET STEP ON first and should not have had a problem then, which he tried to debug. Maybe some code in parent classes?

Bye, Olaf.
The last known cursor position could be always the same after SetFocus because when you set focus to the container then the first contained object gets focus and it sets the cursor position to coordinates of this object...

SET STEP ON is really not so useful in certain context (the best place is Refresh method :-) thus I am voting for event tracking.

Of course, my goal is to write code without bugs :-).
IainMacbAuthor Commented:
OK, the key word in my original question turns out to be "stupid".

Comparing your code and mine, the answer is obvious - you've got controls that can accept the focus, whereas my custom container object is all shapes and labels. Obvious really - "doh" to quote Homer.

So I've added an invisible button which is ANCHORed to cover the whole of the container.

And it all works beautifully.

Thank you!


ps - Who's Efuerte?

LOL, we both supposed this question is asking EFuerte - another EE member.

So, I am sorry and I am glad you've found the solution.
Olaf DoschkeSoftware DeveloperCommented:
Sorry, yes, I read Efuerte from pcelba and didn't look back to the original post.

Bye, Olaf.
"I read Efuerte from pcelba "

Hmm, which post it was?  :-))
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.