I have a pretty straightforward UINavigationController in a
UIPopoverController. When it first comes up, it's a table view with a list of
items and it works as expected.
If you select and item, then go back, suddenly the original table view
controller can scroll sideways. It's as if the UITable
Auto layout for this project? I've had loads of issues with scroll views
resizing themselves badly under auto layout. I have a hack I use for it but
it's on my box at home.
> On 16 Aug, 2013, at 18:33, Rick Mann wrote:
>
> I have a pretty straightforward UINavigationController in a
> UIPopo
On Aug 16, 2013, at 04:04 , Roland King wrote:
> Auto layout for this project? I've had loads of issues with scroll views
> resizing themselves badly under auto layout. I have a hack I use for it but
> it's on my box at home.
Yep, autolayout.
--
Rick
__
That's probably it then. Can't tell you the fix as I'm I'm the arse end of
nowhere using a phone for mail.
Basically auto layout gets it right then calls a method which resets the
content size to what it was before, I know not why. I have a method somewhere
which catches this content size chan
On Aug 16, 2013, at 04:12 , Roland King wrote:
> That's probably it then. Can't tell you the fix as I'm I'm the arse end of
> nowhere using a phone for mail.
Hehe, no worries.
> Basically auto layout gets it right then calls a method which resets the
> content size to what it was before, I
I have some code which is almost identical vor iOS and OS X.
So I want to write something like:
#ifdef SOME_THING
// OS X
NSRect someRect = ...
#else
// iOS
CGRect someRect =...
#endif
But what to choose for SOME_THING?
Gerriet.
_
One thing to note: in the 64-bit run time, NSRect and CGRect are the same thing.
Otherwise, what you want is
#if TARGET_OS_IPHONE
or
#if !TARGET_OS_IPHONE
On Aug 16, 2013, at 05:10 , Gerriet M. Denkmann wrote:
> I have some code which is almost identical vor iOS and OS X.
> So I want to wr
I've looked around StackExchange and though there are many suggestions on how
to add borders to UITableViewCells, which I've tested and which work, I'm at a
loss on how to add a border to a UITableViewCell's imageView.
Within tableView:cellForRowAtIndexPath, I've got this code:
UITableViewC
On 16 Aug 2013, at 19:17, Rick Mann wrote:
> One thing to note: in the 64-bit run time, NSRect and CGRect are the same
> thing.
Yes. But the Xcode does not know this and creates lots of warnings.
>
> Otherwise, what you want is
>
> #if TARGET_OS_IPHONE
Very good. Just tried it, and it works
Ahh. Hope this will help someone else out who might run into this.
Though this code works against the cell just fine, that is because the cell
already has a border color defined as black. The imageView does not and
therefore requires a border color to be set like so:
[cell.imageView.layer se
Well I’d go with a conditional like:
#if TARGET_OS_IPHONE
typedef CGRect NSRect;
typedef CGSize NSSize;
typedef CGPoint NSPoint;
#define NSMakeRect CGRectMake
#define NSMakePoint CGPointMake
// etc
#endif
and go with NS* variants.
On Aug 16, 2013, at 20:17, Rick Mann wrote:
> One thing to
On Aug 16, 2013, at 6:51 AM, Gerriet M. Denkmann wrote:
> Is this documented anywhere? Xcode seems not to know about this.
Not sure where it is in the docs, but /usr/include/TargetConditionals.h, which
defines this symbol and others, has a bunch of commentary.
—Jens
__
Here's mine, right from the source (note I only have one section in this table
so rectForSection: works fine), the code is 'first do no evil' code so it just
blocks incorrect sizes and does nothing, just letting the correct ones through.
The motivation for this particularly vile piece of code c
On Aug 16, 2013, at 7:14 AM, Rick Mann wrote:
>
> On Aug 16, 2013, at 04:12 , Roland King wrote:
>
>> Basically auto layout gets it right then calls a method which resets the
>> content size to what it was before, I know not why. I have a method
>> somewhere which catches this content size c
On Aug 16, 2013, at 9:51 AM, "Gerriet M. Denkmann" wrote:
>
> On 16 Aug 2013, at 19:17, Rick Mann wrote:
>
>> One thing to note: in the 64-bit run time, NSRect and CGRect are the same
>> thing.
> Yes. But the Xcode does not know this and creates lots of warnings.
Xcode does know this. But if
On 16 Aug 2013, at 22:59, Kyle Sluder wrote:
> On Aug 16, 2013, at 9:51 AM, "Gerriet M. Denkmann"
> wrote:
>
>>
>> On 16 Aug 2013, at 19:17, Rick Mann wrote:
>>
>>> One thing to note: in the 64-bit run time, NSRect and CGRect are the same
>>> thing.
>> Yes. But the Xcode does not know thi
On Aug 16, 2013, at 12:41 PM, "Gerriet M. Denkmann"
wrote:
>
> On 16 Aug 2013, at 22:59, Kyle Sluder wrote:
>
>>
>> Xcode does know this. But if you're building for 32-bit OS X, it will
>> correctly complain.
>
> When I build for Mac OS X CGRect is accepted.
> But when I build for iOS then
On 15 aug. 2013, at 20:16, Fritz Anderson wrote:
> Do I understand correctly that you have a row in your form that looks like:
>
> |--Label1-Field1--Label2-Field2 --|
>
> ? (Not intended to be a constraint-specification format.) And you want Label1
> and Label2 to be of fixed (identical?) size
[bringing this back on-list]
On Aug 16, 2013, at 1:10 PM, Izak van Langevelde wrote:
> Dear Kyle,
>
> On 16 aug. 2013, at 18:38, Kyle Sluder wrote:
>
> What I am looking for is the algorithm that determines a layout based on a
> set of constraints.
As I mentioned, it converts all the constra
On Aug 16, 2013, at 5:10 AM, Gerriet M. Denkmann wrote:
> I have some code which is almost identical vor iOS and OS X.
> So I want to write something like:
>
> #ifdef SOME_THING
> // OS X
> NSRect someRect = ...
> #else
> // iOS
> CGRect someRect =...
> #endif
>
> Bu
On 17 Aug 2013, at 01:33, Greg Parker wrote:
> On Aug 16, 2013, at 5:10 AM, Gerriet M. Denkmann wrote:
>> I have some code which is almost identical vor iOS and OS X.
>> So I want to write something like:
>>
>> #ifdef SOME_THING
>> // OS X
>> NSRect someRect = ...
>> #else
>>
On 17 Aug 2013, at 00:04, Kyle Sluder wrote:
> On Aug 16, 2013, at 12:41 PM, "Gerriet M. Denkmann"
> wrote:
>
>>
>> On 16 Aug 2013, at 22:59, Kyle Sluder wrote:
>>
>>>
>>> Xcode does know this. But if you're building for 32-bit OS X, it will
>>> correctly complain.
>>
>> When I build fo
I'm looking at a problem where some key equivs are going to the wrong menu
items. Our Zoom Out menu item is always present and uses command-minus. One
particular tool adds its own menu which includes items that use command-minus
and command-shift-minus. This menu does NOT use autoenable, but ena
On 16 aug. 2013, at 19:18, Kyle Sluder wrote:
> [bringing this back on-list]
>
> On Aug 16, 2013, at 1:10 PM, Izak van Langevelde wrote:
>
>> Dear Kyle,
>>
>> On 16 aug. 2013, at 18:38, Kyle Sluder wrote:
>>
>> What I am looking for is the algorithm that determines a layout based on a
>> se
To answer the question in your subject line, I'm not sure. It certainly seems
like a misuse if not an abuse. I always do stuff like that in my friend,
-menuNeedsUpdate. In -menuNeedsUpdate, you can go so far as to remove all the
items and rebuild the whole menu from scratch if you want to.
On Aug 16, 2013, at 08:57 , Kyle Sluder wrote:
> On Aug 16, 2013, at 7:14 AM, Rick Mann wrote:
>
>>
>> On Aug 16, 2013, at 04:12 , Roland King wrote:
>>
>>> Basically auto layout gets it right then calls a method which resets the
>>> content size to what it was before, I know not why. I ha
I have a custom view that creates a mask image in -layoutSubviews. It uses the
screen scale in order to render the image at the best possible resolution.
But -layoutSubviews is getting called before the view has a window, so I can't
get the view's screen. I could use the mainScreen, but that mig
On Aug 16, 2013, at 6:26 PM, Rick Mann wrote:
>
> -layoutSubviews is not called when the view finally gets a window. Should I
> override setWindow: and call setNeedsLayout? What's the best way to handle
> this?
Since -setWindow: doesn't exist, I'd suggest overriding -viewWillMoveToWindow:
to
On Aug 16, 2013, at 16:26 , Kyle Sluder wrote:
> Since -setWindow: doesn't exist, I'd suggest overriding
> -viewWillMoveToWindow: to render and apply your mask. That way when your view
> comes on screen it will have the correct mask already. Call the same code
> from -layoutSubviews if necess
On Aug 16, 2013, at 7:28 PM, Rick Mann wrote:
>
> On Aug 16, 2013, at 16:26 , Kyle Sluder wrote:
>
> Oh, thanks! I skimmed through the list of methods looking for just that, but
> didn't see it. Pedantically, it's -willMoveToWindow:
D’oh! My Mac side is showing. :P
--Kyle
__
On Aug 16, 2013, at 16:31 , Kyle Sluder wrote:
> On Aug 16, 2013, at 7:28 PM, Rick Mann wrote:
>
>>
>> On Aug 16, 2013, at 16:26 , Kyle Sluder wrote:
>>
>> Oh, thanks! I skimmed through the list of methods looking for just that, but
>> didn't see it. Pedantically, it's -willMoveToWindow:
>
On 16 Aug, 2013, at 11:57 PM, Kyle Sluder wrote:
> On Aug 16, 2013, at 7:14 AM, Rick Mann wrote:
>
>>
>> On Aug 16, 2013, at 04:12 , Roland King wrote:
>>
>>> Basically auto layout gets it right then calls a method which resets the
>>> content size to what it was before, I know not why. I
Troy, you can file an enhancement request specifically for an "ignore grammar"
API, but currently how it works is that if the last shown checking result is a
grammar checking result, then ignoring the word underlined by that result will
cause that grammar checking result to be ignored.
It would
In my storyboard app I have view hierarchy like this:
1. ParentViewController has a container view (dragged and dropped the
container view from library on to the view of parent view controller).
2. Container view can embed one of the three view controllers, based on
some condition.
While impl
On Aug 16, 2013, at 21:09 , Devarshi Kulshreshtha
wrote:
> In my storyboard app I have view hierarchy like this:
>
>
> 1. ParentViewController has a container view (dragged and dropped the
> container view from library on to the view of parent view controller).
>
>
> 2. Container view can e
Cargo cults are insidious because they often start out as legitimate solutions
to real problems, but become community wisdom by way of similarity.
I don't doubt your solution to your problem (but would love the opportunity to
verify it for myself). I'm just concerned about Roland adopting it bec
I think you meant "Rick adopting it." I think my situation is triggered by the
way I pre-push to a detail view. If I can do that differently, it might not
happen.
On Aug 16, 2013, at 22:18 , Kyle Sluder wrote:
> Cargo cults are insidious because they often start out as legitimate
> solutions
Currently I have stuff like:
#if TARGET_OS_IPHONE
NSLayoutManager *layoutManager = self.textView.layoutManager;
#else // TARGET MAC OS X
NSLayoutManager *layoutManager = [ self.textView layoutManager
];
#endif // TAR
On Aug 17, 2013, at 12:31 AM, Gerriet M. Denkmann wrote:
> Currently I have stuff like:
>
> #if TARGET_OS_IPHONE
> NSLayoutManager *layoutManager = self.textView.layoutManager;
> #else // TARGET MAC OS X
> NSLayoutManager *layoutManager =
On Aug 16, 2013, at 22:51 , Ken Thomases wrote:
> Dot syntax is just syntactic sugar for accessing properties through the
> accessors.
I agree with everything you said in your reply, except for a quibble about this
one sentence.
Dot notation is *not* syntactically equivalent to method notatio
On 17 Aug, 2013, at 1:18 PM, Kyle Sluder wrote:
> Cargo cults are insidious because they often start out as legitimate
> solutions to real problems, but become community wisdom by way of similarity.
>
> I don't doubt your solution to your problem (but would love the opportunity
> to verify it
On Aug 16, 2013, at 23:30 , Roland King wrote:
> That's fair enough. One thing Rick could try is breakpointing in his override
> of setContentSize:, if the stack trace at the point it sets the size
> incorrectly is called something like _resetToOriginalContentSize .. that is
> at least the sa
42 matches
Mail list logo
