I hooked up an action from IB to my view controller, but I don't see an
option for where to define what kind of action it is... So my problem
is events are only being fired when a textfield stops being edited. I
would like it to fire anytime a key is pressed, What is the best way to
do
edited. I
would like it to fire anytime a key is pressed, What is the best way to
do this currently?
I'm not aware of a way to do that. Have you tried subclassing NSTextfield and
overriding keyDown, and calling the action handler from there?
--
Steve Mills
Drummer, Mac geek
problem
is events are only being fired when a textfield stops being edited. I
would like it to fire anytime a key is pressed, What is the best way to
do this currently?
I'm not aware of a way to do that. Have you tried subclassing NSTextfield and
overriding keyDown, and calling the action
On Mar 12, 2015, at 12:15:32, Mike Abdullah mabdul...@karelia.com wrote:
Please don’t do that. NSTextField already provides such messaging to its
delegate:
Hi Everyone,
Is there a way to determine if a mounted removable volume is a DMG or not? I
need to distinguish between a USB Stick and a DMG in my app. I have played with
statfs(), but I can't seem to figure out a tangible/concrete difference.
How does one figure out what type of removable
Robert Monaghan wrote:
How does one figure out what type of removable volume is mounted?
Use the 'hdiutil' command to get info on dmg's. For example:
hdiutil info
or:
hdiutil info -plist
You can also correlate its output to statfs()-returned data.
-- GG
is the best way to accomplish this?
Currently, I have a method in A that sets the title property value:
- (void) setBackBarButtonItemTitle:(NSString *)newTitle {
self.navigationItem.backBarButtonItem.title = newTitle;
}
When in B, I call -viewControllers to get
On Sun, Sep 20, 2009 at 6:37 PM, Jesse Armand mnemonic...@gmail.com wrote:
You can create an ivar in class B that refer to class A instance. Set
that ivar, when class B instance is created.
So, you can call the methods in class A by using that instance,
without searching through the view
of the backBarButtonItem was initially set in A, just before
I pushed the B view onto the navigation stack.
Assuming I am in B and I would like to change the title of the
backBarButtonItem, what is the best way to accomplish this?
Currently, I have a method in A that sets the title property value
On 6/18/09 2:52 PM, Greg Guerin said:
Chilton Webb wrote:
Is there a way to add a tag an IB object in such a way that it is
not visible to the user, but in such a way that I could reference
it from my app?
Maybe the -tag method: it returns a 32-bit integer.. It's settable
in IB as the
On 19/06/2009, at 3:59 AM, Erik Buck wrote:
use
[[myBox subviews] makeObjectPerformSelector:@selector(setEnabled:)
withObject:NO];
or similar.
Are you certain that works? 'NO' isn't an object, so I didn't think
you could use -makeObjectsPerformSelector:withObject: in this fashion
-
On 19/06/2009, at 5:23 PM, Graham Cox wrote:
However it does seem to compile without complaint, though I'm not
sure why... If this is permitted, does it work with rects, points,
etc?
My bad - it doesn't even compile in fact, so I guess that answers that
question.
--Graham
It compiles because NO == nil == NULL == 0.
I shouldn't have posted the silly example which doesn't work in most
cases.
how about this typed in mail:
@interface NSView (MYGroupEnable)
/// Enable all controls nested within the receiver
- (void)enableSubviews
{
for(NSView *currentView in
Hi,
Here's why I'm asking.
Right now I have an app that has a number of possibly different
'objects' in it. And I currently have a single inspector for all of
them.
When a new object is selected, the appropriate view for that object is
added to the inspector window.
This is a basically
If I understand correctly:
* You want to have a single general-purpose model class (what you are calling
the object) for which different object types might have different sets of
attributes. Kind of like a dictionary or an NSManagedObject.
* You'd like to use xib files to serve as attribute
On 20/06/2009, at 5:35 AM, Chilton Webb wrote:
Hi,
Here's why I'm asking.
Right now I have an app that has a number of possibly different
'objects' in it. And I currently have a single inspector for all of
them.
When a new object is selected, the appropriate view for that object
is
Hi,
In an effort to create a less structured set of IB objects, I would
like to 'tag' various IB elements.
For example, I might want to add a specific tag to a group of objects
that I might later want to show or hide. I might want to grab values
from only objects that contain some key
See the - (void)setRepresentedObject:(id)anObject method of NSCell. You can
set a string or dictionary and the represented object and retrieve it via
-representedObject.
You can also instantiate an array and add objects to the array within IB. Then
you only need an outlet instance variable
On Thu, Jun 18, 2009 at 1:59 PM, Erik Buckerik.b...@sbcglobal.net wrote:
You can also instantiate an array and add objects to the array within IB.
Then you only need an outlet instance variable to reference the array and not
separate instance variables for all of the user interface objects.
On Thu, Jun 18, 2009 at 1:45 PM, Michael Ashmichael@gmail.com wrote:
Since the last update on that page is from the Panther era, and since
Leopard's IB3 completely broke backwards compatibility with IB2
plugins, I'd say the chances of the Foundation Collections Palette
still working are
Chilton Webb wrote:
Is there a way to add a tag an IB object in such a way that it is
not visible to the user, but in such a way that I could reference
it from my app?
Maybe the -tag method: it returns a 32-bit integer.. It's settable
in IB as the control's tag value. I don't know if
Hi Greg!
Thanks for writing back.
On Jun 18, 2009, at 4:52 PM, Greg Guerin wrote:
Is there a way to add a tag an IB object in such a way that it is
not visible to the user, but in such a way that I could reference
it from my app?
Maybe the -tag method: it returns a 32-bit integer.. It's
Chilton Webb wrote:
It *would* be useful, but IB doesn't let you set it to a string in
Cocoa. It's limited to numeric values, which makes it less useful
for humans.
For a bit of perspective, this is doable in *CARBON* apps, via the
'Command' attribute in Interface Builder. You can only
On Jun 18, 2009, at 5:15 PM, Chilton Webb wrote:
Hi Greg!
Thanks for writing back.
On Jun 18, 2009, at 4:52 PM, Greg Guerin wrote:
Is there a way to add a tag an IB object in such a way that it is
not visible to the user, but in such a way that I could reference
it from my app?
Maybe the
On Jun 18, 2009, at 4:45 PM, Michael Ash wrote:
On Thu, Jun 18, 2009 at 1:59 PM, Erik Buckerik.b...@sbcglobal.net
wrote:
[...]
You can populate the array entirely within IB. Make any target/
action connections in IB.
http://www.geocities.com/kritter_cocoadev/
Since the last update on that
David (enki1...@gmail.com) on 2009-01-10 4:23 PM said:
I'm looking for what I think are some fairly common requirements from
a file copy mechanism.
- simple. Why write something if you can reuse.
- support multi-threading so that you can stay responsive to the UI
while copying large files.
- good
Well, I don't know if you guys are still listening on this thread but,
for the record, I did put Graham's suggestion into practice,
immediately. It was fast, easy, and simple to modify when I wanted to
tweak the behavior to use float values instead of integers. Thanks,
Graham.
After
I assume I can sub-class the control but I wondering if there is a
better way. I'm using a circular slider and would like it to rotate
when I roll the scroll wheel up or down.
-Michael
--
There are two ways of constructing a software design. One way is to
make it so
On 28 Nov 2008, at 3:18 am, Michael A. Crawford wrote:
I assume I can sub-class the control but I wondering if there is a
better way. I'm using a circular slider and would like it to rotate
when I roll the scroll wheel up or down.
You can just implement the -scrollWheel: method in a
On Thu, Nov 27, 2008 at 12:08 PM, Graham Cox [EMAIL PROTECTED] wrote:
On 28 Nov 2008, at 3:18 am, Michael A. Crawford wrote:
I assume I can sub-class the control but I wondering if there is a better
way. I'm using a circular slider and would like it to rotate when I roll
the scroll wheel up
On 28 Nov 2008, at 4:08 am, Graham Cox wrote:
On 28 Nov 2008, at 3:18 am, Michael A. Crawford wrote:
I assume I can sub-class the control but I wondering if there is a
better way. I'm using a circular slider and would like it to
rotate when I roll the scroll wheel up or down.
You
On Nov 28, 2008, at 11:24 AM, Graham Cox wrote:
Playing with this, the code below gives a nice feel for a big
variety of sliders in my app and wraps properly with circular ones
too. I was skeptical at first that this was a good idea but trying
it out in the app I've quickly come to
On 28 Nov 2008, at 11:46 am, Bill Bumgarner wrote:
Categories are great for dividing a class's implementation
(sometimes across frameworks -- NSAttributedString in Foundation and
AppKit, for example) and great for adding new functionality to
existing classes in isolation. But they are
On Nov 28, 2008, at 11:52 AM, Graham Cox wrote:
In which case Apple should a) explicitly document this as a no-no,
and b) disallow categories to install methods that already exist. I
would have thought b) was possible, as when loading a category, I
assume what's really happening is that the
On 28 Nov 2008, at 11:46 am, Bill Bumgarner wrote:
At best, your app's standard sliders will behave in a decidedly non-
standard fashion. At worst, your app's standard sliders will crash.
Could you explain how that's a real possibility? I don't see that.
If Apple's implementation of
On 28 Nov 2008, at 12:19 pm, Graham Cox wrote:
Even if they couldn't remove the functionality for legacy reasons
they could start documenting it in a much more strongly worded
fashion to state that this is simply not permitted.
Just to emphasise the point, the full paragraph you quoted
On Thu, Nov 27, 2008 at 7:24 PM, Graham Cox [EMAIL PROTECTED] wrote:
Please don't do this! It will apply to every single slider in your
process, even ones you didn't create yourself,
Well, that is potentially a feature. I guess the point would be to test
your UI thoroughly and make sure it
On Nov 28, 2008, at 12:19 PM, Graham Cox wrote:
On 28 Nov 2008, at 11:46 am, Bill Bumgarner wrote:
At best, your app's standard sliders will behave in a decidedly non-
standard fashion. At worst, your app's standard sliders will crash.
Could you explain how that's a real possibility? I
On Nov 27, 2008, at 7:24 PM, Graham Cox wrote:
Yep, that's a potentially more serious issue. It would be nice if a
category had a way to check for an existing implementation and
quietly no-op itself. Just checking respondsToSelector: doesn't work
of course, always returning YES.
Build
awakeFromNib was my first guess. Thanks for the pointers.
On Mon, Jul 14, 2008 at 4:07 PM, Scott Ribe [EMAIL PROTECTED]
wrote:
Thats correct. The main window is not covered up. The second window is
not
modal I agree. In the second window I just need to collect some
additional
info
Hi.
I am seeking an advise. I have an app that after loading a MainMenu.nib, it
checks the defaults for some data and if data is not there, the app will
request it via the other NIB (modal window). The Main window shall not be
blocked. What would be a proper way of doing things like that?
The Main window shall not be
blocked. What would be a proper way of doing things like that?
What do you mean? The main window should not be covered up? Or events should
still be processed by the main window? Because if it's the latter, then
don't run the second window as modal.
--
Scott Ribe
Thats correct. The main window is not covered up. The second window is not
modal I agree. In the second window I just need to collect some additional
info that will go the the second's window controller. There will be OK and
Cancel buttons on that window to close it. The main window will not
On Mon, Jul 14, 2008 at 9:57 AM, Ronnie B [EMAIL PROTECTED] wrote:
Thats correct. The main window is not covered up. The second window is not
modal I agree. In the second window I just need to collect some additional
info that will go the the second's window controller. There will be OK and
Thats correct. The main window is not covered up. The second window is not
modal I agree. In the second window I just need to collect some additional
info that will go the the second's window controller. There will be OK and
Cancel buttons on that window to close it. The main window will
On Jul 14, 2008, at 9:57 AM, Ronnie B wrote:
Thats correct. The main window is not covered up. The second
window is not
modal I agree. In the second window I just need to collect some
additional
info that will go the the second's window controller. There will be
OK and
Cancel buttons
46 matches
Mail list logo
