Creating More Than 1 Of The Same Element/control

  • Hellow,
    I've been working through a couple of tutorials and managed to make a text field and things just fine.  The thing I'm wondering is how do I go about naming the textField what I want to call it, like textField1 or for example rather than just textField?  Also, how do I make more than 1 textField?  I would just use the same code as for the first one and change the y co-ordinate, but then I would still want to call them all something other than textField.
    I'm using the objective c language and hate using the storyboard and interface builder.  If I'm going to code something, I'll write the code by hand.  I tried posting on the objc language list, but the only person who replied seemed to think it was too beginner level and that I was posting on the wrong list.  If no one on here can help me rather than insist on suggesting stupid books, I don't really know where else to ask, since I'm not getting a lot of luck on google's search results.
    Thanks,
    Harmony.
  • On 18/05/2013, at 8:21 PM, Harmony Neil <harmony.neil...> wrote:

    > I've been working through a couple of tutorials and managed to make a text field and things just fine.  The thing I'm wondering is how do I go about naming the textField what I want to call it, like textField1 or for example rather than just textField?  Also, how do I make more than 1 textField?  I would just use the same code as for the first one and change the y co-ordinate, but then I would still want to call them all something other than textField.
    > I'm using the objective c language and hate using the storyboard and interface builder.  If I'm going to code something, I'll write the code by hand.  I tried posting on the objc language list, but the only person who replied seemed to think it was too beginner level and that I was posting on the wrong list.  If no one on here can help me rather than insist on suggesting stupid books, I don't really know where else to ask, since I'm not getting a lot of luck on google's search results.

    Stick with Interface Builder, even if you don't enjoy it right now. You'll come to appreciate it even if it will perhaps never be love.

    All you need to do is to create a separate IBOutlet in the controller for each field, then connect that to the fields in IB. In code, you can refer to the outlet by whatever name you called it, like any other instance variable.

    @interface MyController : UIViewController
    {
        IBOutlet UITextField*        mTextField1;
        IBOutlet UITextField*        mTextField2;

    }

    @end

    in the code....

    [mTextField1 setStringValue:@"blah blah"];
    [mTextField2 setStringValue:@"hubba hubba"];

    Trying to do the set up of this kind of thing in code is possible, but never a very good idea. It is certainly the sign of a beginner to want to do that; you'd really be much better off using the time to get more familiar with IB. It will truly save you a monumental amount of work and will eliminate many irritating typical bugs.

    I infer that you're working in iOS, rather than Mac, but I might have got the class names wrong above. I'm sure you're smart enough to realise if that's the case.

    --Graham
  • On 18 May 2013, at 03:21, Harmony Neil <harmony.neil...> wrote:

    > Hellow,
    > I've been working through a couple of tutorials and managed to make a text field and things just fine.  The thing I'm wondering is how do I go about naming the textField what I want to call it, like textField1 or for example rather than just textField?  Also, how do I make more than 1 textField?  I would just use the same code as for the first one and change the y co-ordinate, but then I would still want to call them all something other than textField.
    > I'm using the objective c language and hate using the storyboard and interface builder.  If I'm going to code something, I'll write the code by hand.  I tried posting on the objc language list, but the only person who replied seemed to think it was too beginner level and that I was posting on the wrong list.  If no one on here can help me rather than insist on suggesting stupid books, I don't really know where else to ask, since I'm not getting a lot of luck on google's search results.
    > Thanks,
    > Harmony.

    Hi Harmony,

    I'd really very strongly suggest that you just use Interface Builder.  Your user interface is essentially data, not code.  I doubt (and hope) very much that you don't write code to fill up a buffer with image data at runtime, rather than storing images in data files.  The same logic applies to your UI – store your archived objects in a nib file, and use IB to edit them.

    Thanks

    Tom Davie
  • On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    > I'd really very strongly suggest that you just use Interface Builder. Your user interface is essentially data, not code. I doubt (and hope) very much that you don't write code to fill up a buffer with image data at runtime, rather than storing images in data files. The same logic applies to your UI – store your archived objects in a nib file, and use IB to edit them.

    I'd very strongly argue with this statement … Personally, I do use IB just for common things like preferences window with standard controls, etc. I do use it rarely for other windows, views, … and if then just with custom NSView as a placeholder for things I do want to create in code. It's not that IB is horrible, but it's about personal taste, development speed and lot of other things. For example - try to precisely edit auto layout constraints in IB. Sorry, but this is nightmare - mouse heavily involved, … I'm much faster with my macros like …

      TM_NSLC_BINDINGS( _warningLabel, _closeButton );
      if ( _sticky ) {
        TM_ADD_NSLC_VISUAL( @"H:|-16-[_warningLabel]-10-[_closeButton(8)]-16-|" );
        TM_ADD_NSLC_VCENTER_RELATIVE_TO( self.closeButton, self );
        TM_ADD_NSLC_VISUAL( @"V:[_closeButton(9)]" );
      } else {
        TM_ADD_NSLC_VISUAL( @"H:|-10-[_warningLabel]-10-|" );
      }
      TM_ADD_NSLC_VISUAL( @"V:|-16-[_warningLabel]-16-|" );

    … than with mouse & IB. And many more examples.

    In other words, Interface Builder is not a must, not a dogma, it's just about each developer's taste what's better to use. Stick with whatever you do want and what's better for you. Both worlds have +- and the best thing you can do is to combine them.
  • On May 22, 2013, at 11:19 PM, Robert Vojta <robert...> wrote:

    > On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    >> I'd really very strongly suggest that you just use Interface Builder. Your user interface is essentially data, not code. I doubt (and hope) very much that you don't write code to fill up a buffer with image data at runtime, rather than storing images in data files. The same logic applies to your UI – store your archived objects in a nib file, and use IB to edit them.
    >
    > I'd very strongly argue with this statement … Personally, I do use IB just for common things like preferences window with standard controls, etc. […] It's not that IB is horrible, but it's about personal taste, development speed and lot of other things. For example - try to precisely edit auto layout constraints in IB. Sorry, but this is nightmare - mouse heavily involved, … I'm much faster with my macros like …

    For most developers I’d agree with Thomas, although Robert is right that there are valid reasons for not using IB. I just find that in most cases it saves me time and frustration. Also, if you work in a team, it makes it possible for non-coders to edit the UI: this can be a big time-saver when working with UI designers, when instead of telling you to move something up 3 pixels they can just open the xib and do it themselves.

    However, people are forgetting that the OP, Harmony, has visual impairments that make it very difficult for him to use GUIs. And (so I’m told) Interface Builder has poor accessibility, particularly around crucial actions like wiring up outlets and actions. Back when he started here a few months ago he was having a terrible time trying to drive it with VoiceOver, and the consensus advice was to put IB aside and create interfaces using code instead.

    —Jens
  • It is distressing to me that Interface Builder uses explicit, fixed
    coordinates for positioning and sizing its widgets.

    That means that, for localization for example, to accomodate the different
    numbers of characters in the various languages, you have to create
    different nibs for each locale.

    ZooLib (http://www.zoolib.org/) doesn't have a visual design tool, so your
    UI has to be laid out with explicit C++ code.  But it has a very ingenious
    layout mechanism which quite fluidly and intelligently adjusts for changing
    sizes, as well as window resizes.

    Harmony, give ZooLib a try.  It's a cross-platform application framework.
    It runs in particular on OS X and iOS.

    It hasn't had a tarball release in eons.  That doesn't mean its development
    has been abandoned, just that all its users get the code from revision
    control.

    It's on both sourceforge and github.  I haven't tried the github stuff, but
    that will be more current I think.  The tarball on sourceforge, while quite
    old, is quite stable.

    Best,

    Mike Crawford
    <mdcrawford...>

    On Thu, May 23, 2013 at 9:47 AM, Jens Alfke <jens...> wrote:

    >
    > On May 22, 2013, at 11:19 PM, Robert Vojta <robert...> wrote:
    >
    >> On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    >>> I'd really very strongly suggest that you just use Interface Builder.
    > Your user interface is essentially data, not code. I doubt (and hope) very
    > much that you don't write code to fill up a buffer with image data at
    > runtime, rather than storing images in data files. The same logic applies
    > to your UI – store your archived objects in a nib file, and use IB to edit
    > them.
    >>
    >> I'd very strongly argue with this statement … Personally, I do use IB
    > just for common things like preferences window with standard controls, etc.
    > […] It's not that IB is horrible, but it's about personal taste,
    > development speed and lot of other things. For example - try to precisely
    > edit auto layout constraints in IB. Sorry, but this is nightmare - mouse
    > heavily involved, … I'm much faster with my macros like …
    >
    > For most developers I’d agree with Thomas, although Robert is right that
    > there are valid reasons for not using IB. I just find that in most cases it
    > saves me time and frustration. Also, if you work in a team, it makes it
    > possible for non-coders to edit the UI: this can be a big time-saver when
    > working with UI designers, when instead of telling you to move something up
    > 3 pixels they can just open the xib and do it themselves.
    >
    > However, people are forgetting that the OP, Harmony, has visual
    > impairments that make it very difficult for him to use GUIs. And (so I’m
    > told) Interface Builder has poor accessibility, particularly around crucial
    > actions like wiring up outlets and actions. Back when he started here a few
    > months ago he was having a terrible time trying to drive it with VoiceOver,
    > and the consensus advice was to put IB aside and create interfaces using
    > code instead.
    >
    > —Jens
    >
    >

    --
    Michael David Crawford
    mdcrawford at gmail dot com

      Custom Software Development for the iPhone and Mac OS X
      http://www.dulcineatech.com/custom-software-development/
  • Does Auto Layout not address this issue for you?

    Interface Builder Help: Auto Layout: Understanding Constraints

    Regards,

    Jay O'Conor
    <joconor...>

    On May 23, 2013, at 10:44 AM, Michael Crawford <mdcrawford...> wrote:

    > It is distressing to me that Interface Builder uses explicit, fixed
    > coordinates for positioning and sizing its widgets.
    >
    > That means that, for localization for example, to accomodate the different
    > numbers of characters in the various languages, you have to create
    > different nibs for each locale.
    >
    > ZooLib (http://www.zoolib.org/) doesn't have a visual design tool, so your
    > UI has to be laid out with explicit C++ code.  But it has a very ingenious
    > layout mechanism which quite fluidly and intelligently adjusts for changing
    > sizes, as well as window resizes.
    >
    > Harmony, give ZooLib a try.  It's a cross-platform application framework.
    > It runs in particular on OS X and iOS.
    >
    > It hasn't had a tarball release in eons.  That doesn't mean its development
    > has been abandoned, just that all its users get the code from revision
    > control.
    >
    > It's on both sourceforge and github.  I haven't tried the github stuff, but
    > that will be more current I think.  The tarball on sourceforge, while quite
    > old, is quite stable.
    >
    > Best,
    >
    > Mike Crawford
    > <mdcrawford...>
    >
    >
    > On Thu, May 23, 2013 at 9:47 AM, Jens Alfke <jens...> wrote:
    >
    >>
    >> On May 22, 2013, at 11:19 PM, Robert Vojta <robert...> wrote:
    >>
    >>> On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    >>>> I'd really very strongly suggest that you just use Interface Builder.
    >> Your user interface is essentially data, not code. I doubt (and hope) very
    >> much that you don't write code to fill up a buffer with image data at
    >> runtime, rather than storing images in data files. The same logic applies
    >> to your UI – store your archived objects in a nib file, and use IB to edit
    >> them.
    >>>
    >>> I'd very strongly argue with this statement … Personally, I do use IB
    >> just for common things like preferences window with standard controls, etc.
    >> […] It's not that IB is horrible, but it's about personal taste,
    >> development speed and lot of other things. For example - try to precisely
    >> edit auto layout constraints in IB. Sorry, but this is nightmare - mouse
    >> heavily involved, … I'm much faster with my macros like …
    >>
    >> For most developers I’d agree with Thomas, although Robert is right that
    >> there are valid reasons for not using IB. I just find that in most cases it
    >> saves me time and frustration. Also, if you work in a team, it makes it
    >> possible for non-coders to edit the UI: this can be a big time-saver when
    >> working with UI designers, when instead of telling you to move something up
    >> 3 pixels they can just open the xib and do it themselves.
    >>
    >> However, people are forgetting that the OP, Harmony, has visual
    >> impairments that make it very difficult for him to use GUIs. And (so I’m
    >> told) Interface Builder has poor accessibility, particularly around crucial
    >> actions like wiring up outlets and actions. Back when he started here a few
    >> months ago he was having a terrible time trying to drive it with VoiceOver,
    >> and the consensus advice was to put IB aside and create interfaces using
    >> code instead.
    >>
    >> —Jens
    >>
    >>
    >
    >
    > --
    > Michael David Crawford
    > mdcrawford at gmail dot com
    >
    > Custom Software Development for the iPhone and Mac OS X
    > http://www.dulcineatech.com/custom-software-development/
  • I've never found Auto Layout to work well for me.  I far prefer ZooLib's
    method, despite having to do my design in C++ source.

    Erica Sadun his a nice method for handling autorotation for the cases where
    Auto Layout isn't going to work.  You create two extra views in your nib
    just for use as templates, one portrait the other landscape.  There is a
    numeric field in each Cocoa Touch view that is not used much, called id I
    think, but in the templates you give each view a unique id number.  Then
    you use a method called I think RepositionSubviews that adjusts the layout
    coordinates of each on-screen view to be the same as the view with the
    corresponding template.

    It's in her book The iPhone Cookbook.  I recommend it highly.

    This enables your portrait windows to be laid out completely differently
    from your landscape windows.  For example in my App Warp Life, a Conway's
    Life game, the user can set the size of the cell grid in the Settings
    window.  In portrait, the width UITextField is above the height, in
    landscape the height is to the right of the width.  AutoLayout can't do
    that.

    On Thu, May 23, 2013 at 1:50 PM, Jay O'Conor <joconor...> wrote:

    > Does Auto Layout not address this issue for you?
    >
    > Interface Builder Help: Auto Layout: Understanding Constraints<http://developer.apple.com/library/ios/#recipes/xcode_help-interface_builde
    r/articles/UnderstandingAutolayout.html
    >
    >
    >
    > Regards,
    >
    > Jay O'Conor
    > <joconor...>
    >
    > On May 23, 2013, at 10:44 AM, Michael Crawford <mdcrawford...>
    > wrote:
    >
    > It is distressing to me that Interface Builder uses explicit, fixed
    > coordinates for positioning and sizing its widgets.
    >
    > That means that, for localization for example, to accomodate the different
    > numbers of characters in the various languages, you have to create
    > different nibs for each locale.
    >
    > ZooLib (http://www.zoolib.org/) doesn't have a visual design tool, so your
    > UI has to be laid out with explicit C++ code.  But it has a very ingenious
    > layout mechanism which quite fluidly and intelligently adjusts for changing
    > sizes, as well as window resizes.
    >
    > Harmony, give ZooLib a try.  It's a cross-platform application framework.
    > It runs in particular on OS X and iOS.
    >
    > It hasn't had a tarball release in eons.  That doesn't mean its development
    > has been abandoned, just that all its users get the code from revision
    > control.
    >
    > It's on both sourceforge and github.  I haven't tried the github stuff, but
    > that will be more current I think.  The tarball on sourceforge, while quite
    > old, is quite stable.
    >
    > Best,
    >
    > Mike Crawford
    > <mdcrawford...>
    >
    >
    > On Thu, May 23, 2013 at 9:47 AM, Jens Alfke <jens...> wrote:
    >
    >
    > On May 22, 2013, at 11:19 PM, Robert Vojta <robert...> wrote:
    >
    > On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    >
    > I'd really very strongly suggest that you just use Interface Builder.
    >
    > Your user interface is essentially data, not code. I doubt (and hope) very
    > much that you don't write code to fill up a buffer with image data at
    > runtime, rather than storing images in data files. The same logic applies
    > to your UI – store your archived objects in a nib file, and use IB to edit
    > them.
    >
    >
    > I'd very strongly argue with this statement … Personally, I do use IB
    >
    > just for common things like preferences window with standard controls, etc.
    > […] It's not that IB is horrible, but it's about personal taste,
    > development speed and lot of other things. For example - try to precisely
    > edit auto layout constraints in IB. Sorry, but this is nightmare - mouse
    > heavily involved, … I'm much faster with my macros like …
    >
    > For most developers I’d agree with Thomas, although Robert is right that
    > there are valid reasons for not using IB. I just find that in most cases it
    > saves me time and frustration. Also, if you work in a team, it makes it
    > possible for non-coders to edit the UI: this can be a big time-saver when
    > working with UI designers, when instead of telling you to move something up
    > 3 pixels they can just open the xib and do it themselves.
    >
    > However, people are forgetting that the OP, Harmony, has visual
    > impairments that make it very difficult for him to use GUIs. And (so I’m
    > told) Interface Builder has poor accessibility, particularly around crucial
    > actions like wiring up outlets and actions. Back when he started here a few
    > months ago he was having a terrible time trying to drive it with VoiceOver,
    > and the consensus advice was to put IB aside and create interfaces using
    > code instead.
    >
    > —Jens
    >
    >
    >
    >
    > --
    > Michael David Crawford
    > mdcrawford at gmail dot com
    >
    > Custom Software Development for the iPhone and Mac OS X
    > http://www.dulcineatech.com/custom-software-development/
    >
    >
    >

    --
    Michael David Crawford
    mdcrawford at gmail dot com

      Custom Software Development for the iPhone and Mac OS X
      http://www.dulcineatech.com/custom-software-development/
  • Just curious, didn't check ZooLib, but can you show how do you do this in ZooLib? Short example? I mean text fields stacked vertically for portrait and laid out horizontally for landscape?

    On Thursday, 23. May 2013 at 23:07, Michael Crawford wrote:

    > I've never found Auto Layout to work well for me. I far prefer ZooLib's
    > method, despite having to do my design in C++ source.
    >
    > Erica Sadun his a nice method for handling autorotation for the cases where
    > Auto Layout isn't going to work. You create two extra views in your nib
    > just for use as templates, one portrait the other landscape. There is a
    > numeric field in each Cocoa Touch view that is not used much, called id I
    > think, but in the templates you give each view a unique id number. Then
    > you use a method called I think RepositionSubviews that adjusts the layout
    > coordinates of each on-screen view to be the same as the view with the
    > corresponding template.
    >
    > It's in her book The iPhone Cookbook. I recommend it highly.
    >
    > This enables your portrait windows to be laid out completely differently
    > from your landscape windows. For example in my App Warp Life, a Conway's
    > Life game, the user can set the size of the cell grid in the Settings
    > window. In portrait, the width UITextField is above the height, in
    > landscape the height is to the right of the width. AutoLayout can't do
    > that.
    >
    >
    > On Thu, May 23, 2013 at 1:50 PM, Jay O'Conor <joconor...> wrote:
    >
    >> Does Auto Layout not address this issue for you?
    >>
    >> Interface Builder Help: Auto Layout: Understanding Constraints<http://developer.apple.com/library/ios/#recipes/xcode_help-interface_builde
    r/articles/UnderstandingAutolayout.html
    >
    >>
    >>
    >> Regards,
    >>
    >> Jay O'Conor
    >> <joconor...>
    >>
    >> On May 23, 2013, at 10:44 AM, Michael Crawford <mdcrawford...>
    >> wrote:
    >>
    >> It is distressing to me that Interface Builder uses explicit, fixed
    >> coordinates for positioning and sizing its widgets.
    >>
    >> That means that, for localization for example, to accomodate the different
    >> numbers of characters in the various languages, you have to create
    >> different nibs for each locale.
    >>
    >> ZooLib (http://www.zoolib.org/) doesn't have a visual design tool, so your
    >> UI has to be laid out with explicit C++ code. But it has a very ingenious
    >> layout mechanism which quite fluidly and intelligently adjusts for changing
    >> sizes, as well as window resizes.
    >>
    >> Harmony, give ZooLib a try. It's a cross-platform application framework.
    >> It runs in particular on OS X and iOS.
    >>
    >> It hasn't had a tarball release in eons. That doesn't mean its development
    >> has been abandoned, just that all its users get the code from revision
    >> control.
    >>
    >> It's on both sourceforge and github. I haven't tried the github stuff, but
    >> that will be more current I think. The tarball on sourceforge, while quite
    >> old, is quite stable.
    >>
    >> Best,
    >>
    >> Mike Crawford
    >> <mdcrawford...>
    >>
    >>
    >> On Thu, May 23, 2013 at 9:47 AM, Jens Alfke <jens...> wrote:
    >>
    >>
    >> On May 22, 2013, at 11:19 PM, Robert Vojta <robert...> wrote:
    >>
    >> On Thursday, 23. May 2013 at 2:03, Thomas Davie wrote:
    >>
    >> I'd really very strongly suggest that you just use Interface Builder.
    >>
    >> Your user interface is essentially data, not code. I doubt (and hope) very
    >> much that you don't write code to fill up a buffer with image data at
    >> runtime, rather than storing images in data files. The same logic applies
    >> to your UI – store your archived objects in a nib file, and use IB to edit
    >> them.
    >>
    >>
    >> I'd very strongly argue with this statement … Personally, I do use IB
    >>
    >> just for common things like preferences window with standard controls, etc.
    >> […] It's not that IB is horrible, but it's about personal taste,
    >> development speed and lot of other things. For example - try to precisely
    >> edit auto layout constraints in IB. Sorry, but this is nightmare - mouse
    >> heavily involved, … I'm much faster with my macros like …
    >>
    >> For most developers I’d agree with Thomas, although Robert is right that
    >> there are valid reasons for not using IB. I just find that in most cases it
    >> saves me time and frustration. Also, if you work in a team, it makes it
    >> possible for non-coders to edit the UI: this can be a big time-saver when
    >> working with UI designers, when instead of telling you to move something up
    >> 3 pixels they can just open the xib and do it themselves.
    >>
    >> However, people are forgetting that the OP, Harmony, has visual
    >> impairments that make it very difficult for him to use GUIs. And (so I’m
    >> told) Interface Builder has poor accessibility, particularly around crucial
    >> actions like wiring up outlets and actions. Back when he started here a few
    >> months ago he was having a terrible time trying to drive it with VoiceOver,
    >> and the consensus advice was to put IB aside and create interfaces using
    >> code instead.
    >>
    >> —Jens
    >>
    >>
    >>
    >>
    >> --
    >> Michael David Crawford
    >> mdcrawford at gmail dot com
    >>
    >> Custom Software Development for the iPhone and Mac OS X
    >> http://www.dulcineatech.com/custom-software-development/
    >
    >
    > --
    > Michael David Crawford
    > mdcrawford at gmail dot com
    >
    > Custom Software Development for the iPhone and Mac OS X
    > http://www.dulcineatech.com/custom-software-development/
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today