I was wondering if you had a way to fix the scrolling glitch with Logcat on Eclipse. Whenever I try to scroll up, the screen moves up for a sec and then goes back to the bottom.
It is really annoying and I can't get to some of my errors because of it.
You should use the Scroll Lock button.
Also, consider using the corresponding LogCat filters in order to only display the messages you are interested in.
I've experienced this as a error. Unselecting the scroll lock button will not work 99% of the time. As soon as you try to scroll the window (with mouse wheel or clicking the scroll bar up/down arrows) the scroll lock, turns back on.
Solution:
I've found a workaround, after unselecting the scroll lock, then click on a message and then press the page up key on your keyboard once and this will release the lock completely. You can now scroll with the mouse wheel and scroll bar arrows. This works for me on Windows 7.
Related
I have a very simple UI that has one entry control to enter phone number and a button. The entry control has a handler for removing border around it. When the entry control got focus, keyboard pops up. But when I try to tap outside the entry control such as on the screen empty area, the keyboard does not dismiss and the entry control does not lose focus. Also since the button is at the bottom of the screen, therefore, the soft keyboard hides it and there is no way to tap the button. The button can only be tapped if I press the Android device back button.
At present, I have not checked this behavior on an iOS device.
This was not a problem in Xamarin Forms though. I searched a lot on Internet and found that it is currently a bug in MAUI.
I tried to attach a tap gesture on the parent layout control and invoked platform-specific code to hide the keyboard but it seems the entry does not lose focus and in turn the tap gesture event is never called.
However, the entry control should lose focus automatically when I tap outside the entry control (such as on the screen) and the soft keyboard should automatically dismiss.
Please provide a workaround if there is any.
Known bug. Removing the focus sometimes helps. Sometimes you need to do Disable/Enable in sequence. (I go with the second).
If you want, you can read this for example:
https://github.com/dotnet/maui/issues/12002
(Most disturbing part, considering this is know bug for half year+)
We can leave the behavior how this is for now in NET7 and provide an
API in NET8 that lets users toggle this behavior on/off for iOS and
Android
I am writing an app with the Salesforce Android SDK.
We have a custom website that is used for the login landing page that has a username and password field.
Clicking on the first field brings focus and keyboard as expected. Clicking on the second field (regardless of which is clicked first) causes the screen to jump up and down for half a second and then leaves the screen so that you can scroll infinitely, even beyond the background image. No matter how far you scroll the scrollbar is stuck at the top. However to scroll back up you have to scroll the same distance you scrolled down.
While this is from the LoginActivity from the Salesforce SDK, I have modified the file to show the action bar at the top.
What is causing this behavior and how can I make it stop, changing zoom controls in the webviews settings does not seem to help.
The same screen in iOS does not seem to have this same behavior.
Worth noting, the defect does not appear in the devices chrome browser.
The Class in Salesforce SDK
According to the Salesforce SDK
There is a ScrollView in a WebView. This shouldn't be necessary and may cause a problem such as the one you described. Changing the ScrollView to LinearLayout should fix the issue.
Most of the time (but not always), when I finish typing in a or and the soft keyboard hides, the view area is left raised with a black space on the bottom. Clicking, tilting or otherwise engaging the phone corrects the screen. However, user's first motion is usually pressing , but if you click submit it jumps down and you actually just click on the text area again. How do you stop this and get the screen to reset after the keyboard closes.
Take a look at you AndroidManifest.xml
http://developer.android.com/guide/topics/manifest/activity-element.html
I think you need to change android:configChanges.
I have the exact same problem what i did was handle hidekeyboard even in javascript and do something like window.scrollTo(0,0) or $("input[type=text],textarea").blur();
This will cause the the screen to get back to normal position
But there is just one problem when click from input field of type = text to a input field password it internally hide the keyboard which causes the hidekeyboard event to fire and scrolls the screen to top. This is the only side effect of this
Let me know if you find the solution for this
I'm testing my new mobile website in Android devices.
But in emulator default Browser, I can't scroll down, right or left the page. There is no scrollbars, and arrow keys don't work, too. Here is a screenshot from my emulator window (I opened stackoverflow in browser)
I treat my mouse like a touch.
I left click the mouse button at the bottom of the emulator and drag the mouse to the top.
I have noticed that you need to click the mouse left button at the edge of the screen for couple of seconds to activate the scroll. Once activated you use the mouse like a touch.
If you are not able to locate the scroll bar then go back and come back again on your page. While the page is loading, the scroll bar will be highlighted for a brief period of time. You can then click at the location as I have explained above in first paragraph.
On Android 2.1, just as on most graphical computer OSes, pressing the mouse while in a button, then dragging away, then dragging back, then releasing (while within the button rectangle) would result in a button press. It would also highlight while the mouse pointer was within (or actually near) the button, going off as the pointer left the zone, then back on when the pointer returned.
This behavior allows the user to cancel, mid-press, by dragging away from the button until its highlight is off and releasing; it also allows the user to change her mind about cancelling, so long as the mouse is still down, and go back into the button to "rescue" the click.
In 2.2, it appears that Android no longer allows a return to the button. Dragging away cancels the highlight, but returning with the mouse still held down does not re-highlight the button, nor does an away-and-return click generate a click event.
So, my questions: Is this change real (has anyone else seen it)? and: Is it intentional? What is the rationale for this change, if it is intentional?
Since I tested in an Android 4.0.4, I can guess this was intentional.
My guess is that they made the change to prevent some problems with people who are not used to touchable screens. It can also be to improve usability for people with disabilities. However, I'm not Google nor know the real reason of the change. Those were just my guesses.