I am new to Cocoa and would like to know how to hide an NSPanel when a timer tick, I have tried to call
[myNSPanel orderout:self], the code runs but the panel is still there. Do I need to do something different? Thanks in advance.
For one thing, the selector is orderOut:, and selectors are case-sensitive, so if your code actually says orderout:, then you're getting a does-not-respond-to-selector exception (which you can see in the Debugger Console) and that's why your code isn't working.
If it still doesn't work after you fix that, make sure myNSPanel (which I assume is an outlet) is actually hooked up to the panel in question. A very common mistake is to forget to connect the outlet; when you do this, the pointer in the outlet variable is nil, and a message to nil simply does nothing.
You can check this by logging the pointer: NSLog(#"%p", myNSPanel);. After that statement runs, the Debugger Console will contain a line telling you what pointer was in the myNSPanel variable. If it's 0x0, that's nil.
Related
I am using an NSCollectionView where each NSCollectionViewItem uses a QLPreviewView to get a rendering of a file's content.
(This is an attempt at a file browser for images and other previewable files.)
Initially, this works fine.
However, once collection items are getting re-used, I get an assertion error (both in 10.13 and 10.14):
[QL] Assertion failure (unreachable code) - [… MyPreviewView activated … doc:[QLPreviewDocument …]] is already activated
Apparently, before I can re-use a NSCollectionViewItem, the previously used QLPreviewItem needs to be set to inactive state somehow. How do I do that?
I've tried to send the close message to the QLPreviewView instance but that doesn't make a difference.
I also do not get a dealloc call on my QLPreviewView subclass, which suggests that the object is still referenced by something else, possibly the QLPreviewDocument, which then gets confused about the change of state.
I have made a demo project available on github: https://github.com/tempelmann/NSCollectionViewWithQLPreview
To test: Run it, then scroll down. When reaching items 50 to 60, the assertion will be triggered.
The fix is to set QLPrewiewView's shouldCloseWithWindow property to NO.
This, I suspect, tells the controller behind the scenes not to attach itself to higher level structures, i.e. tells it to remain self-sufficient.
So, adding this line to the code that sets up a new MyPrewiewView object in the sample code's ViewController.m file prevents the error:
qlView.shouldCloseWithWindow = NO;
When I call dequeueReusableCellWithIdentifier it is freezing my code and does never return any cell (or nil) I change the code from my custom class to a UITableViewCell to be sure the problem wasn't in my class, I also create a brand new empty cell to call with the identifier.
I add a log before and after the call for dequeueReusableCellWithIdentifier as you can see in the screenshot the one before gets called once and the one after never.
I try to clean and build, clean the project folder, delete DerivedData, restart the computer. I can't see any exceptions or what is really holding the code.
Any suggestions?
I am not sure what happened to XCode, but, if someone find the same problem here is what I had to do.
I didn't find anything wrong with the cell (yes I was using storyboard and the identifier was set correctly) and noting was wrong with the code in the custom class as well. I even went to the point of create a secondary custom class and custom cell and it did not help, so I try to put a invalid identifier and even there XCode did not return me an error (as it should).
I had to delete my custom cell from the storyboard, as soon as I did that all start to work again, first the error that the identifier didn't exist, than the temporary one start to work, than I recreate the original one (exactly as before) and all start to work again.
Very overkill but worked for me. Thanks for all the help!
It is expressed that you are printing println("return dequeueReusableCellWithIdentifier"), but can't see your return cell code at the end of your function, that must conform to your function expectation.
I hope I can explain this problem decently well!
I'm trying to implement a ReWire audio device as a Delphi .dll. If you don't know what ReWire is, don't worry about it. What's important is that my code compiles into a .dll, and I get calls from the ReWire system into my .dll to open up a display, check if the display is opened, and close it again.
When I get the call to launch, I do the following:
if not Assigned(form) then
form := TMyForm.Create(nil);
form.Show;
where form is a global variable inside of my Delphi library (maybe a problem?). I have hooked up MyForm's OnCreate event to do some interesting things like prepare an array of stuff I want to work with.
So far everything's good. My form has a little button in it that opens up a TOpenDialog. I find that as soon as that dialog closes, somehow the OnCreate event is firing again in my form!
I have checked that OnDestroy is not being called, so I have no idea why OnCreate is getting called again.
Unfortunately I'm not really sure what information is relevant, but here's the call stack the first time around (when the form is first set up):
As expected, ReWire is making a call into my .dll to Launch the Panel application, so I create my form. Great, things are looking good.
Then inside my form, I open up a little dialog, select a file, and do some operations. Out of left field, OnCreate is called again, and here's the call stack that time:
It's a crazy party of calls! Reaper (at the bottom) is the ReWire host I'm using to test my application, but I have no idea what's going on inside that stack trace because none of it is my code. Suddenly the event just gets called when I don't think it should, because OnDestroy wasn't even called.
The only other important thing I can think of is that if I print out the address of the Sender, it's different each time, so it's somehow getting Created again or something, but I've checked that I only call the MyForm.Create once.
Any ideas as to how this type of thing could happen?
In the first stack trace, the OnCreate call is preceded by a call to TCustomForm.Create(), which is correct behavior. In the second stack trace, the OnCreate call is preceded by a call to TObject.Create() instead, which is not correct behavior. That leads me to think that something in your button OnClick event handler is either constructing an object with a bad VMT, or is otherwise corrupting memory in general and causing a bad jump into code that just happens to be occupied by your TForm class. Either way, double check your OnClick logic for bugs.
Check on (any)where you are setting the form variable to nil. It may be that it's being set to nil without freeing the form it's pointing to, and so next time your launch code is called it's creating another instance of the form.
A simple 10.6 Cocoa app I wrote that basically draws a regular window with some buttons and text has been spewing hundreds of console log messages:
<Error>: CGContextSetCompositeOperation: invalid context 0x0
I do not directly call drawRect: and always use setNeedsDisplay:YES when I need to refresh.
Interestingly, this error does not happen on all machines, I'd say about 50% get the error. However, the program works fine in either case!
Anyone got any clue as to what this error means, where it's stemming from, and more importantly, how can I suppress/get rid of it?
Thanks
Try setting a breakpoint on CGPostError. If you can break on the logging, you can hopefully figure out what's going on.
You shouldn't be looking to just suppress it. It means context creation is failing (thus NULL gets passed for some context parameter), and that's not good.
I followed the Tutorial in Cocoa Programming For Mac OS X to create a preferences window but am returned with 2 warnings which stop it from working/opening. These are the two warrnings:
alt text http://snapplr.com/snap/varq
alt text http://snapplr.com/snap/qmxc
How can I resolve the problem?
The warnings mean the object in question doesn't (as far as the compiler knows) implement those two methods. This means either your window controller is not inheriting from the right superclass, or the pointer to the window controller is of the wrong type. It may or may not be the reason your window isn't opening, it's impossible to tell from the warnings alone.
edit: from your full code it looks like you're declaring your controller as inheriting from NSObject, instead of NSWindowController.
Just as it says, showWindow isn't defined on the PreferenceController class. In C++, this would be an error because it's statically typed and would say "method not defined", but since Objective-C is more flexible, this is only a warning. Without seeing the code, it's hard to tell what your mistake is though.