Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 10 of 17 total |
Another question: Focus control |
Wed, Feb 11 2015 9:09 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Hi everyone, another question for you:
The focus control in EWB 2 is currently a little less stringent than EWB 1, but it still gets a little overly aggressive in ways that make mobile usage weird. The situation is this: 1) When you click on a focusable control, EWB 2 "remembers" this control as the last active control for the container control. 2) If you click on a non-focusable control or an area of the container control, EWB 2 will automatically re-direct focus back to this last active active control. 3) When you close a form, and the prior form had a last active control, then EWB 2 will automatically re-direct focus back to the last active active control for the prior form when it is brought forward. I'm probably going to do away with 2) completely because it's not necessary at all anymore (a pre-HTML5 behavior in IE 8 or earlier required it). As for 3), I'm up in the air. For 2) and 3), both trigger a superfluous soft keyboard show on mobile that is no-no, so I'm thinking that 2) will go away and 3) will become a property switch. However, I'm also open to just ditching the whole "last active control" and letting the user/developer choose when/how to focus a particular control, especially since I don't want the default behavior on mobile to be wonky. What do you think ? Thanks, Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 11 2015 9:21 AM | Permanent Link |
Matthew Jones | Tim Young [Elevate Software] wrote:
> 3) When you close a form, and the prior form had a last active > control, then EWB 2 will automatically re-direct focus back to the > last active active control for the prior form when it is brought > forward. This sounds like a handy behaviour. I'm not sure what the alternative is really - go to the first or something? But if I am typing something and a pop-up happens to say "too much text" or something, then I'd want it back where I came from. Presumably a button to say "Add ten" which shows a window and then closes would be handy to have easy to repeat. If it is possible to override, then fine, but it sounds good the way it is. 2, I'd be happy to lose. |
Wed, Feb 11 2015 9:32 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< This sounds like a handy behaviour. I'm not sure what the alternative is really - go to the first or something? >> The alternative would be to let the developer choose which control to focus after a form closes. << But if I am typing something and a pop-up happens to say "too much text" or something, then I'd want it back where I came from. Presumably a button to say "Add ten" which shows a window and then closes would be handy to have easy to repeat. If it is possible to override, then fine, but it sounds good the way it is. >> Thanks, Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 11 2015 10:23 AM | Permanent Link |
Mark Brooks Slikware | I think that "ditching" is the way to go here Tim.
|
Wed, Feb 11 2015 11:08 AM | Permanent Link |
Matthew Jones | Mark Brooks wrote:
> I think that "ditching" is the way to go here Tim. Ditching all behaviour? The main thing for me is you need to know what is happening, and how you can control it. If I do a ShowModal on a form, I want to know where the focus will end up when the form is gone again. To me, back where it was before makes sense. "Nothing changed". If it is ditched, then where will the focus be, and how do I set it to where I want it again? I'd rather not have to set the OnClose for any form that I want to show. An event to indicate "child form closed" would be fine, though then I have to store state if I care about which had the last control. I'd rather the framework do that for me. |
Wed, Feb 11 2015 11:20 AM | Permanent Link |
Uli Becker | Tim,
> However, I'm also open to just ditching the whole > "last active control" and letting the user/developer choose when/how to > focus a particular control, especially since I don't want the default > behavior on mobile to be wonky. That's the best option, I think. Uli |
Wed, Feb 11 2015 2:40 PM | Permanent Link |
Raul Team Elevate | On 2/11/2015 9:09 AM, Tim Young [Elevate Software] wrote:
> For 2) and 3), both trigger a superfluous soft keyboard show on mobile > that is no-no, so I'm thinking that 2) will go away and 3) will become a > property switch. However, I'm also open to just ditching the whole > "last active control" and letting the user/developer choose when/how to > focus a particular control, especially since I don't want the default > behavior on mobile to be wonky. > > What do you think ? It would be nice to have "mobile" vs "non-mobile" based default behaviors but i do realize that just adds to the "todo feature pile". From mobile side ditching makes sense. For non-mobile ditching #3 looks like pain - unless i'm misunderstanding this one would need to write bunch of (almost standard) focus code into every form if you wish to have any keyboard usability within EWB app. Scrolling issues come to mind as well if focus set would cause the form to scroll. Raul |
Wed, Feb 11 2015 3:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Raul, Matthew,
<< For non-mobile ditching #3 looks like pain - unless i'm misunderstanding this one would need to write bunch of (almost standard) focus code into every form if you wish to have any keyboard usability within EWB app. Scrolling issues come to mind as well if focus set would cause the form to scroll. >> I'm leaning towards a conditional #3, depending upon mobile detection. Offering a property switch would simply just be offloading the same decision to the developer who will use the same properties to determine mobile usage. Likewise for the focus functionality itself, which would involve the developer essentially doing what EWB is already doing. So, no automatic focus on container mouse downs, but automatic focus on form switches (from active form to previously-active form or when showing a new form), depending upon mobile detection. Tim Young Elevate Software www.elevatesoft.com |
Thu, Feb 12 2015 4:11 AM | Permanent Link |
Matthew Jones | Tim Young [Elevate Software] wrote:
> depending upon mobile detection I read this last night on my phone (can't reply from it for some reason), and it made me wonder what is so special about "mobile"? What does it even mean any more? My applications are designed to be used on any device. The lastest version of my Connect product works on any screen from massive monitor on a desktop PC, through Chromebook, iPad, iPhone 6, to the 3.5" iPhone and Androids. Works nicely, apart from not supporting touch. I'd expect my web shop to work the same on any device, though I've not gone with support for small screens on that. I realise there may be technical differences, but I still think that what is needed is a simple and consistent behaviour from the framework. Restoring to the last focused control seems a sensible option to me. I realise I know nothing of the technicalities, but if I have to do special stuff for mobile, then it almost shouldn't do it for desktop otherwise I'll not see the behaviours in desktop testing and thus fix it for all. IMO of course... |
Thu, Feb 12 2015 5:37 AM | Permanent Link |
Rick | On 12/02/15 01:09, Tim Young [Elevate Software] wrote:
> 1) When you click on a focusable control, EWB 2 "remembers" this control > as the last active control for the container control. > > 2) If you click on a non-focusable control or an area of the container > control, EWB 2 will automatically re-direct focus back to this last > active active control. > > 3) When you close a form, and the prior form had a last active control, > then EWB 2 will automatically re-direct focus back to the last active > active control for the prior form when it is brought forward. > Tim, I'm happy for EWB2 to handle focusing automatically in both 2 and 3 above just like Delphi does. The last active control always receives/retains focus as described. Probably best controlled by a switch (form/application property?) so that the developer can choose to handle focus manually or let EWB do it. Of course, you don't want the keyboard appearing on mobile so that has to be prevented somehow. Whatever you choose to do, my one request is please don't let the memo/edit control automatically select all of its text when the user clicks outside of it (as in 2 above). That behaviour in EWB1 is a little annoying. If the focus does automatically go back to a control then text selection needs to be in the same state as when focus left and the caret should be in the same location (just like Delphi). -- Rick |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, April 30, 2024 at 03:55 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |