In my app a dialog box automatically captures a screen as a full rectangular area.
I want to change to rounded rectangular. Can I change the dialog box in theme.res in Codename One? Or do i need to write any code to change the dialog box to rounded rectangular?
I used Dialog.show() method but when i change dialog as a rounded rectangular from theme.res. so it shows changes in theme which i used but in my application their is no required change is apply. It appear same as a previous.
so tell me their is any issue or what can i do for apply changes on my all dialog?
The Dialog UIID covers the entire Form due to the way dialogs are implemented (they are technically regular forms that cover everything).
We have the following builtin UIID's you can use:
DialogBody
DialogTitle
DialogContentPane
If you just set the other two to have no border the DialogContentPane should work but won't include the title since that's outside of the content pane area. I would suggest defining the hideEmptyTitleBool theme constant to true in that case.
Our builtin Android/iOS dialogs are rounded and we used 9-piece borders to do that. We cut out the border for the DialogTitle which is rounded on top and square below and we cut out a border for DialogContentPane which is the mirror of that (rounded below and square on top). So they fit together perfectly.
Ideally we'll revisit this styling in the future as we try to make styling easier. All of this was done before our newer rounded border implementations existed and during the iOS 4.x period where the iOS Dialog design was more complicated.
Related
I am trying to heavily customize a menu strip, and have made good progress with most of it. See below for customized rounded corners on hover (OnRenderMenuItemBackground)
I have already overridden the ProfessionalColorTable and ToolStripProfessionalRenderer to get a lot of the themeing
The last bits of customization I am struggling to implement are for
The location of the drop-down. It is currently a few pixels to the right of where I would like it to be (most likely due to some Marging/Padding on the ToolStripMenuItems), as well as too high. Is there a particular property I can override to set the location of the drop-down (and sub-drop-downs)?
The corners on the drop-down are sharp 90 degrees. I want to modify these to be smooth rounded corners like on my hover/OnRenderMenuItemBackground. What property is the best to override to do this?
I'm using the default theme, which I understand is effectively the theme for the platform.
If I put my menu items in the side menu, they show up way too small. If I put them in the overflow menu, the show up way too big. I don't know the UUIDs for the components that display them, so I don't know how to override the font. Here are some examples:
Here they are in a side menu. As you can see, about five of them fit in the width of a penny. These are too small to be usable.
.
Here they are in the overflow menu. They're enormous. I couldn't fit two of them in the width of a penny.
.
Here are some menus from a native application. In this example, you can see both the side menus and the overflow menus, which are a little big bigger, but they're both about 3 to the width of a penny. This is a very sensible size for my phone.
.
I never see these objects in code, so I can't fiddle with their Style objects. And I can't find them in the Resource Editor. Can anyone tell me how I can get these to show up in a sensible size?
Use the more modern flat themes (blue, red, orange), the older native themes needs to be updated to use the Toolbar and the side menu.
The style for the overflow is "Command" and for the side commands is "SideCommand" make sure the styles Fonts are declared using mm and not pixels to allow it to adjust to different resolutions.
The Visual Studio WinForms designer lets you snap together text boxes, list boxes, buttons, and so forth reasonably well. However, a check box with CheckAlign=MiddleRight does not work quite like the others, because it has two components: the built-in label, and the check box itself. If you line up the text with other labels, the check box is left floating and will not automatically line up. You can turn off AutoSize and attempt to size the CheckBox control so the check box lines up, but this is touchy and will be thrown off by custom font sizes.
In this example, I've almost lined up the check box with the other controls, but not quite:
If I had several check boxes it would be a real headache, as with AutoSize turned off the position of the check box is relative to the end of the text, so each control has to be individually sized pixel by pixel.
What's the best way to line up check boxes with other controls?
One workaround is to not include text with the CheckBox and instead have a separate Label control. However, by doing so you lose the ability to click on the label to toggle the check box. On a high-resolution screen, clicking a 10x10 pixel is finicky, a poor UX experience. You could add an OnClick event to the label, of course, but that seems like solving the wrong problem.
Here's an example of someone else with the same issue: in the preferences panel in Oracle SQL Developer, when there's a mix of properties the check boxes are handled with separate labels and boxes:
Personally, i avoid that issue by not having the CheckBoxes aligned to the right:
rather than having the caption on the left.
How can i scale a Form with font in WPF?
i.e. What is the WPF equivalent of
this.Font = SystemFonts.IconTitleFont;
In WinForms, if you're a good developer, you honor the user's font preferences. A WinForm that starts out as:
You then apply the user's font preferences:
this.Font = new Font("Segoe Print", 11, GraphicsUnit.Point);
and elements on the form scale to accommodate the new size:
Notice:
the form is wider and taller
the label is positioned further down, and to the right
the label is wider and taller
the text of the label is not cut off on the right or on the bottom edge
the button is wider and taller
but button is positioned further down, and to the right
Note: In WinForms you can also use the line:
this.Font = SystemFonts.IconTitleFont;
WPF doesn't support Font, which is why i provided the clearer alternative. For the example below.
A similar WPF form starts out as:
You then apply the user's font preferences with:
this.FontFamily = new FontFamily("Segoe Print");
this.FontSize = 14.666; //11pt = 14.66
and elements on the form don't scale to accommodate the new size:
Notice:
the label's position has not changed
the button's position has not changed
the form is not wider or taller (text is cut off)
the label is not any wider (text is cut off on the right)
the label is not any taller (cutting off text along the bottom edge)
the button is not any wider (text is cut off)
Here is another example of two buttons that are the same size:
WinForms:
Windows Presentation Foundation:
Bonus Reading
WPF: How to specify units in Dialog Units?
How to prevent WPF from scaling with the Windows font size options?
WPF version of .ScaleControl?
WPF doesn't do primitive font-based scaling because it's... well, primitive. You can see it in your own screenshots.
Here's your "WinForms, before changing font" screenshot. Take a look at how much space there is between "sat on a log." and the right edge of the form.
And here's your "WinForms, after changing font" screenshot. Notice how much less margin you have after "scaling".
If you hadn't left all that extra space, then your label would be cut off with the new font. And with some fonts, it would be cut off even though you did leave all that extra space. That's what I mean when I say WinForms' scaling is "primitive". WinForms picks a single scale to apply to everything, and that scale is not chosen with any awareness of your content; it's based on average statistics for the font, which can and will fall apart once you start talking about specifics.
WPF doesn't hobble you with something that primitive. It gives you an amazingly powerful layout system, where it would be trivial to make a window that scales beautifully. But instead, you're choosing to cripple that layout system by using hard-coded sizes. Stop it.
Hard-coded sizes have two huge problems:
They don't adapt to different fonts. You've noticed this already.
They don't adapt to different content. (What happens when you want to make a German version of your app, and the German text doesn't fit into your hard-coded button size?)
Hard-coded sizes just don't adapt. To anything. You had to use them in WinForms because that's all WinForms supported. But WPF gives you a proper layout system, so you don't have to (and shouldn't) use anything that crude.
All you need is this:
A Window with SizeToContent="WidthAndHeight". That way, the window will be exactly the right size to accommodate the text and button, no matter what font or language you use.
Since you only have two UI elements, and one is above the other, you would put a StackPanel inside your Window.
Inside the StackPanel, you need:
A Label or TextBlock to show your text, with the text in Content (Label) or Text (TextBlock); and
A Button with HorizontalAlignment="Right", and the text in Content.
Set some Margins on the StackPanel, TextBlock, and Button to space things out to your liking.
That's it. Don't set any other properties on anything -- especially not Width or Height.
Now, if you change your font, the window and the button will still be exactly the right size, and won't cut off your text. If you localize your app into a different language, the window and the button will be exactly the right size, and won't cut off your text. Stop fighting WPF, and it will give you great results.
If you later want to make your layout more advanced, you could consider things like:
If you want the button to be a little wider (to have more breathing room before and after the text), try playing with the Padding, or set a MinWidth and MinHeight. (Don't use Width or Height if your button contains text. You might consider using them if your button only contains an image, but maybe not even then.)
If you're worried that the font might make the window so large that it no longer fits on the user's screen, and want to enable word-wrapping, then play around with MaxWidth and TextWrapping.
WPF's layout system is amazingly powerful. Learn it. Don't fight it by using hard-coded layouts and then complaining that your hard-coded layouts suck.
I'm sort-of just nit picking here, but maybe there's a simple solution which will save me some time.
When I'm drawing my Winforms GUI in the designer, controls snap to certain points. I can align the baseline of the text of one control to that of another, I can align the left and/or top of one control to another, etc. This is all great.
What's great too, is that the controls snap to other controls spaced with their margins. This means that if I'm making a vertical array of TextBoxes, then I can have them equidistant in my GUI - it looks less messy.
However not everything snaps correctly, or at all. Say I have put in my TextBoxes and now I wish to reduce the width of my form so that there is no white space between the edges of the TextBoxes and the edge of the form. Additionally, I want the distance between the edge of the TextBoxes and the edge of the Form to be the same on the left as it is on the right. If I drag the right edge of the form to the left, towards the TextBoxes it will not snap. I'm left with either calculations to work out what the width should be, or a juggling act to gradually reduce the width until the TextBox is snapping to both the left of the right.
I'm not saying this process is particularly difficult or time consuming. It's just that if it were to snap, the whole process would be infinitely easier.
Is there a built-in option in VS2010, or perhaps an extension? Or maybe I'm just doing it wrong in the first place?
The snap lines in the designer work perfectly when moving or resizing any of the built-in controls. The only time that they don't work is when you are resizing the form itself.
I agree that it would be extremely convenient to have snap lines here, as well. I wish I knew of a way to enable this. But unfortunately, I don't believe that there is one.
The workarounds are either to calculate the proper size mathematically, or guess at resizing the form then check your work by dragging one of the controls (and using the snap lines that appear). I go through the same "juggling act" that you describe on an unfortunately regular basis.
Whenever a control needs to be positioned so that it "snaps" to a form edge I usually move (or resize) the controls to the correct size first, and then change the controls "Anchor" property of those controls to be anchored to the corresponding form edge (even if the form itself won't be allowed to resize).
That way whenever I resize the form, the controls position relative to that form remains the same, simply resizing or moving the control as required (depending on the Anchor property chosen).
I completely agree that the ability to "snap" the form to controls when resizing the form would be extremely useful, but its normally possible to work-around using the anchor property in this way - the times when its doesn't work (such as when a form consists entirely of a column of text-boxes is a fixed height), I'm afraid you need to resort to calculations, but I find that most of my dialogs are resizable.