Now I adapt my app for tablet PC. I ask how can I fixate form when the screen was rotated. Good people says that I must adapt my app for portrait orientation and they're right.
Some forms is very specific and it's very hard (maybe impossible) to re-design they for portrait orientation. So I think I can create a illusion that my app works only in landscape orientation.
That's why I need rotate standard VCL components in Delphi XE2. For example for standard memo I need write text not only from left to right (or right to left) and from up to down (and from down to up).
Also I need rotate button. Now I use standard TButton and TRxSpeedButton.
I think enough to rotate the text for TButton but I don't know how I can do this?
In case of TRxSpeedButton I use glyphs. In theory maybe I can override canvas and change pic. Another way is create 2 buttons (one for portrait orientation, one for landscape. Each one will have their special glyph) and change their visibility. But I don't like 2nd variant because in this case exe file will be very plump, I don't like plump exe))
Thanks for advises.
You've no realistic chance of making this work using standard VCL controls. VCL controls don't have a mode that allows them to be rotated through 90 degrees. I see no easy prospect for making any control that displays text do so rotated. That's just text output. What about text input? There's also the issue of shadows and 3D effects which are based on a specific orientation. The list goes on and on.
In my view, if you want to make this work well you'll almost certainly need to write an entire GUI framework from scratch.
Whilst it is clear possible to do this it doesn't seem like a realistic choice when set aside the alternative of making your app work in both portrait and landscape orientations.
You have no chance with fake landscape approach.
There are three solutions for your problem:
Best one - make your application work with any screen size / orientation combination. This is the Windows way.
If your application "must" work in landscape mode, inform users when you detect wrong orientation, that application only functions in landscape mode. Show either message box, or special form with message that cannot be missed, while you hide your other forms, or something like that.
Lock device in landscape mode, like described in How to prevent the screen from automatically rotating on a tablet? But you should know that this is not the way Windows are meant to be used in Desktop mode.
The VCL was not built for this, so I dont really see that happening without major work done to the presentation layer of the RTL.
The have been skinning engines that were capable of this, but they essentially patched the RTL and took over rendering. Rotation data was held in a lookup table for each control that you had to set separately from the actual class.
If Delphi had support for partial classes like Smart Pascal does, then perhaps (if the architecture allowed it) this could be postfixed. But as of writing the VCL is simply not made for this. I am writing a tweening library as I type this, so I have looked into this.
One way that might work for you would be to use the PaintTo method of various controls. Have them paint their fully drawn image onto a bitmap and then rotate the bitmap by 90 degrees to get the portrait versus landscape effect. Then draw that image on the canvas of your form in its OnPaint method (you would want to make the actual controls invisible when in the portrait mode, showing only your painted and rotated bitmaps.)
There are some controls (like TRichEdit) whose PaintTo Method doesn't work correctly, though. So this may be of limited use for you. Another way is to grab a screen capture of the entire client area of the form on the desktop and then rotate and display that. that works even with TRichEdit...
Related
Recently I was asked to adapt to large-screen phones because the standard mode view looks too small on large-screen phones. So I thought of a simple way: display the zoom-in view in the standard mode of the large-screen phone. But i can't find a good way to realize it.
The original idea was to set the currentMode setting of UIScreen, but iOS does not support the creation of external UIScreenMode...
If you are not using a storyboard, use code with frame. You can use masonry, use multipliedBy. If you don’t change anything code and want to directly adapt, that’s unlikely.
When an app is running in a third of an iPad screen, there is a small drag handle at the top of its window. In iOS 10, dragging on that handle lets you switch what app is open there. In iOS 11, you can use it to change the app from taking up a third of the screen to floating over the rest of the screen.
My question: how do I know when this handle is present, or at least know that there's something taking up that space? I need to lay out my UI content around it without conflicting with it. It doesn't appear to work with iOS 11's Safe Area APIs.
See here for a sample project trying to put a label at the top of a window without overlaying the drag handle. Run it in a third of an iPad screen.
Start by duplicating the radar. This is definitely something that should be handled by the safe area magic.
The issue here is that the handle is rendered by SpringBoard, so you can only apply tricks to guess whether it is currently visible. You can determine whether the window is at the right size and whether it is at the correct location on screen, and then add some extra safe area insets. This is normally ill-advised for several reasons, such as not knowing all cases where the handle appears, having to take into account left-to-right systems, etc., but in this case, the problem seems so egregious, I'm not sure I'd recommend leaving as is.
Edit
One more option is to see if UIWindow.safeAreaInsets returns a correct value. UINavigationController is able to deduce the safe area correctly, so it is hiding there somewhere.
I'm taking a few first steps in Xamarin for iOS and having a very hard time figuring out how to create a view that is resolution independent.
I have a single textbox in the view, aligned so that its edges meet the edge of a iPhone 6S. When I change the View to a Iphone 4S the edges of the textbox are outside of the view.
I have tried to drag the constrains to the edges, pretty much clicked every button and tried to find some example of how to make it so the view resizes to fit the viewport but I cannot make it work. Ive also fiddled with the different modes of the View (Aspect Fit, Scale to Fill, etc) but that makes no difference.
I would love to se a simple example of how to create a resolution independent or multi-resolution form or view that is displayed similarily no matter the screen resolution on the iPhone.
Having gone through very much the same pain as you, my recommendation is two-fold:
Have a look at the Cirrious FluentLayouts package, which you can
get from NuGet.
A tremendous help in simplifying various issues with auto-layout, especially if you decide (like I did) to just give up on the GUI layout tools and go with a full programmatic approach.
It will allow constructs like:
this.AddConstraints
(
_navBar.AtTopOf(this, UIApplication.SharedApplication.StatusBarFrame.Height),
_navBar.AtLeftOf(this),
_navBar.WithSameWidth(this),
_navBar.Height().EqualTo(Hamburger.HamburgerHeight),
_scrollView.Below(_navBar),
_scrollView.AtLeftOf(this),
_scrollView.WithSameWidth(this),
_scrollView.Bottom().EqualTo().TopOf(_pageControl),
_pageControl.Above(_toolBar),
_pageControl.AtLeftOf(this),
_pageControl.WithSameWidth(this),
_pageControl.Height().EqualTo(pageControlHeight),
_toolBar.Above(_button),
_toolBar.AtLeftOf(this),
_toolBar.WithSameWidth(this),
_toolBar.Height().EqualTo(toolHeight),
_button.AtRightOf(this),
_button.AtBottomOf(this),
_button.Height().EqualTo(buttonHeight)
);
Be aware that since... iOS 8 I believe? ... you now need to use a
LaunchScreen.xib to have your app correctly pick up device
resolution which will then be used by auto-layout.
This was the one area I still needed to use the graphical layout tool for - just once, happy to say.
I'm refactoring one of my apps from the iPhone to the iPad and this has resulted in the removal of tabs as I've been able to combine functionality onto 1 screen and use popovers to enable the user to select stuff that previously required a new tab.
I'm basically left with 2 tabs now. One (which is best viewed landscape) shows a map of the world with some overlays drawn on it plus an indication of where you are. The second is a data display with a few graphs which is best viewed portrait.
I note what Apple say about requiring apps to run in all orientations on the iPad, and of course I could do this, and keep my 2 tab bar buttons to switch views.
HOWEVER
In this case, there is 1 view that is best suited to landscape view and 1 view that is best suited to portrait view. Would be be appropriate (or even Apple permissible) UX design to drop the tab bar and switch views on an orientation change instead?
From a user perspective, you wouldn't need to be switching back and forth much, you tend to use the landscape view to change location (if you need to) and then work mainly in the portrait view - so I don't think it would be frustrating and dropping the tabs seems to make more sense to me.
What do you think? Any best practice in these situations?
Roger
London
I would say that the best practice is not to restrict the orientation of views.
The central idea here is not to force the user to hold the device a certain way. For example, a lot of people use iPads in a stand or holder and input with a keyboard. Do you want to force your users to stop and physically adjust the device in the holder/stand before they can read the view in the other orientation? Other people simple prefer holding the device one way or the other and lock the orientation (I do that a lot.) Forcing users to change from their preferred device orientation won't win you happy customers.
Apple will not penalize you for a non-standard UI unless it reflects badly on the device itself. As long as the end users can tell it's your apps non-standard behavior, Apple does not care. However, in my experience, end users tend to interpret non-standard interfaces as flawed or broken because they don't understand them.
In this case, if I launch your app for the first time, how am going to know that changing orientation changes to another view altogether and another data set? Nothing in the standard UI teaches me to expect that. I will have to discover it by trial and error. If I have the orientation locked, not even trial or error will help. At that point, I might well conclude that the app is broken.
You could try adding instructions but just the thought that they might be necessary is a red flag for a potentially poor UI.
For accessibility purposes, I need to make the scrollbars for all scrollable controls (lists, list views) wider and the scrollbar arrows bigger.
How to get the scrollbars (handles) from a scrollable control (ex: TListView) ?
How to make the scrollbar and the arrows wider/bigger ?
10x for any hints and code...
Accessibility is something that does not concern a single application, but the whole system. That's why there is no API defined to adjust things like border widths, scrollbar size and similar properties of the native controls only for your program. You can however adjust these settings globally in Windows, either by using the Accessibility Wizard, or by adjusting fonts, colours, border sizes and scrollbar sizes in the Display Properties applet.
For more information you should check out the Microsoft Accessibility page and follow the various links.
Edit: Changing the global settings (as the accepted answer suggests) for the benefit of your own program is rude in the extreme. Please keep in mind that this interferes with all other running programs. It is maybe excusable for a system with a touch screen, where controls need to be large to be usable at all - but on such a system the control sizes would probably already be set correctly.
I'm not sure that you can - You have to change it (and restore back) for whole Windows.
http://www.greatis.com/delphicb/tips/lib/system-captionfont.html
Setting and reading property TNonClientMetrics.iScrollWidth
Edit: I know that this solution is rude, but in common cases is the best that you CAN do. If you have specialized TabletPC application then you usually use only that application at one time, not others. But - almost all Windows applications are not designed to work with so big scroolbars. So when you need to use OS dialogs and other applications then you have to switch it back.
There is no better solution than "while is my touchscreen application running set Window scroolbars big, then return it back". We have exactly this application in real world so I know what I'm talking about.
Of course you can write your own grid control (if you have so much time) or use some thirdparty controls (if you have money and time), but that was not question.