On 14 Oct 2012, at 03:26, Kyle Sluder wrote:
> On Sat, Oct 13, 2012, at 01:19 PM, Andy Lee wrote:
>> Unless I'm mistaken, Kyle meant the view hierarchy, not the inheritance
>> hierarchy. In other words, if you go up the superview chain starting at
>> the window's first responder, do you encounte
On 13.10.2012, at 21:00, Kyle Sluder wrote:
> Could you instead broaden your test to "my WebView or any of its
> descendants is first responder?"
or simply use directly the WebView on the responderchain. Because I had similar
problems like Gerriet
concerning finding a selected string or zoomin
On 14 Oct 2012, at 16:07, Heinrich Giesen wrote:
>
> On 13.10.2012, at 21:00, Kyle Sluder wrote:
>
>> Could you instead broaden your test to "my WebView or any of its
>> descendants is first responder?"
>
> or simply use directly the WebView on the responderchain. Because I had
> similar pr
On Sat, Oct 13, 2012 at 11:58 PM, Jerry Krinock wrote:
> So you need to experiment with different methods.
>
> • Remove the -setPredicate: statement. Now is filteredPersons everything in
> the store, as expected, or still empty?
Yes, it contains all the names currently in the store.
> • Chang
Maybe another clue, if I NSLog the predicate, I get this:
name IN {{"name" = "Jones A."}, {"name" = "Williams S."}, {"name" =
"Brown M."}, {"name" = "Tobias S."}}
That seems as expected to me.
- Koen.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.
On 2012 Oct 14, at 07:05, Koen van der Drift wrote:
> name IN {{"name" = "Jones A."}, {"name" = "Williams S."}, {"name" =
> "Brown M."}, {"name" = "Tobias S."}}
>
> That seems as expected to me.
It says that the name should be in a set of predicates, which are boolean.
That doesn't make sens
On Oct 14, 2012, at 10:43 AM, Jerry Krinock wrote:
> On 2012 Oct 14, at 07:05, Koen van der Drift
> wrote:
>
>> name IN {{"name" = "Jones A."}, {"name" = "Williams S."}, {"name" =
>> "Brown M."}, {"name" = "Tobias S."}}
>>
>> That seems as expected to me.
>
> It says that the name should be
On 12 Oct 2012, at 23:55, Koen van der Drift wrote:
>
> Man, I thought I had this all working, and after a few days of doing other
> stuff, it is back to my original issue. I am now updating my textfield as
> follows, so no matter from where it is called, it will always be updated on
> the
Hi,
I'm trying to set the key equivalent for a menu item to the plus sign.
Interface Builder won't let you do that. I tried doing it manually with
[item setKeyEquivalent:@"+"];
But to make it work you have to hold down the shift key.
Any ideas?
thanks
Jeff
__
On Oct 14, 2012, at 3:04 PM, Mike Abdullah wrote:
> How did you determine that -updateStatusWrapper: doesn't get called?
>
> (You could do away with that method entirely BTW, and just use
> setProgressStatus: as the selector)
>
> You're updating a property of self. How does that then update t
On Oct 14, 2012, at 12:24 PM, Jeff Smith wrote:
> I'm trying to set the key equivalent for a menu item to the plus sign.
> Interface Builder won't let you do that. I tried doing it manually with
> [item setKeyEquivalent:@"+"];
> But to make it work you have to hold down the shift key.
Right. D
On Sun, Oct 14, 2012, at 12:29 PM, Koen van der Drift wrote:
> Even if I use:
>
> - (void)updateStatus: (NSString *)status
> {
> [statusTextField performSelectorOnMainThread:@selector(
> setStringValue:) withObject: status waitUntilDone: NO]; // or YES
> }
>
> the field does not get upda
On Oct 14, 2012, at 4:34 PM, Kyle Sluder wrote:
> Okay, at this point you need to step back a bit and actually work
> through your threading architecture. The first question to ask yourself
> is whether you actually understand multithreading. The second question
> to ask is whether you actually
On 14 Oct 2012, at 20:29, Koen van der Drift wrote:
>
> On Oct 14, 2012, at 3:04 PM, Mike Abdullah wrote:
>
>> How did you determine that -updateStatusWrapper: doesn't get called?
>>
>> (You could do away with that method entirely BTW, and just use
>> setProgressStatus: as the selector)
>>
On Oct 14, 2012, at 4:47 PM, Mike Abdullah wrote:
> Presumably statisTextField is an outlet? Sure you've got it hooked up right?
Yup, it is an outlet and hooked up. SInce it is being updated during the
download phase of the process, I can assume it is connected correctly.
- Koen.
Interestingly, I also have a progressbar, and that one gets updated as expected
in all cases. Very strange.
- Koen.
On Oct 14, 2012, at 4:54 PM, Koen van der Drift
wrote:
>
> On Oct 14, 2012, at 4:47 PM, Mike Abdullah wrote:
>
>> Presumably statisTextField is an outlet? Sure you've got it
> Maybe another clue, if I NSLog the predicate, I get this:
>
> name IN {{"name" = "Jones A."}, {"name" = "Williams S."}, {"name" =
> "Brown M."}, {"name" = "Tobias S."}}
>
> That seems as expected to me.
>
the predicate should be something like
name IN {"Jones A.", "Williams S.", "Brown M.", "
LSUIElement=1 in Info.plist is hint for Launch Services to do not
initialize user interface(i.e., Dock icon).
On Oct 12, 2012, at 11:19 AM, Dave Keck wrote:
> I would create a new Cocoa application using Xcode's template, delete all the
> .m files (except main.m), and put your code in main.m. Y
On Sep 22, 2012, at 5:46 PM, Boris Dobroslav wrote:
> I'm perplexed by one line that appears in the file AVSPDocument.h from the
> apple example code project AVSimplePlayer:
>
> staticvoid *AVSPPlayerItemStatusContext = &AVSPPlayerItemStatusContext;
This is my preferred method of generating un
19 matches
Mail list logo
