I'm looking for a grid view / table view / spreadsheet-type control for Cocoa and can't seem to find anything that's in any reasonable state.
I've tried using NSTableView but it's not really meant to be a single cell control.
NSCollectionView doesn't seem to be right either.
Any ideas?
While Matt Ball's spreadsheet view (https://github.com/mattball/mbtablegrid/, mentioned above) is several years old, it does still compile on El Capitan. It must be easier as a starting point than working from scratch. There are several forks of the repository, most notable this one that does seem to be actively developed:
https://github.com/pixelspark/mbtablegrid
It seems like it would be better for those interested to pool contributions than create something new!
We now have NSGridView, which is most likely what any future person reading this will want to use.
Related
I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!
Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.
I've inherited a project that uses ~100 Xcode storyboard scenes. Trying to add to this project has been a nightmare for the following reasons:
My machine (late 2011 Macbook Pro 13inch with non-SSD drive 16GB running 10.8 + XCode 4.4) crawls to a halt on storyboards. In some cases I'll move a scene and it will take 10 seconds to update its position.
When I modify a scene (create a segue between two scenes, etc) in some cases all the scenes disappear. I have to do a "select all" on the sidebar to get them back.
Navigating a specific storyboard scene is absolutely frustrating. There's no apparent way to sort the storyboard scenes by name.
The filter feature below the scenes sidebar kind of lets me find the scene I'm looking for, but has the frustrating side effect of filtering out the attributes (segues, views, etc) of the specific scene I'm looking for. So if I need to modify the "add_new_guy" segue for "Person View Controller", and I type "Person" in the filter, I get the Person View Controller sans the add_new_guy segue. If I delete the text in the filter to make the segue appear, I'm taken back to the top of the scene list and (most likely) away from the Person View Controller at the other end of it. I end up scrolling all the way down the scene list manually looking for the specific scene I want to change.
I've spent hours googling solutions and nothing useful has appeared. Any suggestions on how to improve the storyboards situation or pointers to things in XCode I've stupidly overlooked?
Disclaimers:
a) I am well aware that moving to nibs would solve the problem and 100 storyboard scenes is nuts, but I've inherited the code and I'm expected to do storyboards for at least the next year.
b) I'm aware that it's possible to split out the project into several storyboards. I might look into this if I have time.
c) I've heard that some problems may be caused by having two storyboards open at once, which I've tried to avoid as much as possible.
d) Filing a bug with Apple's regarding storyboards is already on my to-do list.
First, work on splitting your storyboard up into smaller storyboards. I would recommend a maximum of 4-5 view controllers per storyboard. It will be a giant headache at first, just work on it over time. Take a look at RBStoryboardLink, which allows you to connect them "by allowing 'pseudo-segues' between UIStoryboards. These segues can be built without leaving Interface Builder and without writing any extra code". This will give you:
The ability to make abstract super classes in storyboards for very similar view controllers
Smaller, more manageable files that don't bring your computer to a halt
Fewer merge conflicts when working as part of a team (assuming your project is under version control)
Second, tell your boss to immediately purchase you a new, way better development computer. They'll make back the $3-$4k in more efficient development time in a matter of days. (Or, if this is contract work… buy a new one yourself.)
And, please indulge my slightly off-topic comment.
Regarding this statement:
I'm expected to do storyboards for at least the next year
Work expectations are always negotiable. Your boss likely thinks "switching from storyboards to code will cost more time than it will save." If this isn't true, say so.
Is there a way to get colored checkboxes like in iCal without using custom drawing?
I have looked through the documentation but can only find how to change the background and text color.
You can achieve something at least similar to the colored checkboxes in iCal by enabling Core Animation for the checkbox and adding a "Hue Adjust" (in "Color Adjustment") content filter. If the color is static, this can be done entirely within Interface Builder, no code needed.
Be careful, though, as sometimes enabling Core Animation for various views causes strange bugs (for example, WebViews don't play nice with Core Animation views).
If you want to do it programmatically, take a look at the documentation for CIFilter (that's a link), which you use with the NSView instance method setContentFilters: (also a link).
It's a bit dated (runs back on 10.3), but Matt Gemmell published a some code for doing colored checkboxes a few years back.
http://mattgemmell.com/source
Look for "iTableView."
I looked at the code when it was first available, but not since. There might be a better way to do it at this point.
I'm afraid not. I'm not sure if the AHIG forbids this sort of thing or not, (it probably does), but the reason iCal gets away with it is because, 'Hey! Why not?'. Also, it's an Apple application, so yeah.
It can still be done, of course, but not without custom drawing. Personally, I'd advise against it, and rather see if what you are trying to achieve could be achieved some other way. If not, you could possibly use some of the data files from iCal to build your checkbox. (Unsure of how kosher that would be, but 'Hey! Why not?'.)
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!
I'm trying to create a very simple selection list widget based on NSOutlineView. However, I'm having a hard time figuring out how to display an icon and a label right next to it, which is really the expected behavior in all the mainstream implementations of that kind of widget out there (iTunes, mail, Finder,...).
So far I am just binding two separate cells, but then when I'm expanding the tree, the icon cell grows larger and a gap appears between the icon and its accompanying label. I know I can probably overcome this problem by extending NSCell and provide a custom class, but as what I'm trying to achieve is really the standard thing, I can't be resigned to accept that there isn't a simpler solution.
Candide
Sadly, there isn't a 'text and icon' cell that you can just use, fresh out of the box as you would like. However, when I was working on a project, I found that Apple released some sample code that implements this, since it is such a common idiom.
This can be found here, specifically ImageAndTextCell.h/m
It can help teach you about UI customization by reading through this example, but scratching that, just dropping the ImageAndTextCell straight into your project should do just fine.
You need to create ImageAndTextcell to combine text and icon..
you can create ImageAndTextcell like this Sample Project