Title: Disable auto scroll to focused field Post by: Anderson P. on September 11, 2015, 04:40:19 pm Hello
In the Genero's web interface, every time a click on a button or on a folder tab the web browser automatically scroll to the focused field. For example, I have a web interface with some statistics at the top and a folder with some input field right below. I would like to keep the scroll on the top of the page, so the statistics will be visible while the user input the data, but occurs that the browser scrolls to the inputs, even they fitting on the screen with the statistics. I don't know if it's a browser behavior or a GWC configuration, but you guys know some way of disabling this behavior? Thank you in advance! Title: Re: Disable auto scroll to focused field Post by: . on September 15, 2015, 04:41:20 pm Hi Anderson, There can be some solutions modifying js files but it depends on the GAS version / mode you use and also your application type. So what is your GAS version ? And can you send your program ? (or contact your support center with it if you don't want to share it here). But let me warn you that handling focus may give some side effects, so it needs to be done carefully. Regards, Guney Title: Re: Disable auto scroll to focused field Post by: Anderson P. on September 15, 2015, 06:24:03 pm Hello Guney
Thanks for your reply! Yes, i'm already in touch with our consultant for Latin America, Florencia. We are using GAS version 2.50.29, actually the application i'm implementing is a full service desk system, so the project is a bit huge and complex for just a test case. So, i was looking for something like a property "disable auto scroll", but as i said, actually don't know if it's a browser or a GWC behavior. I have noticed that if a keep the focus on a specific field on the top of the page, it will not scroll. Title: Re: Disable auto scroll to focused field Post by: Reuben B. on September 16, 2015, 12:35:25 am Quote ...so the project is a bit huge and complex for just a test case... I'll just comment on that, you should always be able to break a problem down to a smaller test case. So for something like you have described, my test case would be the code at the end of this post. The key points being a form that is taller than a screen, and an INPUT that takes you to the bottom of the screen when you want the top to remain visible. Sometimes for a test case you can start with the code from FGLDIR/demo. Also with simple test cases. you will sometimes find that as you prepare the test case you will find the magic line that is the difference between your production example doing what you expect and not what you expect. Anyway sounds like you have hit upon the solution of putting a focusable field at the top of the page, my example shows a styles technique where you can make that field practically invisible. My first thought was that you should be able to use the ui.Form.ensureFieldVisible method but as the test case shows that doesn't work in this instance. It is designed for widgets like FOLDER to ensure a certain page is visible and AFAIK does not have ability to move scrollbars, perhaps it should ... ensureFieldVisible.4gl Code
A stylesheet ensureFieldVisible.4st Code
and 2 forms ensreFieldVisible.per Code
ensureFieldVisible_dummy.per Code
Title: Re: Disable auto scroll to focused field Post by: . on September 16, 2015, 11:42:15 am Hi Anderson, To answer your question, scrolling to focused item (I guess it's an editable field) is not a GWC specific behavior. I think you should get quite the same behavior if you run the program with GDC client. Also, you should see the same with the google homepage for example; if page height is small enough, focus and scrollbar will be set on the edit field. Anyway, you can either modify your application to add a focused item on the top, or modify GAS js files to force it. But this needs to be carefully according to your application. Regards, Guney Title: Re: Disable auto scroll to focused field Post by: Anderson P. on September 16, 2015, 01:11:48 pm Hello guys,
Thanks for the answers, agree with you Reuben, every problem can be broke down in a simple test case, and this is no exception. Your test case indeed represent the described problem, but i guess pointing the focus to a field on the top of the page is the best bet... Actually a have an input field right on the top of the page, so i will manage the code to keep the focus on that field. |