In the Codename One API, there are several methods that cointain the word "Tensile", such as isAlwaysTensile(), setAlwaysTensile(), getTensileLength(), etc.
I didn't find an explanation of the meaning of "Tensile" in the context of a mobile app. What are example of use of these methods?
Tensile is the rubber band effect you get when you drag the UI beyond the edge and it lets you. Then you release and the UI bounces back into the valid position.
This is the common behavior in iOS, on Android a highlight color effect is used to indicate the same behavior.
Generally these methods are best lest alone, they are set by the platform themes and modifying them can result in unexpected behavior.
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 would like to achieve IONIC application that allows a transition from right to left (and up to down, and others) between two pages, much like Snapchat. To switch from the main screen (the camera) in the center, to the list of snap on left and the list of stories on right.
Do you have an idea / solution to this problem?
PS: Snapchat is just one example, I do not wish to reproduce the application itself, but if you want me to examples in the basis for comparison, that's fine.
You may want to use ion-slides for transition from right to left http://ionicframework.com/docs/api/directive/ionSlides/
There should be other solutions for other type of transitions (for example https://github.com/driftyco/ionic-ion-tinder-cards) however mixing all type of transitions and in different directions might be confusing for the end user. I would suggest to stick with the standard UI controls and behavior which is clear and unambiguous for the end user.
The app I'm writing involves buttons that have a slight noise filter texture, which can be any size. For a standard button I'd simply use resizableImageWithCapInsets: but due to the texture, this causes unusual artefacts to appear on the resulting button.
A solution I have in mind, is to use the Core Image monochrome filter combined with the random noise filter to add the noise texture to a plain image. In theory this works, and in practice this has been shown to work (One example here) but these are all in cases where the button size is known at the point of invoking the CI code.
What I'm looking to do, is use the appearance proxies, so across the app I can simply set the style of UIBarButtonItems for instance.
Is there a way I can apply these CI filters to the buttons through the appearance proxies or isn't this possible? Would something like a category on UIImage to add noise work? I'm not entirely sure at which point the appearance proxy would actually invoke that code.
Any help is appreciated
OK So I finally solved it but found out some stuff on the way.
It seems you can create a category on UIImage and use that in the appearance proxy. I created a category to add noise, and it seemed to partly work, but I couldn't get it looking how I wanted as it wasn't quite rendering properly, but in the process of coding this discovered another method
resizableImageWithCapInsets:resizingMode:
Because the texture I was dealing with was simply noise, it could be tiled, so rather than the image now being stretched, the centre of the image is instead tiled which gives me the appearance I needed :)
Inside a WinForms application what is the best way to handle re-sizing controls to match based on screen resolution and maximizing and re-sizing the window. I have 3 columns that are set like this. LABEL TEXTBOX in each column. You could count that as 6 columns. I have tried anchoring to the right but the problem there is the textbox in column 1will overlap the next 2 columns. I have also tried docking but that does not seem to do the trick. Is there any easy way of doing this?
TL;DR: You can't without manually coding resizing logic. As a side note, you probably shouldn't be trying to do this.
In traditional WinForms there is no automatic way to my knowledge without rolling your own solution. Sean87 suggested the AutoScaleMode property, but while it is then automatic it doesn't support auto-sizing by resolution. It gives an option for scaling based on Font size settings in Windows or the DPI setting. Neither of these are directly changed when simply changing the screen resolution and, honestly, most typical users (and even probably power users) probably never modify the DPI or font size settings.
Besides, the whole point, from a basic user perspective, of increasing screen resolution is to give more virtual desktop "space" to place application windows in. True, most monitors are LCD-based now and thus have native resolutions that make changing this around mostly a thing of the CRT past. But still, the act of buying a new, larger monitor would let a typical user increase this virtual screen space so that they could see more windows on the screen simultaneously. An application that always maintains the same relative size to the screen resolution would be quite uncommon I think and goes against the expectations of most users, including even us advanced developer users.
Typically, you are to code your application to adjust its contents intelligently and usefully if the window is resized, but generally you defer to the user for managing that as it is their machine and their preference (think of it as the "my house, my rules" principle). This is also why most (all?) applications don't change window positions except when directly manipulated by the user (via dragging the window frame and such). In fact, all of this likely explains why Microsoft chose not to include any automatic sizing rule based on resolution.
You don't define what you mean by "column". Generally, you should use a TableLayoutPanel and inside each "cell", set the anchors of the controls.
you can change AutoScaleMode of the form and also auto size property of each control. And you might use splitcontainer or panels to form your columns.
I have developed a 1024 *780 resolution screen in Windows Forms, but some say that it does not fit properly at higher resolutions. Is there any way to handle this?
Is there a way to make Windows Forms applications look the same at ALL resolutions?
My recommendation is not so much to "make it look the same" on all screens, but rather to design the GUI so it scales up and down more gracefully. Layout managers, docking, and anchors are your friends in Winforms. The TableLayoutPanel is quite useful for this sort of thing. Splitters also help...
Finally, this is one of those problems that WPF sets out to solve. WPF makes extensive use of layout managers. It feels much more like Java or GTK than Winforms or even VB (old school VB).
This is the sort of thing that makes you say "there's got to be a better way."
My solution for this one time was to declare a global ScalingFactor variable that was tied to the current screen resolution. Then, the sizes of every visual element were multiplied by that factor.
So, if I designed my form for resolution A, and resolution B is 1.2x larger, the width of window A will be with * 1.2, the fonts will be fontSize * 1.2, the textbox dimensions will be dimensions * 1.2.
Not fun.
There may be 3rd party tools that you can buy and will perform this scaling.
One other thing to check before you run down any of these roads is whether it is actually the screen resolution or the dpi settings that are causing it to look bad. Usually a higher resolution will only make it look smaller, but an atypical dpi, such as when the user selects "large fonts" will wreak havoc.
You can use anchor property of item, and autoScaleMode property of form set it equals 'None'.