How to expand wxTextCtrl in wxToolbar? - wxwidgets

There is a tool button and a textctrl in the toolbar. I'm trying to expand the textctrl in the horizontal direction to fill all the remaining space.
wxSizer maybe a good choice but it seems not suitable with toolbar because I can't add tool button directly in a sizer.

There is no built in support for this, you will need to handle wxEVT_SIZE (either in the toolbar itself or in the frame containing it, as the size of the toolbar only changes when the size of the frame does), compute the available size (which is going to be tricky, there is no function to find this out neither so I expect you'd have to do some kind of binary search using wxToolBar::FindToolForPosition()) and resize your text control.
It would definitely be much simpler to put both the toolbar and the text in a sizer instead. But it's true that it wouldn't appear quite the same, so if you really want to have the text-inside-toolbar appearance, you would have to do the above. Good luck!

Related

WinRT - ImageButton for transparent PNGs

I'm using XAML Toolkit ImageButton control to be able to create normal and pressed states for a button. Code is:
<toolkit:ImageButton NormalStateImageSource="ms-appx:///Assets/1_off.png"
PressedStateImageSource="ms-appx:///Assets/1_on.png"
Width="500"
Height="200">
</toolkit:ImageButton>
Issue I'm facing is, say I have a shape which isn't rectangle or square. For example I have PNGs for star and arrow object. Is there a way to set their boundary corresponding to shape? If not, please advice the best approach to handle such scenarios.
There are two options I tried
When clicking using mouse or touch - you'd check the last position of the pointer before click and see if the image in your button has a non-transparent pixel at that position.
Pros:
It's simpler than option 2.
You get most precise information
Cons:
You can't tell if a button got clicked with mouse, touch, pen, keyboard or by narrator using automation, so you could end up filtering out keyboard clicks just because the mouse cursor is a bit off. You could possibly use some heuristics like how long ago was the pointer move or pointer down event before the click event, but it's a bit hacky and might be unreliable.
Generate a vector path for your image and put it in the button template as a Path element with Fill="Transparent", then mark any other non-transparent or hit testable template elements (buttons, borders with Background="Transparent", etc.) as IsHitTestVisible="false".
Pros:
Doesn't break any input methods
Can be quite precise
For some shapes like a circle - the Path.Data could be quite simple or you could even use something like an Ellipse element instead
Cons:
You need to generate the path somehow
A complex path might adversely affect performance
A better solution overall in most cases is to leave the hit-testable area rectangular. The reason is - an arbitrary shape is a finicky and unreliable hit test target so it makes clicking your button more difficult. Using the default rectangular border or at most - an ellipse shape is a lot simpler and more usable.

Programmatically make color filled UIBarButtonItem

I have a UIBarButtonItem with the UIBarButtonSystemItemSearch type. I can programmatically change the tint color, like so:
searchButton.tintColor = [UIColor purpleColor];
However, what I'm trying to do is figure out a way to programmatically "fill" the button (i.e. the magnifying glass) with a given color. More generally, I'm trying to use a change in the icon to indicate that the search functionality is active.
I really like the built in search icon, but the lack of an obvious fill functionality is annoying. Is there any way to do something like this without creating an entirely custom button/icon? If not, what's the easiest way to utilize the existing search icon to create a custom button that does have the ability to be filled?
First off I would suggest simply using the tintColor to show your selected/unselected states without trying to mess with the shape itself since it is much easier and will convey what you're trying to do. Keep in mind that in this specific case, the magnifying glass may not even look right if it is filled in, that shape is very specific and people are used to seeing empty space in the circle.
If you want to continue on that route though, no you cannot easily change the built-in search icon. Your options are 1. programmatically take a snapshot of such an icon on the screen and try to manipulate that using CoreGraphics (not a great solution) or the better solution 2. which is just to get/make your own image and then you don't have to do any of it programmatically.

Automatically adjusting winform and controls to screen size

I created a winform application. The size of each screen is 1361, 768 in pixels. This worked great for larger screens and/or laptops. But now I have to move my application to 10inch screen tablets, which means my application does not fit.
I have never had to deal with this issue before, how can auto adjust each form size and adjust all of the controls and panels when viewing on smaller screens?
I am using VS 2012.
Making forms fully scalable in WinForms is possible, but it takes a bit of work. The good news is that most of this work is done at design-time, arranging the controls properly so that everything is done for you automatically by the framework. It's drudgery, but it isn't difficult. Rejoice that you don't have to write the scaling code by hand, form-by-form, like you did with VB 6.
There are four fundamental properties that you will need to acquaint yourself with:
Anchor
Dock
Margin
Padding
The last two should be quite familiar web developers who know CSS—they do the same thing here. Padding controls the inner margin around a control, while margin controls the outer margin. You will need to set these correctly to ensure that your controls can "breathe", because the automatic scaling code is just going to jam them up against one another.
The "standard" margins around a control in a Windows desktop application are approximately 12–15 pixels. You should make sure that you leave at least this much room. Then add additional margins/padding as you see fit to separate things. I keep these layout specifications bookmarked for reference. This is another good reference.
The next step is to instruct the layout manager how you want the controls to be arranged and resized. The key to this is to think in terms of container controls and child controls. The form itself is a container control, and you can set its child controls to either Anchor or Dock within its boundaries. One or more of those child controls can itself be a container control, and its child controls can be Anchored or Docked within its borders. The nesting is virtually unlimited, but for your own sanity and reasonable redraw performance, you'll want to keep it to a reasonable minimum.
A good way of doing this is to use the two provided invisible layout helpers, FlowLayoutPanel and TableLayoutPanel. Personally, I don't find the former very useful very often, at least not for standard Windows applications. But the TableLayoutPanel is invaluable.
Generally what I will do is fill my entire form with a TableLayoutPanel (margins = 0, dock = fill). Then I will add individual controls (or sometimes another nested TableLayoutPanel) to its cells. Those child controls will have their margins set appropriately, and will have either their Anchor or Dock properties set, depending on whether I want that control to have a fixed size or resize dynamically.
Before you get the hang of how these properties interact and how it all works, you'll probably need to play around with your layout a bit. Make a backup of your forms and then just dig in. Or, you might find it easier to start designing each form from scratch (you can still copy-and-paste individual controls in order to preserve their other properties). Eventually, it will all start making sense to you, and you'll be up and going in a jiffy.
The great thing is, once this is all set up, all you have to do is ensure that your form is resizable. Then, whether the user manually resizes it or uses the maximize/restore button, it'll automatically fill their screen size. This also works well for all DPI settings, which is another common Achilles' heel of WinForms devs.
Try to get the resolutions variables to adjust your screens, there is an answer to get these variables using the Screen class
Getting Screen Resolution
DevExpress has a great control call the Layout Control. This control helps to maintain consistent whitespace between controls as the form is resized. It does take a little study to use the control effectively but once you understand how to use this control the results are consistent and you are able to speed through form design.

Custom button in Windows 8.1 app

I have a requirement to create a button in a Windows 8.1 app which has an icon and a text label. The icon will be a symbol from Segoe UI Symbols and the text label will be Segoe UI Semibold at a smaller text size.
I want to be able to reuse the button in different places within the app, using different icons and text labels.
How show I go about this? I could create a button and then edit the ContentPresenter to have a horizontally oriented stack panel with two TextBlocks, but then how could I reuse this? And how could I change the text in the two different text blocks?
Should I create a separate custom control with separate dependency properties for each of the textblock strings? I'm interested in hearing what you would do.
thanks
Create a simple Style. To make it easy, I would base it off the standardized AppBarButton style. You can format it to whatever size you want (I have done something similar to make a larger button or one with text on the side).
Have the main icon simply be a ContentPresenter which binds to the Content using a TemplateBinding. Make sure to set the FontFamily to Segoe UI Symbol. Have the text label pull from AutomationProperties.Name, similar to how the AppBarButton style does.
Then, whenever you want to use this just do:
<Button Style="{StaticResource MyCustomButtonStyle}"
Content="" // Where "000" is replaced by the number of the icon you wish to use.
AutomationProperties.Name="Text Label"/>
This should be extensible and easily reproducible to whatever location you need. When copying over the AppBarButton style, I suggest removing the artificial size limits (specifically the width of the main content Grid). I do suggest either giving the Text Label a fixed size or having it pull its size from the specified parent Width, so that it will Wrap correctly.
Hope this helps and happy coding!
Are you desiring to create something like for an AppBar? Take a look at AppBarButton and the style/types it supports. In Windows 8.1 we added some things around SymbolIcon specifically. Since you basically want two pieces of 'content' for your style you'll have to re-purpose one property (unless you create a custom control which doesn't sound needed for this scenario). Using AutiomationProperties.Name for the visible label is a good idea because it will also help with accessibility by default for those users.
Investigate the style for AppBarButton to get you started.

Setting UIMenuController arrow direction not working

I have a UIMenuController which I have added a few extra items to. I would like the menu to be BELOW the text that I select, so I tried:
[UIMenuController sharedMenuController].arrowDirection = UIMenuControllerArrowDown;
That seemed to do nothing, and everything I try, won't put the menu below the text.
How can I do that?
According to the docs, arrowDirection sets the direction the arrow points; it has nothing to do with the location of the menu relative to its target area. It also looks like they don't give you any control over the positioning of the menu beyond setTargetRect:inView.
If you really want to put the menu below the text, you might be able to set a "fake" target area and change the arrow direction to point to the "real" area of interest.
However, there's probably a reason Apple does it this way. My guess? If you select some text with your finger, your hand is probably obscuring the part of the screen below the text... so it's not very helpful if the menu appears there. Going out of your way to break consistency with standard UI conventions isn't usually worth the effort.