Can someone explain this contradiction. If you look under certain controls at focus , as in gotfocus and lostfocus, under for instance bevelbutton, you will find also a property AcceptFocus. If you do the same under textarea you will find both gotfocus and lostfocus, but no AcceptFocus. There is apparently a definition like “by default”. However if you “have focus” on a textarea during debugging and look at the window the control is on - the property focus is nil. How can this be?
I have a lost focus that is firing after I’ve clicked on a menuitem. I am thoroughly confused.
Per that LangRef… only 6 controls have an “acceptfocus” property… BevelButton, Canvas,ContainerControl, DisclosureTriangle,Scrollbar and UpdownArrows,
What “Focus” property are you referring to?
When a control has “focus” then it is the currently selected control. When you click on a menu item, I would expect focus to leave (and therefore LOSTFOCUS to fire) on a Textarea… you just clicked on another control and now the MENU has the focus
Not disagreeing on the 6. It’s just that XOJO treats the textarea via a menu click differently than RB did. In RB 2012r2 and before, if I have code in the textarea control’s lostfocus it wouldn’t be activated by a menu click. Now it does.
(I forgot to check in the previous version about which control has focus, sorry.)
Now the menubar is activating lostfocus and I’m not sure how to control the menuitem since focus and therefore, by my coding, text that was selected is no longer selected. My question is really how do I keep my code in lostfocus and my code in the menuhandler. Sorry if this is confusing.
I guess another way to look at this simply is before copying text from a textarea via a menuitem, my lostfocus is activated and by coding there’s no text to copy, because nothing is selected because lostfocus is activated.
Sounds like a bug. Please file a feedback report.
I had to add Me.SetFocus to the MouseEnter event in various controls after Xojo 2013r2 for scrolling to work properly in Windows. You may have to do something similar to work around the problem by adding code to the relevant TextArea events.
I sort of found the answer. I actually had filed a bug but couldn’t explain until last night. In 6.2 lostfocus is called after the menuclick. In xojo it is called before it enters the code