date:20141018

Calling fcntl() and friends from Swift?

2014-10-18 Thread Rick Mann

So far, my foray into Swift is going decently well. But I'm trying to re-write 
some code that uses IOKit and sys/fcntl.h, and while the IOKit calls are 
fine, it doesn't like me trying to call fcntl(). It says, Use of unresolved 
identifier 'fcntl'.

I've tried including sys/fcntl.h in my bridging header, I tried a few imports 
like import sys or import fcntl with no luck. I also haven't found anything 
by googling. Even searching for Swift printf didn't give me good results.

Any ideas on how I can call these things? Thanks!

-- 
Rick Mann
rm...@latencyzero.com



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Table of TextViews

2014-10-18 Thread Ken Thomases

On Oct 15, 2014, at 6:40 AM, Charles Jenkins cejw...@gmail.com wrote:

Thanks for looking it over. :-) I guess I misunderstood the documentation. I
thought if you dragged out a table view from the palette into a NIB, you got
a full hierarchy of objects (including the extra scroll view I specifically
don’t want), but if you created it programmatically you had to create all the
individual text objects and link them up programmatically.

Dragging a text view in IB does give you an enclosing scroll view, which is
almost always what one wants, so it's probably a good default, but it can be a
bit annoying.

However, the documentation clearly explains that there are two approaches when
creating on programmatically. If you use -initWithFrame:, NSTextView creates
all of the appropriate objects of the text system. If you use
-initWithFrame:textContainer:, the NSTextView assumes you are taking
responsibility for creating those objects. The two approaches also result in
different ownership semantics for the various objects.

I’ll use the debugger to scope out what I actually get via initWithFrame:,
and if the other objects are already there, I’ll leave them alone instead of
wasting code space recreating them.

You can poke around with the debugger if you like, but the docs are clear.
Just look at the docs for the initializer methods in the NSTextView class
reference. Or see the Creating an NSTextView Object Programmatically article
in the Text System User Interface Layer Programming Guide:
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/TextUILayer/Tasks/CreateTextViewProg.html

As for reporting the size the way I do, I tried that because of the craziness
that happens when I use text views in a table. I originally started out
having the table delegate watch for the size change notification. When my
table delegate is notified of a text view’s size change, it logs the event
and makes these calls:

NSIndexSet* ixs = [NSIndexSet indexSetWithIndex:row];
[self.theTableView noteHeightOfRowsWithIndexesChanged:ixs];

And things go nuts.

Are you using the text view as the _direct_ cell view in the table? Don't do
that. The outline view is in charge of the frame of the cell views. So, it
will call (or cause to be called by, for example, auto layout) the -setFrame…
methods, which will cause the text view to re-layout the text, which will cause
the layout manager to change the size of the text view, etc.

Put the text view into another view. Probably easiest to make that containing
view flipped, since you want the text view's top-left corner, not its
bottom-left, to be anchored in place as it changes size. If you're using auto
layout, leave the text view's translatesAutoresizingMaskIntoConstraints
property as YES and don't set any constraints on it. Position it using
-setFrame: and let the autoresizingMask take it from there.

The outline view can resize the container view as it likes. That won't have a
direct effect on the text view's height. It will affect its width, as desired,
because of the autoresizingMask. If the text view changes height such that it
is taller or shorter than the container view, that should be corrected after
you inform the outline view that the row's height has changed, so it queries
your delegate for the new height, at which point your delegate would inform it
and the outline view will resize the container view so that the text view shows
and is not clipped.

50 matches

Mail list logo