On Oct 11, 2014, at 10:23 AM, Keary Suska <cocoa-...@esoteritech.com> wrote:
> On Oct 11, 2014, at 3:53 AM, Daryle Walker <dary...@mac.com> wrote:
>
>> On Oct 10, 2014, at 1:58 AM, Ken Thomases <k...@codeweavers.com> wrote:
>>
>>> On Oct 10, 2014, at 12:02 AM, Daryle Walker <dary...@mac.com> wrote:
>>>
>>>> On Oct 7, 2014, at 8:03 PM, Ken Thomases <k...@codeweavers.com> wrote:
>>>>
>>>>> On Oct 7, 2014, at 5:29 PM, Daryle Walker <dary...@mac.com> wrote:
>>>>>
>>>>>> 1. Although the text in the window expands vertically as needed, it
>>>>>> never does horizontally. Wrapping always happens when lines are too
>>>>>> long, but it adjusts as the width of the window is changed. How do I get
>>>>>> “infinite” space horizontally? I tried various tweaks in Interface
>>>>>> Builder and looked at various Apple guides, but I can’t turn off the
>>>>>> horizontal wrapping.
>>>>>
>>>>> On the Size inspector of IB, enable Resizable Horizontally. Then, in
>>>>> code, do this (assuming self.textView is the outlet property):
>>>>>
>>>>> self.textView.textContainer.widthTracksTextView = NO;
>>>>>
>>>>> I couldn't find anyplace in IB that exposes the text container attributes.
>>>>
>>>> I added “textContainer.widthTracksTextView” to the run-time attributes
>>>> section in Interface Builder as a Boolean, and it changes the behavior in
>>>> the other direction; the text wraps at the window’s original width, even
>>>> if I make the window wider. Changing it to YES (i.e. turning on the
>>>> checkbox) brings back the previous behavior. (I first changed the
>>>> horizontal point limit to 10K, just like the vertical limit.)
>>>
>>> Did you also set Resizable Horizontally (the first step, above)? And, yes,
>>> good catch: I forget to mention changing the max. width.
>>
>> Yes.
>>
>>> I tested this and it worked for me. In summary, all three steps:
>>>
>>> * Set the text view's max. width
>>> * Set the text view to be horizontally resizable
>>> * Set textView.textContainer.widthTracksTextView = NO
>>
>> I had that before my last post; didn’t fix it, made it worse (text width is
>> the initial width of the window, even if I Zoom it out, or manually make it
>> wider, or narrower(!)).
>
>
> I think Ken mis-stated what he meant--the max width isn't terribly relevant.
> You need to set the actual container size (width minimally) to an unlikely
> large number. Apple's TextViewSizing example project demonstrates this. They
> use the value 1.0e7, which comments say is the largest possible value before
> experiencing text drawing issues. You will have to set this value in code, as
> it can't be set via IB.
This fixed it. Thanks.
There was a minor detour where I just had “textContainer.containerSize” set.
You need BOTH “containerSize” and “widthTracksTextView” set (to {10M, 10M} and
NO, respectively). Both of these can be set in the user-defined run-time
attributes section of IB. I heard about this a few months ago as a power-user
hint. I first tried it to set the text-view’s font to the system fixed-width
font, but I couldn’t do it. NSFont is not a type supported by the runtime
attribute section, but NSSize and BOOL are.
>> On Oct 7, 2014, at 5:33 PM, Daryle Walker <dary...@mac.com> wrote:
>>>>>
>>>>>> 3. The text in the view-source window is editable, although I turned
>>>>>> that off. (It’s still selectable.) I can cut/copy/paste. Isn’t turning
>>>>>> off editing supposed to stop this?
>>>>>
>>>>> Are you using bindings? Do any of them have Conditionally Sets Editable
>>>>> enabled in the binding options?
>>>>
>>>> Yes, one for the text view's contents, and another on the window's title
>>>> (using the format substitution version). There is a binding for the text
>>>> view being editable, but I’m not using it. (The text contents property in
>>>> my window controller class is read-write.)
>>>
>>> My point was to check the options on those bindings for the Conditionally
>>> Sets Editable option. If any of them have that option enabled, that would
>>> explain why your text is editable when you set the text view to
>>> non-editable. The binding option is overriding the attribute you set.
>>> Turn it off.
>>
>> I thought you meant the “Editable” attribute under “Availability.” I haven’t
>> activated that Binding at all. But now I see you meant the C.S.E. option
>> under the Binding I did make. That option is checked.
>>
>> Turning it off blocks Cut and Paste, but still allows Copy, Select All, and
>> Find.
>
> You will need to also turn off "selectable" (setSelectable: in code) which
> should disable the rest, and possibly change "find" value to "none"
> (setUsesFindBar: and/or setUsesFindPanel:).
Oh, I want read-only actions supported. Those don’t break the illusion that the
source-view and browser windows are connected.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT 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
