Yep - I ended up going with a Pop Up Button for the reason's you've both
mentioned.
Thanks for replying with a bit of explanation and suggestions!
-Luther
On Wed, Oct 29, 2014 at 3:16 PM, Graham Cox wrote:
>
> On 19 Oct 2014, at 3:14 pm, Luther Baker wrote:
>
> > I don't want to allow the use
On Oct 29, 2014, at 12:15 , Kyle Sluder wrote:
>
>> Dangerous things should be undoable or have a confirming alert anyway.
>
> Steve writes music software. To pick an example, disabling recording on
> an active input track should NOT require a confirmation alert, even
> though it's a destructive
On 19 Oct 2014, at 3:14 pm, Luther Baker wrote:
> I don't want to allow the user to type randomly into the text
> field
It *is* a text field. Sounds like what you really want is a pop-up menu button.
--Graham
___
Cocoa-dev mailing list (Cocoa-de
On Oct 29, 2014, at 14:15:50, Kyle Sluder wrote:
> Huh. I am surprised, but apparently this is precisely what Mail does:
> you can't Trash a message in a background window, even if you
> Command-click it.
I'm glad to see that now (on 10.9 and 10.10), as I'm almost sure it didn't do
that at some
On Oct 29, 2014, at 12:15 PM, Kyle Sluder wrote:
> On Wed, Oct 29, 2014, at 11:57 AM, Quincey Morris wrote:
>> However, this is the wrong solution. A button that doesn’t click through
>> should *look* different when the app is in the background (and shouldn’t
>> do rollover highlighting). So a b
On Wed, Oct 29, 2014, at 11:57 AM, Quincey Morris wrote:
> However, this is the wrong solution. A button that doesn’t click through
> should *look* different when the app is in the background (and shouldn’t
> do rollover highlighting). So a better solution is to disable buttons you
> don’t want cli
> On Oct 29, 2014, at 10:57 AM, Quincey Morris
> wrote:
>
> However, this is the wrong solution. A button that doesn’t click through
> should *look* different when the app is in the background (and shouldn’t do
> rollover highlighting). So a better solution is to disable buttons you don’t
>
On Oct 29, 2014, at 10:26 , Steve Mills wrote:
>
> As I said in my first message, I'm trying to *prevent* this behavior on the
> entire window for all subviews withOUT having to subclass every conceivable
> class that I might add to my window.
You can’t, because it’s not window behavior but ra
On Wed, Oct 29, 2014, at 11:46 AM, Steve Mills wrote:
> 3. It can be dangerous if you forget that an app exhibits this behavior
> and you accidentally click a control in the background when you simple
> wanted to activate the window, and that control deletes something,
> changes something, or other
On Oct 29, 2014, at 12:37:22, Jonathan Mitchell wrote:
>
> Why is this behaviour so undesirable?
1. Only rarely do I find it expected and useful. Otherwise, it's not good user
experience.
2. It forces you to aim at empty spaces if you simply want to bring a window
forward without inadvertentl
> On 29 Oct 2014, at 17:26, Steve Mills wrote:
>
> On Oct 29, 2014, at 12:17:58, Jonathan Mitchell
> wrote:
>
>> Sure. This is expected behaviour for NSButton subclasses of NSView.
>>
>> The docs for NSView acceptsFirstMouse: state:
>>
>> Override this method in a subclass to allow instance
On Oct 29, 2014, at 12:17:58, Jonathan Mitchell wrote:
> Sure. This is expected behaviour for NSButton subclasses of NSView.
>
> The docs for NSView acceptsFirstMouse: state:
>
> Override this method in a subclass to allow instances to respond to
> click-through. This allows the user to click
> On 29 Oct 2014, at 17:08, Steve Mills wrote:
>
> On Oct 29, 2014, at 11:24:49, Jonathan Mitchell
> wrote:
>>
>> Does sound like overkill. I would put together a trivial test project and
>> work back from there.
>
> Same result. New Cocoa app project, subclassed NSView and handled
> accep
On Oct 29, 2014, at 11:24:49, Jonathan Mitchell wrote:
>
> Does sound like overkill. I would put together a trivial test project and
> work back from there.
Same result. New Cocoa app project, subclassed NSView and handled
acceptsFirstClick:, which returns NO, set the main window's content vie
> On 29 Oct 2014, at 16:16, Steve Mills wrote:
>
> On Oct 29, 2014, at 11:05:42, Jonathan Mitchell
> wrote:
>
>> I created a sample project with a single NSWindow and content view subclass
>> like so:
>> @implementation TestView
>>
>> - (void)mouseDown:(NSEvent *)theEvent
>> {
>> NSLog(
On Oct 29, 2014, at 11:05:42, Jonathan Mitchell wrote:
> I created a sample project with a single NSWindow and content view subclass
> like so:
> @implementation TestView
>
> - (void)mouseDown:(NSEvent *)theEvent
> {
>NSLog(@"Mouse down");
> }
>
> /*
> - (BOOL)acceptsFirstMouse:(NSEvent *)
> On 29 Oct 2014, at 15:21, Steve Mills wrote:
>
> Is there no way to turn off the annoying and dangerous behavior of views
> accepting background clicks, short of subclassing every view in a window and
> returning NO from acceptsFirstMouse:? The only docs I can find still state
> the opposit
On 18 Oct 2014, at 11:14 PM, Luther Baker wrote:
>
> Is it possible to keep an NSComboBox in the tabbing ring if I set its
> "Behavior" to "Selectable". Tabbing reaches the control if the textfield is
> editable but I don't want to allow the user to type randomly into the text
> field ... but unf
Is there no way to turn off the annoying and dangerous behavior of views
accepting background clicks, short of subclassing every view in a window and
returning NO from acceptsFirstMouse:? The only docs I can find still state the
opposite of what happens these days
(https://developer.apple.com/l
On 29 Oct 2014, at 10:31 pm, William Squires wrote:
> Is it possible to fire the flash (LED) on my iPhone 5(s) without taking a
> photo?
Have a look at AVCaptureDevice - it has various methods for detecting whether
the hardware supports a torch and for turning it on and off.
--Graham
___
Given the number of flashlight apps in the store the answer had to be a yes.
Check the docs for ‘torch’ and ‘flash', that seems to have interfaces for
turning the LED on and off, whether the torch one or the flash one or possibly
they are the same anyway.
> On 29 Oct 2014, at 7:31 pm, Willia
Is it possible to fire the flash (LED) on my iPhone 5(s) without taking a
photo? (i.e. is there a programmatic interface to turn the LED on/off via an
ObjC message send? Can I talk to it directly using C? Also, does iOS have
OpenCV, or something like it, so the camera can detect flashing light
Iain,
I forgot to say that this was the first thing I checked when the apps were
first rejected. I moved from the automatic provisioning profile to explicit
ones, but still the apps were rejected. Maybe I still got the provisioning
profiles wrong. I’ll double check.
Thanks!
Martin
> On 29
I had the same issue: it turned out that Xcode's automatic provisioning profile
choice was not as smart as I'd hoped and had picked a provisioning profile that
had a maps entitlement. Setting the correct profile fixed it.
I'd check there first before a DTS
Iain
> On 29 Oct 2014, at 7:01 am,
Dear list,
I recently submitted updates to three different apps on the app store. All
three were rejected due to:
"This app uses one or more entitlements which do not have matching
functionality within the app. Apps should have only the minimum set of
entitlements necessary for the app to func
25 matches
Mail list logo
