One of my Form contains a BrowserComponent. My Form has a non-white bcakground color (when Dark Mode is on)
No matter what I set the browser's background color to, when I showBack() the previous Form, a brief flash is shown in the space the BrowserComponent occupies
Here is a video showing this on iOS
https://imgur.com/a/QhhZ0ZY
On Android, the effect is slightly different. The space the BrowserComponent occupies is initially drawn white/gray/black (randomly) while the Form is in transition (in & out)
That seems like a bug in browser component that was probably missed due to the default background color. Please file an issue with this. If you can isolate this to a test case for that issue it would help too.
It looks like createPeerImage in the iOS port should accept a background color but it might be something else.
Related
This question is related to this other one (Android). A sample test case was also provided here
Basically, I can get past the "glitch" of losing the bottom screen under the keyboard that occurs sometimes when a single line TextField is focused by setting the TextField's bottom padding and making it a layer
But when the same glitch occurs to a multi-line TextField, each time the cursor is moved to a different line the keyboard follows the current line and hides everything underneath. I've been looking at TextArea and Component but I can't see anything there that stops this behavior. My "trick" of making the TextField a layer with bottom padding doesn't work in multi-line mode. I'm out of options, could this be enabled or alternatively is there some magic method somewhere I am missing?
Also, I've checked that calling getComponentForm().getInvisibleAreaUnderVKB() returns 0 when the glitch occurs
I think you need to re-open the applicable issue. This code is very platform specific as the virtual keyboard behavior is handled 100% within the Android port.
Android doesn't implement getInvisibleAreaUnderVKB() since the VKB doesn't work that way in Android. It resizes the screen instead to provide the additional space. It will generally try to get the top area where your cursor is. That's the chief goal.
When the screen is empty that might look problematic but when your screen is full of data we'd rather see the data than have the full text component in view. Unfortunately, the native editing code has no way to distinguish between the two cases. We might be able to come up with a workaround but with these things there are often issues/regressions.
Solution to prevent this consists in setting the Form's setFormBottomPaddingEditingMode(true);. Easy fix! 👍
I am developing app using codename one .On login screen when toastbar gets loading container moves down.
I have attached screen shot in which i have shown exact error.
If I rotate the device or simulator it produced same effect.I used border layout and value of includeNativeBool = true
Can you please let me know how to resolve it?
Thanks in advance
I have attched screen shots of my form structure
There is no scrollability in this layout. I'm also guessing you assigned percentage heights in the table layout and some nuances might change.
Container1 should be scrollable on the y axis but that might break your entire layout because you rely on problematic behaviors of table layout so it will fit "exactly" it wasn't designed for that.
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I'm seeing some odd behaviour in iOS7 with my app that only demonstrates in iOS7.
When the keyboard comes up from the bottom it pushes the screen up to focus the input box. After the keyboard is dismissed a grey space remains where it was, leaving the rest of the window pushed up. Images below will demonstrate what I'm saying.
I'm using Sencha on this webapp.
While the images show the split keyboard, this occurs for both split and non-split keyboards
I can swipe down in the grey space to bring the rest of the view back onto the screen, but that isn't a solution.
What is the cause of this behavior and how can I avoid it?
Below is a slightly modified email that I sent out describing the cause of this:
After seeking an answer for our keyboard issue but coming up empty handed I think I figured out what is going on. It seems to be related to a bug in iOS 7.
Take a look at the attached ‘normal_behaviour.jpg’ file. This shows what the split keyboard looks like from iOS 6 to iOS 8. The input field I had selected on the Apple website was near the top of the page. When I touched it the web page slid up very slightly to ensure that the input field was still visible.
In the attached ‘unwated_behaviour.jpg’ file I found an input field close to the bottom of the screen and selected it. On both iOS 6 and iOS 8 the keyboard covers the input filed, however on iOS 7 the entire webpage is slid up so you can see the input field, which is great from a user friendliness perspective, but then when the keyboard is dismissed that grey area where the keyboard was remains, and the rest of the webpage does not slide back into place.
Also of note is that once you select an input field near the bottom of the page with a split keyboard you are able to slide beyond the end of a webpage in any other website you bring up within the same Safari session. You can see a few examples of it in ‘buggy_behaviour_other_pages.jpg’.
Of course with our app we are really using a Safari webview to display pages so we are vulnerable to the same issue when using the Split keyboard. The issue does not present itself with the full keyboard.
Unwanted behaviour.jpg
++++++++++++++++++++++++++++
Normal behaviour
++++++++++++++++++++++++++++
Buggy behaviour other pages
On a WinForm with an extended borders, when i place a text on the glass area it doesn't appear right.
This is how the text looks like Status
a busy cat http://img833.imageshack.us/img833/4732/95454282.png
![form][1]
how can i fix the text to appear normally?
Text in Winforms is rendered with an alpha of 0. Which makes it transparent when you draw on glass. So you'll see the background color, not the ForeColor you selected.
Drawing text on glass is troublesome, you can't get it easily anti-aliased correctly since the background of the text isn't well defined. Note how the screenshot shows how Windows addresses that problem, the text in the window caption has a milky-white background, thus ensuring that the anti-aliasing properly blends the letter into the background.
Which is what you need to do as well. You get text drawn like that with pinvoke, DrawThemeTextEx() with the DTT_GLOWSIZE flag option. Visit pinvoke.net for the required declarations or use this project. And don't forget to provide a fallback so this window still looks decent on older Windows versions. And newer versions, glass is no longer appropriate for Windows 8.