I have a window in which I have one to several labels visible, and a textfield into which the subject (this is for an experiment) is to type the response. Between trials (intertrial interval) I make all the visible controls not visible, set a timer, and then when the timer goes off, make everything visible again**[see next paragraph]. The Textfield is enabled (and also specifically set to enabled every time I make it visible again). I also specifically set its focus every time. I have also (tips picked up in other question threads) set its tab index to 0 [both in the inspector and in the code], turned usefocusring to off (to get it to stop flashing), and possibly one other thing that I read about here but am not remembering…
YET when controls are made visible for each trial [side note: in one phase the stimuli labels are made visible first and the textfield is made visible after a small delay; in another phase the stimulus label and textfield are made visible simultaneously], the textfield does NOT have focus (which I am taking to be the same as the cursor is in the textfield ready for typing to be done). Instead, the user must either use the mouse and click in the textfield, or use the tab key to get to it. (OR, if I do something else to interrupt the program, such as a breakpoint or a msgbox or switching to another app and back, then the cursor is where it ought to be.) (FWIW, it had the same behavior before I added in the setfocus setting; the only time I think it worked was back when I wasn’t blanking things out between trials but just leaving them on the screen the whole time.)
Obviously, this is unacceptable for an experiment where the subjects’ responses (including typing onset time) are being recorded, and just a pain for a subject to remember anyway. And obviously I don’t want breakpoints or msgboxes in the middle either.
Either I’m missing something simple or I’m missing something important…either way, can someone point me to the way to get this textfield to have the cursor ready for typing/have focus?
Yes, I’ve got that line of code (MyTextField.setfocus) for every time I make the textfield visible again, but am still having this behavior. (Am guessing you were not referring to clearfocus, which didn’t do anything anyway.)
…
The only thing that I’ve been able to do to make it have the focus when I want it is to leave it visible from the get go and all the time, which means that the subject can type in it even before I want them too, even between trials. To solve that problem, I have gone back to switching the enabled property on and off instead of the visible property, and changing the cue text from nothing to my original cue text to more visibly indicate when the field is able to be typed in. I also am calling SetFocus every time I set enabled to true (whereas before I was calling it when I made visible equal to true.) This is not an ideal solution (as I’d prefer the field not be visible between trials; though maybe my boss will disagree!) but it seems to now work.
So, Michel, thanks for scratching my brain enough to find a working solution though I’m guessing that wasn’t precisely what you were indicating! (and sometimes maybe one needs a youngster practicing cello in the background, too…)
And, in the process of looking at the rectcontrol page and associated pages (i.e. clearfocus), I saw the property mask, which sounded intriguing but is not what I thought it was…but it IS something I need, so thanks for making me see that, as well!
I’m not sure if the window is losing focus, to be honest, nor where they were tabbing from. The window is staying visible, and I’m just setting the “visible” property of the three labels (in which I put my stimuli) to false as soon as the subject types return to signal the end of his/her answer. And of course, now I’m not setting the textfield (in which the subject types the response) to not visible, but merely erasing what they typed (setting text to “”) and making it not enabled in the intertrial interval. Then when the intertrial interval has ended, I re-enable it AND call setfocus for it. (And reset the cuetext as well.) And there is no longer a need to tab to it.
It may well be that leaving the response field visible but blanked out (rather than blanking everything) IS acceptable. At first we were allowing the subject to start responding as soon as the stimuli were present, but then decided we wanted them to study the relationships between the stimuli, thus an additional timer actually on top of the intertrial interval, wherein the textfield is not enabled. I want to make it very obvious when they are allowed to start answering, and was doing that with the visible property. But using the cuetext in addition to enabling may suffice.
(Another thing I need to figure out…how to capture a tab key so that it doesn’t erase what they’ve already typed. In a much earlier RealBasic program that this one is based on, subjects apparently were able to end their responses with either the tab key or the return key [at least that’s how the ancient code reads ], but now, the tab key is having a different result, so I need to intercept it and make sure it at least doesn’t erase everything they did.)
Thanks for your comments. If there’s something I should be doing differently that will make for better code, I am very open to learning such a thing.
I suspect something else is stealing focus and you dont know it or see it
I’d leave the focus ring visible until you can sort this out JUST FYI
I just cant say what or why without seeing the code (these kinds of behaviours are often tricky to track down)
In a quick test I put three text fields on a window and a button that is set up to toggle these fields visible & not
toggling & setting focus works exactly as I expect
You make it sound as you are reporting an issue from the field.
Have you tested the issue yourself ? It is pretty easy to see if a window is active, or if you have a doubt, simply click on it’s bar.
You can also use some declares to push your window on top if needed. Another excellent way of preventing the window from deactivating is to make it modal. Or, as often used in educational programs, make it full screen (“kiosk mode”).
Norman suggestion is to be checked as well. Maybe another control is stealing focus. You need to track what is going on.
Use these events of the window :
Sub Paint(g As Graphics, areas() As REALbasic.Rect)
if self.focus <> nil then
system.DebugLog me.focus.Name+" has focus."
else
system.DebugLog "No control has focus"
end if
End Sub
Sub Activate()
system.DebugLog "Window activate"
End Sub
Sub Deactivate()
system.DebugLog "Window DEactivate"
End Sub
You will see the results in the messages pane. Click the third icon at the bottom of the IDE.
That way you can track when the window is active or not, and which control has the focus.
Sorry for not responding earlier; I wasn’t at work yesterday and not able to try the things suggested.
To Michel: I’m not reporting field problems; this program is still in development (and has plenty of other parts not yet even implemented!) Right now it’s just me testing out little bits as I bring them into the program. And what I described above is what I was seeing when I tested. (And I really cannot afford to have any problems at all when it goes into the field, because then we would lose subjects at a huge rate. So I have to get it perfect now. Or at least perfect enough to run with subjects and not have them crash it!)
Anyway, even though I was able to get a reasonably working alternative by just leaving the textfield visible the whole time, my boss and I agree that the ideal would still be to have all the fields on the screen (the labels that are stimuli, as well as the textfield where the subject types the response) go invisible during the intertribal interval, and for the textfield to reappear a few seconds after the stimuli are presented in each trial so that the subject doesn’t start typing right away. So I am back to trying to get the focus to go to that textfield as soon as I make it visible and enabled. I’ve just gotten back from discussing this with her, and haven’t had a chance yet to try to use the helpful suggestions from Michel and Norman and Richard above. I’ll update after I do so.
To Norman: When you say “I’d leave the focus ring visible until you can sort this out” do you mean have “UseFocusRing” set on or true? (I was advised in a different thread to turn it off to eliminate a very annoying visual effect that happened every time the textfield got focus.) Will having that on help me figure out what has focus if the textfield doesn’t? I hadn’t noticed anything else having that annoying visual effect, but I suppose I could turn it back on and see. Or did you mean something else?
Thanks everyone for your responses so far trying to help me figure this out and understand it better!
(I only work part-time, and am the only one working on this. Sometimes I’m able to work on it a little at home, but I might not get back to it until next Monday after I finish today.)
Carolyn, what I posted with System.debuglog will let you know real during execution which control has focus, and if the window is active. Note that on Mac you may need to click on the IDE to have the messages display in the pane.
[quote=200664:@Carolyn Buck-Gengler]To Norman: When you say “I’d leave the focus ring visible until you can sort this out” do you mean have “UseFocusRing” set on or true?
[/quote]
Yes
until you can sort out why the field isn’t getting focus as you expect
[quote=200664:@Carolyn Buck-Gengler] Will having that on help me figure out what has focus if the textfield doesn’t?
[/quote]
It might
At least you can tell for certain whether it has focus or not with the focus ring
Had a wee moment to work on this at home and try what Michel suggested. (Especially since my boss and I decided to go back to make it not visible until partway into the trial, and that’s when the problem I described at the beginning occurs.)
(Also had to turn off full screen to be able to see the IDE, but once I did that, I can see the results of putting that code in, that is, I can see the debug log. This is going to probably be a helpful thing to know about. THANK YOU. Haven’t needed it in 13+ years of RB and now Xojo programming, but it looks like a tool that could save me time over other ways I’ve done debugging. New tools are good.)
And indeed, what I see is “Window Activate.” followed on next line by “No control has focus.” The behavior of the program is back to the behavior I described at the beginning: the textfield is not able to be typed in until I either click on it or push the tab key, and no control has focus. When I click on it or tab to it, then I get repeated messages of “SubjectResponse has focus.” (up to 4 per second, more when I am typing a response)
The code that makes the textfield visible (after 3 seconds of the rest of the items being visible), is in a timer (set in the other code that makes the rest visible), and is as follows:
Other: UseFocusRing is currently on, per Norman’s suggestion. I don’t see any odd visual behavior until I click in or tab to the textfield.
basic summary of this window:
when it is first opened, do basic setup
call intertrial timer to make it wait for a second
intertrial timer, when it goes off, gets next trial’s stimuli and makes them visible and sets timer for 3000 ms – wait period before making response textfield visible
ResponseVisible timer does the code posted above.
once the subject types in the response field, everything is blanked and the intertrial timer is called again.
This goes until the stimuli for a particular phase are all used and then other things are done and this sequence is repeated for a new phase. (The program does end phases at the correct time. At least right now! I have to put in some latin square complexity to make it choose between 6 different sets of stimuli for the 6 different phases depending on which group I say the subject is in…)
Thank you again, everyone, for your interest and help and suggestions. At least now we do know for sure that no control has focus but the window is active.
Well, in the end that turned out to be a simple fix! I’m pretty sure I wasn’t using setfocus when the problem first arose (because I had just changed it from being visible all the time to not, and when it was visible all the time the order of what I was doing didn’t matter), but obviously I must have stuck it in, but in the wrong place, before I wrote the first post of this thread. (I’ve had some instances in the past where the order sometimes didn’t matter but other times did…and never before in the past had to worry about setting focus.)
Thank you everyone, and especially Michel, for hanging with me! More than one new thing I’ve learned here!
], but now, the tab key is having a different result, so I need to intercept it and make sure it at least doesn’t erase everything they did.)