Date   

Re: New syntax in Xcode 12.5.

Alex Zavatone
 

I found out what the issue was.  The programmer didn’t add a self in front of variables that had the same name as the local that he was creating.   Xcode 12.4 reports an error until you add self in front of the properties.  Xcode 12.5 can handle 

The actual line looked more like this.

let myVar = myVar != someValue ? myVar : myOtherAssignment

It actually should be    

let myVar = self.myVar != someValue ? self.myVar : myOtherAssignment

Thanks.
Alex Zavatone

On Jul 26, 2021, at 11:19 AM, Jeremy Hughes via groups.io <moon.rabbit@...> wrote:

1. myVar != someValue is the condition.

2. It determines whether the ternary expression evaluates to resultOne or resultTwo

3. resultOne or resultTwo is what is assigned in let myVar =

This seems like a standard use of the ternary conditional operator. I don’t have any problems compiling it in Xcode 12.4.

Jeremy



On 26 Jul 2021, at 16:57, Alex Zavatone via groups.io <zav@...> wrote:

The first half.  Ternary has been there since time began.  I’ve never seen this part be legitimate before.

let myVar = myVar != someValue



On Jul 26, 2021, at 10:09 AM, Jeremy Hughes via groups.io <moon.rabbit@...> wrote:

Are you referring to the ternary conditional operator, which has existed in Swift since the beginning, or to the fact that it creates a local variable with the same name (myVar) as a parameter or member (myVar)?

Jeremy



On 26 Jul 2021, at 15:37, Alex Zavatone via groups.io <zav@...> wrote:

I just saw someone use this syntax in a project and haven’t see it before.  It compiles in Xcode 12.5, but not in Xcode 12.4.  Does anyone have any more details on it?

let myVar = myVar != someValue ? resultOne : resultTwo

Swift sure is getting muddier and muddier with regards to visual comprehension.

Thanks in advance.
Alex Zavatone



















Re: New syntax in Xcode 12.5.

Jeremy Hughes
 

1. myVar != someValue is the condition.

2. It determines whether the ternary expression evaluates to resultOne or resultTwo

3. resultOne or resultTwo is what is assigned in let myVar =

This seems like a standard use of the ternary conditional operator. I don’t have any problems compiling it in Xcode 12.4.

Jeremy

On 26 Jul 2021, at 16:57, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

The first half. Ternary has been there since time began. I’ve never seen this part be legitimate before.

let myVar = myVar != someValue


On Jul 26, 2021, at 10:09 AM, Jeremy Hughes via groups.io <moon.rabbit=virginmedia.com@groups.io> wrote:

Are you referring to the ternary conditional operator, which has existed in Swift since the beginning, or to the fact that it creates a local variable with the same name (myVar) as a parameter or member (myVar)?

Jeremy



On 26 Jul 2021, at 15:37, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I just saw someone use this syntax in a project and haven’t see it before. It compiles in Xcode 12.5, but not in Xcode 12.4. Does anyone have any more details on it?

let myVar = myVar != someValue ? resultOne : resultTwo

Swift sure is getting muddier and muddier with regards to visual comprehension.

Thanks in advance.
Alex Zavatone







Re: New syntax in Xcode 12.5.

Alex Zavatone
 

The first half. Ternary has been there since time began. I’ve never seen this part be legitimate before.

let myVar = myVar != someValue


On Jul 26, 2021, at 10:09 AM, Jeremy Hughes via groups.io <moon.rabbit=virginmedia.com@groups.io> wrote:

Are you referring to the ternary conditional operator, which has existed in Swift since the beginning, or to the fact that it creates a local variable with the same name (myVar) as a parameter or member (myVar)?

Jeremy



On 26 Jul 2021, at 15:37, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I just saw someone use this syntax in a project and haven’t see it before. It compiles in Xcode 12.5, but not in Xcode 12.4. Does anyone have any more details on it?

let myVar = myVar != someValue ? resultOne : resultTwo

Swift sure is getting muddier and muddier with regards to visual comprehension.

Thanks in advance.
Alex Zavatone





Re: New syntax in Xcode 12.5.

Jeremy Hughes
 

Are you referring to the ternary conditional operator, which has existed in Swift since the beginning, or to the fact that it creates a local variable with the same name (myVar) as a parameter or member (myVar)?

Jeremy

On 26 Jul 2021, at 15:37, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I just saw someone use this syntax in a project and haven’t see it before. It compiles in Xcode 12.5, but not in Xcode 12.4. Does anyone have any more details on it?

let myVar = myVar != someValue ? resultOne : resultTwo

Swift sure is getting muddier and muddier with regards to visual comprehension.

Thanks in advance.
Alex Zavatone


New syntax in Xcode 12.5.

Alex Zavatone
 

I just saw someone use this syntax in a project and haven’t see it before.  It compiles in Xcode 12.5, but not in Xcode 12.4.  Does anyone have any more details on it?

let myVar = myVar != someValue ? resultOne : resultTwo

Swift sure is getting muddier and muddier with regards to visual comprehension.

Thanks in advance.  
Alex Zavatone


Re: Help with iOS 15-style UIButton?

Rick Aurbach
 

Just to finish up this discussion, below is the code I ended up with for my button that is compatible with both pre-15 and post-15 code.

I think that if you subclass UIButton in your current code, (particularly if you use titleEdgeInsets and/or imageEdgeInsets, you need to test for breaking changes in iOS15.

Good luck to all.


Re: CGContext always creating a black rect.

Ben Kennedy
 

On 24 Jul 2021, at 12:56 pm, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

I know I don’t need the self, but I want the context. A variable just sitting around tells me nothing about the context in which it exists. I want to see the context and want to see the self.
I initially felt that way too, several years ago, when first coming from Obj-C. However, I learned to embrace the tools (which make it easy to find the declaration) and also be mindful of writing clear and well-organized code to keep the mental burden of symbol bookkeeping to a minimum.

Moreover, following conventional style (which, in Swift, eschews the redundant `self.`) makes it easier to work with other developers.

- That same function seems like it ought to be pure; i.e., have no side effects -- just draw a rect based on its argument. However, it does math and sets instance variables. If it needs to affect and act on persistent state, it ought to be refactored.
Refactored how? [...]

Here’s how I currently call it. [...]

self.roundedRect.configure(rectWidth: rectWidth, rectHeight: rectHeight, rectBgColor: rectBgColor , rectBorderColor: rectBorderColor, rectBorderWidth: rectBorderWidth, rectCornerRadius: rectCornerRadius)

self.view.addSubview(roundedRect)
Seems like your `configure(…)` method is the ideal place for those calculations.

In Swift, I HATE how they have done method parameters, so I’m opting for redundant redundancy over terseness or brevity.
I'm not sure what you're referring to about "how they have done method parameters".

-ben


Re: CGContext always creating a black rect.

Alex Zavatone
 

Thanks.

I know I don’t need the self, but I want the context.  A variable just sitting around tells me nothing about the context in which it exists.  I want to see the context and want to see the self.

- The `roundRect(…)` function would be better named as `drawRoundRect(…)`.

Good point.

On Jul 24, 2021, at 2:32 PM, Ben Kennedy <ben-groups@...> wrote:

On 24 Jul 2021, at 11:37 am, Alex Zavatone via groups.io <zav@...> wrote:

Hi.  I’m trying to draw a bezier shape in CGContext on a UIView in Swift with a transparent background and the background is always black.  Nothing online helps.

Any ideas?  I’ve checked .isOpaque, backgroundColor.   Nothing I can do to get rid of the black rect background.  Any ideas?

Move your `backgroundColor` and `isOpaque` calls to the init method(s). I set up a test project with your code, and that solves the problem.

I was going to make that suggestion before I even tested it, though, because it's an obvious smell to me: there's no need to repeatedly set those properties every time you draw, but rather just once, at setup.

A couple of other code style comments:

- You don't need all the `self.` prefixes.

Want them.  They indicate scope.  I don’t need to think.  I just look at it and know the scope.  Anything that makes code more vague sucks.  I want easier understanding rather than “but we can use less words!”  People’s time is $$.

- The `roundRect(…)` function would be better named as `drawRoundRect(…)`.

- That same function seems like it ought to be pure; i.e., have no side effects -- just draw a rect based on its argument. However, it does math and sets instance variables. If it needs to affect and act on persistent state, it ought to be refactored.

Refactored how?

It can’t exist without its configuration being set and it will be drawing with those internal settings once I have the details set up.  Then it’s possible that I’ll move the configuration internal.  Eventually, it will have a gradient interior.  It’s replacing a UISwitch.

Here’s how I currently call it.

        self.roundedRect = RoundedRectUIView()
        self.roundedRect.backgroundColor = .clear
        self.roundedRect.clipsToBounds = true
        let rectBorderWidth = CGFloat(2)
        let rectWidth = CGFloat(100)
        let rectHeight = CGFloat(40)
        let rectBorderColor = UIColor.blue
        let rectBgColor = UIColor.systemGray3
        let rectCornerRadius = CGFloat(-1)
        let origin = CGPoint(x: 10, y: 200)
        viewRect = CGRect(origin: origin,
                          size: CGSize(width: rectWidth + rectBorderWidth * 2.0,
                                       height: rectHeight + (rectBorderWidth * 2.0)))
        self.roundedRect.frame = viewRect

                          

        self.roundedRect.configure(rectWidth: rectWidth, rectHeight: rectHeight, rectBgColor: rectBgColor , rectBorderColor: rectBorderColor, rectBorderWidth: rectBorderWidth, rectCornerRadius: rectCornerRadius)

        self.view.addSubview(roundedRect)

In Swift, I HATE how they have done method parameters, so I’m opting for redundant redundancy over terseness or brevity.

Thanks, Ben.
-ben








Re: CGContext always creating a black rect.

Ben Kennedy
 

On 24 Jul 2021, at 11:37 am, Alex Zavatone via groups.io <zav=mac.com@groups.io> wrote:

Hi. I’m trying to draw a bezier shape in CGContext on a UIView in Swift with a transparent background and the background is always black. Nothing online helps.

Any ideas? I’ve checked .isOpaque, backgroundColor. Nothing I can do to get rid of the black rect background. Any ideas?
Move your `backgroundColor` and `isOpaque` calls to the init method(s). I set up a test project with your code, and that solves the problem.

I was going to make that suggestion before I even tested it, though, because it's an obvious smell to me: there's no need to repeatedly set those properties every time you draw, but rather just once, at setup.

A couple of other code style comments:

- You don't need all the `self.` prefixes.

- The `roundRect(…)` function would be better named as `drawRoundRect(…)`.

- That same function seems like it ought to be pure; i.e., have no side effects -- just draw a rect based on its argument. However, it does math and sets instance variables. If it needs to affect and act on persistent state, it ought to be refactored.

-ben


CGContext always creating a black rect.

Alex Zavatone
 

Hi.  I’m trying to draw a bezier shape in CGContext on a UIView in Swift with a transparent background and the background is always black.  Nothing online helps.

Any ideas?  I’ve checked .isOpaque, backgroundColor.   Nothing I can do to get rid of the black rect background.  Any ideas?  

Thanks in advance.


    override func draw(_ rect: CGRect)
    {
        self.backgroundColor = .clear
        self.isOpaque = false
        super.draw(rect)
        roundRect(rect)
    }

    

    internal func roundRect(_ rect: CGRect)
    {
        self.backgroundColor = UIColor.clear

        

        // Make a pill shape if rectCornerRadius < 0
        let xHalf = self.frame.width / 2
        let yHalf = self.frame.height / 2

        

        if (self.rectCornerRadius < 0) {
            if (self.rectWidth <= self.rectHeight) {
            self.rectCornerRadius = (yHalf / 2)
            } else if (self.rectHeight <= self.rectWidth) {
                self.rectCornerRadius = (xHalf / 2)
            }
        }

        

        let ctx: CGContext = UIGraphicsGetCurrentContext()!

        ctx.clear(rect)
        ctx.saveGState()

        

        ctx.setLineWidth(rectBorderWidth)
        ctx.setStrokeColor(rectBorderColor.cgColor)

        

        let rect = CGRect(x: 0, y: 0, width: self.rectWidth, height: self.rectHeight)

        let clipPath: CGPath = UIBezierPath(roundedRect: rect, cornerRadius: self.rectCornerRadius).cgPath
        let linePath: CGPath = UIBezierPath(roundedRect: rect, cornerRadius: self.rectCornerRadius).cgPath

        

        ctx.addPath(clipPath)

        

        ctx.setFillColor(self.rectBgColor.cgColor)
        ctx.closePath()
        ctx.fillPath()

        

        ctx.addPath(linePath)
        ctx.strokePath()

        

        ctx.restoreGState()
    }


Re: Help with iOS 15-style UIButton?

Rick Aurbach
 
Edited

Hi, Alex.

The work-around was to force the button width to be "expectedWidth" (which is the width of the [unwrapped] text + image padding + image width + 8 points of slop (to account for button margins). If you notice, I override draw() to always make this adjustment just before calling super.draw(). The 8 its of margin was determined by experiment.

The comment about "mirroring above bounds code" just means that I was (historically) using different logic to adjust button size in the pre-15 case, and that I should probably change that code to use the same logic as the 15+ version.

Hope this helps.


Re: Help with iOS 15-style UIButton?

Alex Zavatone
 

And what is, "mirrow above bounds code”?

On Jul 19, 2021, at 12:56 PM, Alex Zavatone via groups.io <zav@...> wrote:

mirrow above bounds code"



Re: Help with iOS 15-style UIButton?

Alex Zavatone
 

Could you point out the specific workaround please?

On Jul 19, 2021, at 12:49 PM, Rick Aurbach via groups.io <rlaurb@...> wrote:

[Edited Message Follows]

I haven't filed a bug yet, but I will. In the meantime, I've constructed the following work around — it's a hack, but it seems to work.

    override open func draw(_ rect: CGRect) {

        drawButton()

        super.draw(rect)

    }

    

    private func drawButton() {

        if #available(iOS 15, *) {

            titleLabel?.lineBreakMode = .byTruncatingTail

            titleLabel?.numberOfLines = 1

            if let text = titleLabel?.text {

                let textSize = sizeText(string: text)

                let imageSize = imageView?.bounds.size ?? CGSize.zero

                let expectedWidth = textSize.width + textGap + imageSize.width + 8

                var currentBtnSize = self.bounds.size

                currentBtnSize = CGSize(width: max(expectedWidth, currentBtnSize.width), height: currentBtnSize.height)

                self.bounds.size = currentBtnSize

                setNeedsUpdateConstraints()

            }

        } else {

            contentHorizontalAlignment = .left

            titleLabel?.adjustsFontSizeToFitWidth = false

            titleLabel?.lineBreakMode = .byTruncatingTail

 

            let imageSize = image(for: .normal)?.size ?? .zero

            let optSize = intrinsicContentSize

#warning("consider changing this to mirrow above bounds code")

            if bounds.width < optSize.width || bounds.height < optSize.height {

                setNeedsLayout()

            }

            let actualTextWidth = optSize.width - textGap - imageSize.width - trailingGap

            imageEdgeInsets = UIEdgeInsets(top: 0.0, left: (actualTextWidth + textGap), bottom: 0.0, right: trailingGap)

            titleEdgeInsets = UIEdgeInsets(top: 0.0, left: -imageSize.width, bottom: 0.0, right: -actualTextWidth)

        }

    }



Re: Help with iOS 15-style UIButton?

Rick Aurbach
 
Edited

I haven't filed a bug yet, but I will. In the meantime, I've constructed the following work around — it's a hack, but it seems to work.

    override open func draw(_ rect: CGRect) {

        drawButton()

        super.draw(rect)

    }

    

    private func drawButton() {

        if #available(iOS 15, *) {

            titleLabel?.lineBreakMode = .byTruncatingTail

            titleLabel?.numberOfLines = 1

            if let text = titleLabel?.text {

                let textSize = sizeText(string: text)

                let imageSize = imageView?.bounds.size ?? CGSize.zero

                let expectedWidth = textSize.width + textGap + imageSize.width + 8

                var currentBtnSize = self.bounds.size

                currentBtnSize = CGSize(width: max(expectedWidth, currentBtnSize.width), height: currentBtnSize.height)

                self.bounds.size = currentBtnSize

                setNeedsUpdateConstraints()

            }

        } else {

            contentHorizontalAlignment = .left

            titleLabel?.adjustsFontSizeToFitWidth = false

            titleLabel?.lineBreakMode = .byTruncatingTail

 

            let imageSize = image(for: .normal)?.size ?? .zero

            let optSize = intrinsicContentSize

#warning("consider changing this to mirrow above bounds code")

            if bounds.width < optSize.width || bounds.height < optSize.height {

                setNeedsLayout()

            }

            let actualTextWidth = optSize.width - textGap - imageSize.width - trailingGap

            imageEdgeInsets = UIEdgeInsets(top: 0.0, left: (actualTextWidth + textGap), bottom: 0.0, right: trailingGap)

            titleEdgeInsets = UIEdgeInsets(top: 0.0, left: -imageSize.width, bottom: 0.0, right: -actualTextWidth)

        }

    }


Re: Help with iOS 15-style UIButton?

Jeremy Hughes
 

Can you file a bug?

Maybe they will fix it before iOS 15 is released.

Jeremy

On 19 Jul 2021, at 16:06, Rick Aurbach via groups.io <rlaurb=me.com@groups.io> wrote:

Good thought. I'll give it a try.

Re: your "do you have to use the API" remark, the simple answer is that if your deployment target is iOS 15, you ARE using the API, whether you like it or not. There is no choice in this matter. And it's even worse -- if you just carry over code that works on iOS14 to an iOS15 deployment target, the button's appearance changes. In other words, iOS 15 will break existing code as soon as you link it for iOS 15 SDK deployment.

This is seriously broken.


Re: Help with iOS 15-style UIButton?

Alex Zavatone
 

Thanks for the heads up.  That’s crappy.

On Jul 19, 2021, at 10:06 AM, Rick Aurbach via groups.io <rlaurb@...> wrote:

Good thought. I'll give it a try.

Re: your "do you have to use the API" remark, the simple answer is that if your deployment target is iOS 15, you ARE using the API, whether you like it or not. There is no choice in this matter. And it's even worse -- if you just carry over code that works on iOS14 to an iOS15 deployment target, the button's appearance changes. In other words, iOS 15 will break existing code as soon as you link it for iOS 15 SDK deployment.

This is seriously broken.


Re: Help with iOS 15-style UIButton?

Rick Aurbach
 

Good thought. I'll give it a try.

Re: your "do you have to use the API" remark, the simple answer is that if your deployment target is iOS 15, you ARE using the API, whether you like it or not. There is no choice in this matter. And it's even worse -- if you just carry over code that works on iOS14 to an iOS15 deployment target, the button's appearance changes. In other words, iOS 15 will break existing code as soon as you link it for iOS 15 SDK deployment.

This is seriously broken.


Re: Help with iOS 15-style UIButton?

Alex Zavatone
 



On Jul 18, 2021, at 4:52 PM, Rick Aurbach via groups.io <rlaurb@...> wrote:

  • I tried setting .numberOfLines to 1. In fact, I do so whenever changing title content. The button sets the value back to 0 and wraps the text.
Can you set up an observer to watch and see if it’s changed and then change it back? Seems like a real hack, but it’s a thought.


Re: Help with iOS 15-style UIButton?

Alex Zavatone
 



On Jul 18, 2021, at 4:52 PM, Rick Aurbach via groups.io <rlaurb@...> wrote:

  • I tried setting .numberOfLines to 1. In fact, I do so whenever changing title content. The button sets the value back to 0 and wraps the text.
My god, that sucks. I can’t believe this wasn’t tested.  We've actually been building custom UI classes for the past month and am familiar with the pain.  

Do you have to use the new API?


Re: Help with iOS 15-style UIButton?

Rick Aurbach
 

The problem is unique to the new iOS 15 UIButton API. There is no problem in my logic if the deployment target < iOS15.

Specifically,
  • I tried setting a constraint on the height of the button. It is ignored — the text wrap extends outside the constrained height.
  • I tried forcing the button to be very wide. That works (i.e., no wrap), but in this case, the button extends beyond the trailing edge of the image, which leads to undesirable effects.
  • I tried setting .numberOfLines to 1. In fact, I do so whenever changing title content. The button sets the value back to 0 and wraps the text.
This is, actually, quite frustrating.

1 - 20 of 1416