I have a Delphi XE2 Firemonkey application that I want to run on both iPad and iPhone. The iPad and iPhone real estate is different of course and I have been experimenting repositioning and resizing (visual) components according to the platform they are running on - triggered by the forms OnResize event. Started out changing the component "Margins" property with not much success (maybe that relates more to adjacent components...?) and then found the component "Position" property seems to do the job.
Question: Is the Position property the way to go? Or is there a more appropriate way using "Margins" (I seem to have read something about this somewhere, but can no longer find it). Or is there some other method, maybe not based on the OnResize event? (Yes, I am sure this is just 1 question.)
Brief details of the project - displays a costomer database record on the screen using around 30 components, mostly TLabel components, some buttons and search fields or 2 using TEdit's.
Thanks
Really depends on how differently you want to use the extra real-estate.
Do you want to display additional information, or just stretch everything out to use the space? If the latter, then you can use the Scale property.
Related
I want to build a mobile application in Delphi, but I can't seem to figure out how to handle multiple screen sizes. AndroidStudio has a nice relative layout for this, but I can't find anything alike for delphi. Am I supposed to build a multiple form designs for each screen size?
I'm using XE6, I am requoired to use Delphi as the programming language.
I have already figured it out, you have to use the Align property on every single control you add to the form.
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...
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Replacing a component class in delphi
Does anyone have any tips for modifying the VCL components and making them so they are relatively default within the IDE? This means not necessarily descending from them, but changing functionality in places that don't seem to allow such things in a descendant object. And if they can be used in place of the standard components, that's a bonus as well.
For example, one of the things I'd like to do is an alpha blended mouseover on a TButton. I notice no OwnerDraw event and the code to modify how the button was drawn seems to not be in a place that I can override. Any suggestions, or would I have to strip TButton and all its ancestors out of the VCL code and modify it directly?
You can choose one of the following methods:
Override ReadState of your form, as explained here
Use an interposer class, as explained here and here
Assign a new WindowProc, as explained here.
You are making several questions related to developing custom V.C.L. controls.
Since, its a very extended topic, you may want to browse or search the internet about it.
As a fast question, there are several ways to develop or extend a control.
Sometimes, the same control can be developed in different ways,
other, it depends the kind of control, that you want to develop.
You also mention how to make a control, interact with the Delphi I.D.E.
Delphi controls work with packages, you can make a package with plain libraries without controls, you may want to start doing that, before making a control.
You can make a control, that doesn't interact at all, and only works by running the application, and later add interaction with the Delphi I.D.E.
In Delphi, when you develop a control and want to put it on form, while designing, internally, its like Delphi was your application, and already have your control.
If you want to change the appearance of all TButtons in your application, you can do it without modifying the VCL at all. I see no necessity to modify or even subclass a VCL control yourself, when a few hundred button components exist out there. For example, for alpha-blended mouseovers, just check out the TMS controls.
However, for do-it-yourself techniques; Method one (recommended as simple) is to simply take all the TButtons out of your application and replace it with something else. VCL component replacement (globally) is easily done via gExperts. To see how to combine a standard control appearance (how a button looks) with some overlaid elements drawn in Delphi code, see TBitBtn as a sample. Rather than subclassing TButton or TCustomButton, I recommend you examine TBitBtn sources, and start from it.
Method two (not recommended as simple) is to start using a skinning system which can draw a completely different appearance over standard controls.
I wonder how difficult it would be to be able to have a custom background or be able to draw on the datamodule canvas somehow so that the relationships of all the datasets can be nicely represented with arrows and stuff. Way back in Delphi 7 or so I seem to remember some sort of datamodule designer which has disappeared (I always found it annoying anyway).
Does anyone know if this is possible through some sort of IDE plugin or something?
TDataModule is a direct descendant of TComponent, and as such, it doens't have a Canvas or any such painting provisioned in it. As is, there is no way to draw or paint on it.
It is conceivable that you could create a descendent that has a TCanvas, but you'd have to really hack into the IDE to get it to be drawn on at design-time. It is an interesting idea, however.
There used to be a "Diagram" tab on the designer for Datamodules. It did have the ability to put notes, boxes with text, and data relations. It was not very understood or used, and the feature was dropped, I guess. (Before my time at CodeGear...)
Or, you may change the datamodule to a form. Leave it visible during development, for testing, documentation and debugging; and turn it it invisible for production. On the form you may put a visio viewer component and some datagrids, accessed thru a tab rack, for quick browsing of the data.
I believe that some way to organize the components in visible groups on
screen could be nice... I have a report DM which have tons of datasets,
dataset providers and Rave DataSources (circa 40 components)....
If I could create some groups to differentiate which is used in
what report.
But this in DM designer itself, not on a separate drawing space...
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.