I am working with AutoLayout and am using a library called FLKAutoLayout. When I have a conflict the autolayout debug messages that I am used to do not always show useful information about the constraints in conflict.
Has anyone seen this before and know how to resolve these messages?
From taking a look at FLKAutoLayout it looks like your problem is with this line in NSLayoutConstraint+FLKAutoLayoutDebug.m :
`return [description stringByAppendingFormat:#" %# (%#, %#)", asciiArtDescription, [self.firstItem flk_nameTag], [self.secondItem flk_nameTag]];`
asciiArtDescription is a private method on NSLayoutConstraint, while flk_nameTag is an property added as an "associated object".
Are you working in Swift? It could be something interfering with the program's ability to do those two things, even though it's in objective-C code. You could try creating a test project in Objective C that recreates the warnings to see if they appear.
Related
The debug view hierarchy is a great way to view they different layers that make up the UI, but as far as I can't tell there is no way to see what outlet reference names the objects have. They are simply referred to as what type of object they are. For example, a button is just refered to as UIButton rather than the name of the outlet. Yes, it's possible to see in what viewController it resides, but it' not foolprof and it can still be very hard to track down certain objects.
So, is there a way to see what the reference outlets of the objects are called?
UIView.accessibilityIdentifier does that trick.
For NSLayoutConstraints, its description in warning log (or po constraint) contains more details after set UIView.accessibilityIdentifer.
Before set accessibilityIdentifier, it's something like
<NSLayoutConstraint: 0x6000037766c0 UILayoutGuide: 0x600002d6c620'UIViewSafeAreaLayoutGuide'.trailing == UILabel: 0x7fee70712780.trailing + 132 (active)>
After set accessiblityIdentifier,
<NSLayoutConstraint:0x6000037766c0 UILayoutGuide:0x600002d6c620'UIViewSafeAreaLayoutGuide'.trailing == First-ID.trailing + 132 (active, names: First-ID:0x7fee70712780 )>
For view debugger, you can check accessibilityIdentifier as follows
No, there is not (unfortunately).
The information is not maintained at runtime to my knowledge, so you also won't be able to use lldb from Xcode's console to figure it out.
Probably worth a feature request to Apple!
https://feedbackassistant.apple.com/
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;
How can it be possible, that an app, that runs in objective-c without problems, get the "Unable to simultaneously satisfy constraints"-error after moving it to swift?
I´ve only copied the views of an app to a swift-project and now get this error. But when the constraints are valid in objective-c, how is it possible, that they are invalid in swift???
This is the view, I want to display:
When all fields are filled as in the screenshot, now error appears.
The error only is thrown when one or more fields are empty!
This are the contraints of this view
The constraints are the same as in the objective-c-Version...
What might i show u more, Mr Beardsley?
I uploaded the swift-Project to here
u can find the objective-c-version (very large!) here
to get the error, u must go this way:
Mr. Rob Mayoff was right: my Swift project has different constraints than my Objective-C project. :-(
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.
I would like to find a way to see what happens while my XAML is being loaded. What classes are being instantiated, and in what order? Which properties are being set, to what values, and in what order? Which methods are being called (e.g. BeginInit, EndInit, etc.), in what order, and with what parameters? That sort of thing.
(If anyone's curious as to why, it's because the XAML loader is doing something magic that I can't duplicate in code, and I'm trying to figure out what it is.)
My first idea: Configure VS to debug into the .NET source code, and single-step through the XAML-loading code to see what happens. Unfortunately, source stepping has been busted for months, and there's no sign of that changing.
My second idea: Make my own classes that descend from WPF classes, override OnPropertyChanged, and do a Debug.WriteLine. Unfortunately, one of the classes I want to know about (BitmapImage) is sealed, so I can't descend from it.
Anyone have other ideas on how I could get some visibility into what the XAML loader is doing? Are there any tools (profiler, maybe?) that could give me a call graph? Is there a way to turn on some kind of logging in the XAML loader? Thoughts / suggestions?
Edit: The article Steve linked to does have the answer, though their sample code makes every event get displayed twice. For reference, here's how to make this work in code (no app.config changes required). Add these lines before the InitializeComponent() call (or type both lines into the Immediate window in the debugger):
PresentationTraceSources.Refresh();
PresentationTraceSources.MarkupSource.Switch.Level = SourceLevels.All;
This will cause detailed output to show up in VS's Output window, including the properties that get set magically behind the scenes.
You can trace a lot of the binding and loading with system.diagnostics. I've found a number of problems using this namespace. Its unwieldy like everything else in WPF, but it works. You can see what's getting set and where.