I need a UIALertView, which on popping up should be transparent enough to show the background behind the alertview in a faded way and the blue color of the alert view should not appear since the background behind the alert view is black and grey in color. Changing color and putting an image to the alert view is one thing which can be seen in the links : iOS 5 black transparent UIAlertView and Changing the background color of a UIAlertView?
but I need a transparent UIAlertView. Is it possible to get one?If yes how?
Thanks for the help in advance.
If you look at Apple's documentation page for UIAlertView you'll see this note:
The UIAlertView class is intended to be used as-is and does not
support subclassing. The view hierarchy for this class is private and
must not be modified.
In other words, Apple doesn't want developers to muck around with colors or fonts or backgrounds when it comes to UIAlertView. If Apple changes the internal guts of UIAlertView in a later iOS, your app is likely to have unexpected and not-desired effects when that modified alert appears.
If you want custom UIAlertView like behavior, why not just write your own UIView that looks and behaves a lot like UIAlertView. And then you have full control over everything about how it's drawn.
As Michael said, you can't with an UIAlertView, you have to build it yourself.
You can try BlockAlertsAnd-ActionSheets, it is like a customizable UIAlerView
https://github.com/gpambrozio/BlockAlertsAnd-ActionSheets
I know it's too late but,
I'll leave this command for other developers.
.h
#interface CustomAlertView:UIAlertView {}
.m
// override
- (void)drawRect:(CGRect)rect
{
for(UIView * sub in self.subviews)
{
[sub removeFromSuperview];
}
// this removeFromSuperview will clear all thing such as background view and buttons
// do something
}
Related
I'm trying to get my NSScrollView (and thus a contained NSOutlineView) to use a blurred NSVisualEffectView with behind-window blending effect.
I've successfully made NSVisualEffectView the container view and placed my scroll view as a subview. This seems to work fine (as long as I make all my table cells, table, nsscrollview etc transparent).
However I've now turned 'Reduce transparency' ON under Accessibility options and all of a sudden I have a black background behind my NSScrollView. I tried subclassing the visual effect view in order to override the drawRect method so that I can draw my own background, but I've just learned this isn't possible or recommended.
How do I detect that Reduce Transparency is ON and how do I make my scrollview opaque dynamically?
Took me a while to find it, but there are a couple of new methods on NSWorkspace that you can use to find out about the preferences for OS X Yosemite’s new accessibility features. -[NSWorkspace accessibilityDisplayShouldReduceTransparency] is the one you want.
By Listening for NSWorkspaceAccessibilityDisplayOptionsDidChangeNotification you can find out when that preference changes. Note that you’ll have to register for that notification on the correct NSNotificationCenter, that is [[NSWorkspace sharedWorkspace] notificationCenter].
It seems as for now I've ended up overriding a parent NSView that contains everything and set a background color for that. This way, when Reduce Transparency is ON, the NSVisualEffectView becomes transparent and the color I end up getting is the one visible below it. This seems to work fine for now.
Despite we have SwiftUI nowadays, in classic Cocoa you can still subclass a custom NSScrollView and use ...
-(NSColor *)backgroundColor {
return NSColor.clearColor;
}
-(BOOL)drawsBackground {
return NO;
}
or set properties of your NSScrollView accordingly if you don't want to subclass like...
yourscrollview.drawsBackground = NO;
yourscrollview.backgroundColor = NSColor.clearColor;
this forces your view to show what is below, and with it also the blurEffect or opaque color of your View or Window that is enclosing your NSScrollView.
This solution has the benefit that you do not have to observe the Workspace for some Notification or VibrancyEffect.
when I change the background of UISearchBar in iOS 7 via interface builder or even in code, and enter in search mode, scopeBar wont be visible and instead its frame will be black?
why that happens?
could someone explains or provide a solution?
here is a shot:
I searched but couldn't find any solution
what I did was using an image which was wide enough to fill seacrh bar background and scopeBar background.
thats all.
first you need to create a subclass of UISearchBar and use this class as your seachBar custom class.
then in - (id) initWithCoder:(NSCoder *)aDecoder add this call
[self setBackgroundColor:[UIColor colorWithPatternImage:[UIImage imageNamed:#"searchBarBg"]]];
Storyboard:
Simulator before segue with view (which is connected to a tab bar controller) showing correct background:
A tap on any of the icons causes a push segue but the background is white, when it should be blue:
I'm using AQGridview and the code for the segue is:
-(void)gridView:(AQGridView *)gridView didSelectItemAtIndex:(NSUInteger)index
{
[self performSegueWithIdentifier:#"mySegue" sender:self];
}
Can anyone tell me what I'm missing?
Did you set the seque Identifier?
Turns out it was something rather stupid but I'll explain it because it's the type of thing I can imagine happening to anyone else who is as daft as me. (There has to be someone as daft as me...)
I'd earlier added a webView to to the viewDidLoad method of the destination ViewController. The default colour of the webView is white and it was overlaid on top of the background colour, so I couldn't see it.
Removed the code referring to the webView and all was well again.
Yes, I'm feeling rather foolish now.
How can I draw a simple BAR?
Like this:
Thank you.
You'll want to make a UIToolbar, put it at the bottom of your XIB, and put some buttons on it. Now, this will by default give you a regular black bar, with that standard black gloss. If you want to have a custom image, there are two solutions.
First is simply subclass UIToolbar and override its drawRect to draw a custom image. The code for overriding drawRect would look something like this:
//in some other code somewhere, preferably on init
self.image = [UIImage imageNamed: #"image"];
- (void)drawRect:(CGRect)rect {
[self.image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}
Now, in iOS 5.0 there is something very useful called appearance but you have to be willing to only target 5.x+ iOS versions.
The second, which is simpler but less versatile, is to simply stick a UIImageView at the bottom of the XIB, and place some buttons on top of it. This is much easier than above, but is less extensible, is harder to modify, and is frowned upon in iOS for good reason - it breaks general iOS conventions (and you lose some very useful functionality).
Crimson has a nice idea but since his/her answer requires using UIToolbar, I'll offer an alternative:
Basically what you are showing there is some kind of progress bar, so ultimately whatever you want to display should be something subclassed from UIControl or even better, UIProgressView or maybe a UISlider.
Google around for custom progress view indicators or sliders. There are also good examples available here on Stackoverflow.
I am working on an app, which actually works like MSPaint (something to draw lines, etc...).
I got a white UIView, basically where the user draws. On top of this UIView I set up a UIImage, which is gray, with a 0,4 alpha. I want this UIImage to be used as a blotting paper. The idea is to disable touch when the user put the palm of his hand on this area, so it's more comfortable to draw (multitouch is disabled, and with this "blotting paper" you won't draw something accidentally with your palm...)
Even if I bring the UIImage to the front, on top of the view, and even if I disable user interactions on this UIImage, it is still possible to draw on the UIView. , behind the UIImage (kind of strange!)
I do not understand what's happening, because, it seems that the image is transparent, and that the UIView "behind" is still active, even if she's overlaid by the UIImage?!
Any help/indication/idea would be much appreciated! Thank you :-)
Have you set the "userInteractionEnabled" property of the UIImage to "NO" ?
You may actually want to do the opposite. When you disable user interaction or touches, the view basically becomes invisible to touches and they are passed on to the next view.
In your case you do want userInteractionEnabled because you want the view to catch those touches.
You have to disable the user interaction on the UIImageView not the UIImage and it should work.
Edit:
Or you could be sneaky and just add an empty view over it. Use the same frame size so it overlaps perfectly and thats it. You'll be able to see everything you need and it's not a subview of it so there will eb no interaction and touches will get registered but won't have any effect. :P
No better ideas unless you post some of your code...
OK, so I managed to do what I wanted to! YAY!
I got 3 different classes :
StrokesViewController (UIViewController)-the view controller
StrokesView (UIView) - the view where the user draws the strokes.
BlottingPaper (UIView) - the blotting paper.
I got a XIB file "linked" to all three.
I created this new class, called "BlottingPaper", typed UIView. the .h and .m file are actually empty (I do import #import < Foundation/Foundation.h >)
User interaction is enable on BlottingPaper.
I do not use the exclusive touch on this class.
On the XIB file, I just put a view on top of StrokesView. I link it to BlottingPaper (modify the alpha as I want, blablabla...)
And that's it! When I put the palm of my hand on it, it doesn't draw anything on the area where my hand is, but I still can draw with my finger on the rest of the StrokesView!
In addition to Dancreek's response, you should be setting buvard.userInteractionEnabled = YES; so that it captures interaction.
You should also set buvard.exclusiveTouch = YES; so that buvard is the only view which will receive touch events.
When you remove buvard you should set buvard.exclusiveTouch = NO; so that other views will regain their ability to receive touches.