|
Okay this I don't get: In AuxObject.m: code:The window in the AuxWindow nib is an NSWindow subclass (for intercepting events and handling some in special ways, this also works fine). I also need to be able to access some properties on AuxObject, so I figured I'd do this in AuxWindow.m: code:Edit: gently caress it, I'll just throw an outlet in the AuxObject that I can bind to the window and do it backwards. Carthag Tuek fucked around with this message at 22:07 on Jan 19, 2012 |
#
?
Jan 19, 2012 21:37
|
|
|
|
| # ? May 16, 2024 21:08 |
|
|
Without looking at the documentation or thinking about it too hard... you probably need to make a connection in IB between windowController and the Parent object.
|
|
#
?
Jan 19, 2012 22:06
|
|
|
I'm guessing it has something to do with File's Owner being AuxObject instead of the window controller, but it works this way now, so I'll let that simmer unless there's some even better solution.
|
|
#
?
Jan 19, 2012 22:24
|
|
|
Carthag posted:But [self windowController] is nil?! How do I get to the owner then? The documentation doesn't say anything about special cases where this might happen. When are you calling [self windowController] in AuxWindow?
|
|
#
?
Jan 20, 2012 00:08
|
|
|
Toady posted:When are you calling [self windowController] in AuxWindow? So I could get at the owner, and thereby access properties on AuxObject. Edit: Lol sorry, I thought you wrote "why" ... It was being called during my overridden sendEvent:(NSEvent *)event, so the window was indeed up & running. Carthag Tuek fucked around with this message at 03:12 on Jan 20, 2012 |
|
#
?
Jan 20, 2012 03:10
|
|
|
Carthag posted:So I could get at the owner, and thereby access properties on AuxObject. He asked when, not why.
|
|
#
?
Jan 20, 2012 03:12
|
|
|
Oops yeah sorry. But yeah, the window is definitely alive.
|
|
#
?
Jan 20, 2012 03:32
|
|
|
I wonder if event processing can occur before the window is associated with its window controller.
|
|
#
?
Jan 20, 2012 07:57
|
|
|
Do you ever reference your window directly through the window controller? I've run into weird issues when using NSWindowController where unless you actually try to access the controller's window it won't get set up properly.
|
|
#
?
Jan 20, 2012 09:55
|
|
|
Gordon Cole posted:Do you ever reference your window directly through the window controller? I've run into weird issues when using NSWindowController where unless you actually try to access the controller's window it won't get set up properly. That makes sense because NSWindowController loads its nib on-demand when -window is called. However, he also said File's Owner in his window's nib is set to AuxObject instead of the window controller which might be a more likely cause of his issue. Toady fucked around with this message at 10:12 on Jan 20, 2012 |
|
#
?
Jan 20, 2012 10:08
|
|
|
Yeah, I also tried going [wc window] from AuxObject, at a later point than alloc/init. Still nil. So I think it's some File's Owner related thing too. Anyway as I mentioned I got it to work by using an IBOutlet and having the window keep its values and then querying them from the object, instead of the window reporting directly to the object. In other news, NSPopovers are incredibly easy to implement and look slick as hell. Carthag Tuek fucked around with this message at 11:37 on Jan 20, 2012 |
|
#
?
Jan 20, 2012 11:33
|
|
|
I'm reposting a question asked on the Cocos2D forum, since it is quite a complicated issue and there are more posters here. I have a sprite added from a method call in init using convertToNodeSpace, and it is placing it incorrectly. I use practically use the same code elsewhere to place sprites with convertToNodeSpace (placing it in the center of the iPad screen) and it works fine. My guess is before init returns self, convertToNodeSpace cannot make an accurate conversion. Is this the problem most likely, and is there any known solutions?
|
|
#
?
Jan 20, 2012 18:34
|
|
|
sleepness posted:Hey friendly programmer goons. I'm looking for a developer looking for some extra cash to help me with a project I want to implement. It's very simple, so I don't think you need to be a professional to do this. Am I the only person who finds an app that can tell you what race you are and has the text "Go back home!" disturbing. Your not an australian by any chance?
|
|
#
?
Jan 20, 2012 18:38
|
|
|
I think he meant race as in runners or cars trying to finish a course first. vv they call me the humor slayer. xzzy fucked around with this message at 18:49 on Jan 20, 2012 |
|
#
?
Jan 20, 2012 18:40
|
|
|
xzzy posted:I think he meant race as in runners or cars trying to finish a course first. I know , I was just pulling the piss
|
|
#
?
Jan 20, 2012 18:48
|
|
|
LP0 ON FIRE posted:I'm reposting a question asked on the Cocos2D forum, since it is quite a complicated issue and there are more posters here. So it looks like at different points in the sprite's lifetime, convertToNodeSpace behaves differently? I haven't used cocos2d, but have you tested this (in the same object)? Like putting the conversion later on, and seeing if it gives a different result than during init? I am trying to get out of the habit of NSLog-debugging, but sometimes that's just the easiest. Logging what it does during init, and then later on, and comparing...
|
|
#
?
Jan 20, 2012 18:55
|
|
|
Carthag posted:So it looks like at different points in the sprite's lifetime, convertToNodeSpace behaves differently? I haven't used cocos2d, but have you tested this (in the same object)? Like putting the conversion later on, and seeing if it gives a different result than during init? Exactly. It gives a different result if I use convertToNodeSpace later on and outside of init. I heard that it's a problem that I'm calling it on a node that does not yet have a parent. There has to be an alternate way of getting the center coordinates of the iPad/iPhone screen area (not the entire current map) and placing the sprite there. edit: Fixed it! I have my method call to place this sprite right before return self in init. Somehow that works. LP0 ON FIRE fucked around with this message at 20:14 on Jan 20, 2012 |
|
#
?
Jan 20, 2012 19:28
|
|
|
Isn't there something in CCDirector that will tell you the screen size, then you can just divide by two? Seems more reliable than relying on accidental behavior that may break/change later on. edit: [[CCDirector sharedDirector] winSize] should tell you the screen size, then decide each axis by two to get the center of the screen. edit2: if you're putting your code after the if(self = [super init]) block, that will cause issues if the object can't be created for some reason. Doc Block fucked around with this message at 08:18 on Jan 21, 2012 |
|
#
?
Jan 21, 2012 08:09
|
|
|
Doc Block posted:edit2: if you're putting your code after the if(self = [super init]) block, that will cause issues if the object can't be created for some reason. yeah but I doubt that is his issue. I mean he wouldn't even get nothing if [super init] failed. E: Oh gotcha. Yeah don't put anything outside the if (self) block in an init.
|
|
#
?
Jan 21, 2012 08:36
|
|
|
I'm just starting out with Xcode, writing an app for iOS. I'm trying to hide a button, but am getting an undeclared identifier error. How do I set the identifier for a control/button/whatever? Identity Inspector->Accessibility->Label? Identity Inspector->Identity->Label? Edit: That's what outlets are for! 30 TO 50 FERAL HOG fucked around with this message at 09:44 on Jan 22, 2012 |
|
#
?
Jan 22, 2012 09:22
|
|
|
For the most part I'm used to writing applications for iOS, but I just started experimenting making stuff for OS X. I'm trying to make a simple video player and followed this tutorial with slightly different names for files. I try opening a MOV file from my application I built, and nothing happens. I can't figure out what's wrong. For anyone that wants to help and check out my project, It's very cut and dry, so someone that's knowledgeable with this stuff I'm sure can easily track it down. In my console, before I even open anything I receive the waring several times "Unable to read symbols for cl_kernels (file not found)."
|
|
#
?
Jan 22, 2012 21:51
|
|
|
Your views and outlets are wired all weird. I "fixed" it by deleting all the windows and views and whatnot in your NIB and putting in new ones. A new window that's just a window (not an inspector or whatever you had it set to), with it's delegate set to File's Owner, and the File's Owner's window outlet connected to this new window. Also, set the class of File's Owner to the name of the class that will actually be responsible for this window, which in your case is VideoFX, not the class for inspector windows or whatever it was you had it set to. Then I added a QT Movie View to the window's view, and set up the autoresizing and bindings as per the tutorial. And now it works fine. Additionally, following the tutorial on my own from scratch worked fine too. Doc Block fucked around with this message at 02:45 on Jan 23, 2012 |
|
#
?
Jan 23, 2012 02:42
|
|
|
Thanks Doc Block! I started off the wrong kind of project with just a delegate, so everything became kind of twisted when I followed this tutorial. I should have started from scratch, but I also wanted to learn what was wrong since most of the experience I have is without using interface builder. I'm deciding to learn not to hate it and give it a try.
|
|
#
?
Jan 23, 2012 03:58
|
|
|
gently caress coder machismo. Interface builder is awesome, once you get the hang of it. People who like coding interfaces by hand are wierd to my thinking.
|
|
#
?
Jan 23, 2012 04:13
|
|
|
I wouldn't like creating iOS apps nearly as much if I couldn't visually lay out at least the overall placement of my major UI elements. It sucks trying to estimate what a good spot for a certain element would be while looking at code, instead of just being able to see it and move or resize it however you want. Also, it sucks having to write and edit giant walls of tedious attribute setting code. Doc Block fucked around with this message at 04:27 on Jan 23, 2012 |
|
#
?
Jan 23, 2012 04:24
|
|
|
duck monster posted:gently caress coder machismo. Interface builder is awesome, once you get the hang of it. I bet it is, but it's sort of over my head to make a ton of crazy connections to buttons that have tweened animation, may or may not be displaying, and sliding transitions into other views, etc, which is exactly what I needed to create for my first app. It was enough pressure that I was just learning Obj-C, and then decided whether or not it was really worth creating a nib for something like a movie player, which would just be a feature that would be recycled throughout the program with different filenames. I can see where it would be really beneficial, like if you had a lot of carefully placed sliders, and it would be much easier to draw those out on a space. But usually I'm going from something like a design from Photoshop and getting button coordinates and then just hardcoding them. It's not that I really like coding interfaces, but sometimes factoring in IB seems like unnecessary extra work.
|
|
#
?
Jan 23, 2012 04:33
|
|
|
Dragging a button from the library, putting it where you want, setting the attributes in the inspector panel, and making the connections in IB is faster than having to look up UIButton in the docs so you can see what all its properties and methods are and then type out the code to set them (and, if you're like me, having to keep flipping back and forth between the docs and your code as you type out the attribute code). As for "crazy connections", all the connections you make in IB are the same as what you'd be making in your code anyway. And with IB you also have the added advantage of immediate feedback if you want to tweak an element's attributes or placement. Doc Block fucked around with this message at 05:04 on Jan 23, 2012 |
|
#
?
Jan 23, 2012 04:52
|
|
|
The thing is, if your interface is tht complex, your probably doing it all wrong. The whole deal with iOS and mac interfaces is they should be simple and as apple-y looking as possible. IF its compliant, your coding in a propper model-view-controller pardgim and are not rolling whats already provided, then chances are your IB <-> Code relationship will be simple. Unless your doing a game, in which case carry on... (Its the one thing I wouldnt use IB on , cos I'd rather use Cocos2d)
|
|
#
?
Jan 23, 2012 05:47
|
|
|
Yeah, the one thing I really miss about iOS development when working with Android (so far at least) is the comparative lack of control over interface layout, necessitated by the lack of control over the destination device. What do other devs who work with both platforms think? Personally, I really like the way Android handles behind-the-scenes stuff, but iOS kicks its rear end in everything presentation-related.
|
|
#
?
Jan 23, 2012 06:52
|
|
|
PT6A posted:Yeah, the one thing I really miss about iOS development when working with Android (so far at least) is the comparative lack of control over interface layout, necessitated by the lack of control over the destination device. Considering I'm alergic to Java at an almost genetic level, my opinion of Android has been both terrible and completely and irrationally biased!
|
|
#
?
Jan 23, 2012 08:02
|
|
|
duck monster posted:The whole deal with iOS and mac interfaces is they should be simple and as apple-y looking as possible. IF its compliant, your coding in a propper model-view-controller pardgim and are not rolling whats already provided, then chances are your IB <-> Code relationship will be simple. I wish I could have made it Apple-y looking, but it wouldn't have lived up to the expectations of the client. Other than that, it still followed the model-view-controller guidelines. And for the past 11 months I've been working on a game in Cocos2D, so I STILL haven't had any experience really using interface builder! Just now I'm trying to get my feet wet in IB with some personal projects. Doc Block posted:And with IB you also have the added advantage of immediate feedback if you want to tweak an element's attributes or placement. I agree, and it will probably help out a lot with what I'm making now.
|
|
#
?
Jan 23, 2012 15:07
|
|
|
I have an IKImageView subclass showing an image. Some of my Core Data objects contain rects, which I draw as paths on CAShapeLayers, which are sublayers of the ImageView's overlay. All the layers' bounds are the size of the image. This works fantastic. I want to expand this by making it possible to edit (move, resize) or delete the rects. Looking at the docs for CALayer, there's a hitTest:, but this checks whether the point is within the bounds of the layer and wouldn't work. So, what would be the correct (read: most Cocoa-like) way to accomplish this? - Change the layers so instead of their bounds being the size of the image, have them be the size of the rect, and then use an offset to place them on the ImageView's overlay. - Subclass CALayer and override hitTest:? - Use NSViews instead of CALayers? Seems like the first option would be most correct, possibly. Anyone done something similar (hittesting CALayers)?
|
|
#
?
Jan 23, 2012 15:48
|
|
|
IB is great, but it bothers me that not all object attributes can be set in it. Once I realized I was spending half the time in IB and half in code just to get things like buttons to act correctly, I asked why I was working with nibs in the first place. However, it really cemented how interface elements worked. Having the visual cue is a great teacher.
|
|
#
?
Jan 23, 2012 17:58
|
|
|
Can anyone explain how IB actually works? In VS, I can just go look at FormName.Designer.cs, and there's all my property setting and parenting turned into code. Is there an equivalent place I can look for IB? I don't mind things doing things for me, but right now it's a bunch of magic to me, and that drives me up the wall when I'm trying to figure out why something isn't working like I expect it to.
|
|
#
?
Jan 23, 2012 18:08
|
|
|
wellwhoopdedooo posted:Can anyone explain how IB actually works? Storyboards and XIB files are just XML files that describe the interface. NIB files were basically binary versions of XIBs. I'm assuming at XIB load time, this XML is translated on the fly into Obj-C code that is compiled and becomes proper objects etc. I don't think you can see this code though.
|
|
#
?
Jan 23, 2012 18:18
|
|
|
Nibs basically works through the NSCoding protocol. You interact with the properties of the objects when designing your interface in IB, such as setting the frame of a button, the values of things, bindings, all that. When you save it to a nib, the properties & ivars are serialized via encodeWithCoder:. When your app loads a nib and recreates the interface, it does so via initWithCoder: I think the actual coder used is probably a different one than the NSKeyedArchiver you'll normally see when working with NSCoding. They go into it a little bit in the 2010 WWDC talk about custom Cocoa views. That's how you create your own IB view plugins too, like a custom button for instance. Carthag Tuek fucked around with this message at 18:41 on Jan 23, 2012 |
|
#
?
Jan 23, 2012 18:38
|
|
|
wellwhoopdedooo posted:Can anyone explain how IB actually works? Many (most?) other windowing frameworks generate code, which is what you're seeing in the .Designer.cs file you mention. Hence the "do not edit this auto-generated file" warnings you typically find in them. That's not how it works on Mac OS X and iOS. Instead, the objects you drag into Interface Builder and position are serialized as is. Their class name and their attributes just get dumped into XML. Open up a .xib in a text editor sometime, it's fairly readable (if typically verbose). When you build your app, the XML files (aka .xib) get compiled into a custom binary format that used to be the only format Interface Builder used (aka .nib). I believe the main reason for introducing a text format was for sane diffs in source control. I believe the main reason for using a binary format in the app bundle is for efficiency when deserializing. I have no sources for either claim. When a .nib file gets loaded, the objects are deserialized exactly as they were when you serialized them in Interface Builder. It's not running a bunch of code like you'd write if you weren't using .nibs. This is the source of something I always forget to do, causing me to stare blankly at the screen for a minute until I remember: your view subclass's -initWithFrame: is not called when your view is loaded from a .nib. It's -initWithCoder:. So make sure to put any custom initialization in both places (or factor it out into a -commonInit and call that from both). If you're curious about the code behind loading .nibs, have a look at NSNib (for Mac OS X) and UINib (for iOS) as well as NSCoding. (That's why NSWindow conforms to NSCoding despite the warning in the docs saying to never use it: it gets loaded from .nibs). For documentation, have a look at the Resource Programming Guide, specifically the chapter on .nib files. (As an aside, it used to be bizarrely difficult to have an app that contained no .nib files. NSApplication would try desperately to load a .nib, venturing into the system frameworks if it couldn't find one in your app bundle. You also needed to use a private method on NSApplication just to set the main menu. And I think I'm forgetting a few steps in there too. The idea of using .nib files in your apps is basically hardwired into Mac OS X, and they deserialize very quickly, and don't generate code. Don't shy away from using them because of what you've experienced with other libraries.)
|
|
#
?
Jan 23, 2012 18:40
|
|
|
Carthag posted:I have an IKImageView subclass showing an image. Some of my Core Data objects contain rects, which I draw as paths on CAShapeLayers, which are sublayers of the ImageView's overlay. All the layers' bounds are the size of the image. This works fantastic. Why not make the sublayers the size of the actual rects they're drawing, position them appropriately, and then -hitTest: works?
|
|
#
?
Jan 23, 2012 18:41
|
|
|
wellwhoopdedooo posted:Can anyone explain how IB actually works? Imagine you created a form in the VS designer then serialized it to a file. Now imagine you deserialized it and VS examined the real live form to determine what properties to display, etc. That's exactly how IB works and in a sense you can think of it as having the ability to reverse-engineer the visual layout stuff from the actual object, not by reading the code like VS does. In reality the VS designer is doing the same thing in design mode - when you drag a button onto the form it creates a real button window but in design mode and drives what it knows about the button on the generated designer code rather than reflecting on the instantiated button.
|
|
#
?
Jan 23, 2012 21:39
|
|
|
|
| # ? May 16, 2024 21:08 |
|
|
Ah, the serialization (mostly) answers the question. I assume that there's some code that gets run in order to set the IBOutlet-type stuff in the ViewController classes (unless the ViewController instance is serialized too?) but, don't answer that parenthetical unless you know off the top of your head, I plan to research the details as soon as I get the chance. Thanks everyone!
|
|
#
?
Jan 23, 2012 21:51
|
|