I have written an installerplugin to show a custom pane in the pkg installer. I want to display the pane only during first install and hide it when upgrading. I know how to find out if the package has already been installed or not but I am not able to figure out the logic of showing/hiding the installerpane based on a runtime decision.
One method I could think of is that the installerplugin contains an Installersection outlet called parentSection. And installersection class has a function shouldload whose return value decides whether the section should be loaded or not. And this article mentions that the installersection methods can be overloaded. But I am unable to think of a way to overload the functions as parentSection is just an object inside the installerpane class.
Even though it's been several months since sanmukh asked this question, I figured I would post the answer since I figured out how to do this.
The solution is indeed to subclass InstallerSection and override the shouldLoad method. To use it, you have to edit your plug-in's Info.plist file and change the entry for "NSPrincipalClass" (or "Principal Class" as it appears in Xcode 4) to be your new InstallerSection derived class. Afterwards when your package loads, the new shouldLoad method will be called, allowing you to programmatically decide whether the installer pane should be visible.
Related
Does Xcode have a way to show the caller function of a method? I want to know all of the calling functions of a method in a class. A solution would be to find the method in the project, but sometimes different classes have methods with the same name - That could find us a method we're not looking for..
Many other IDEs have this capability, such as Visual C++ 2003/2005/2008,Eclipse ...
Can you do this in XCode?
Xcode 4.4 intrudced this functionality:
New Features in Xcode 4.4 (Scroll down to 'Find and Search Additions')
Move your cursor on top of the function you are interested in
Open the Assistant editor(⌃ +⌘+Enter)
On the top of the assistant editor, Select 'Callers'
You will see a list of all the function that's calling your function
Not the as effective as other IDEs, but does the job.
Yes. Set a breakpoint inside your method, then when it breaks, there are two spots to see a stack. First is in Xcode's "console" area (usually the bottom middle), there is a top-bar which may not immediately appear to be navigable, but it is a select-style UI control which has the entire stack in it. Selecting a different level shows you that scope's variables, etc. and pops your editor to that exact file (where you can mouse-over variables to see their in-memory real-time values). Second is in the left-hand area (where you normally browse files). There is another tab there (besides the file browser) for exactly this purpose. There is a slider at the bottom which controls how many "steps" in the stack you see; clicking on one has a similar affect.
For simple refactoring such as method re-naming, you can use the contextual-menu when you right-click a selected method-name, and Xcode will replace all identical selectors in your project. However, this does not address what you mentioned about different classes having methods with the same signature. It does, however, give you a very nice interface for reviewing the changes in-context and easily accepting or rejecting them one at a time.
It might be noted, however, that changing method signatures often may be a sign of poor design, and particularly if you have to do it with methods which have the same signature on different classes (which are not "siblings" and therefore should both get the rename)
I'm implementing a Visual Studio Language Service for a custom scripting language used internally at my company, and I've run into an issue with the navigation bar implemented as a subclass of TypeAndMemberDropdownBars. The subclass is created by my LanguageService subclass' LanguageService.CreateDropDownHelper method.
In the OnSynchronizeDropdowns method I'm iterating through the types defined in the file and adding DropDownMembers to the passed-in array to fill out the navigation bar. The issue I'm seeing is that the first item in the array is being duplicated and placed at the end of the listing by code that I don't have access to. This extra item does not behave correctly when selected (nothing happens), but doesn't seem to cause any other issues; the rest of the items in the list work fine. Additionally, this only seems to happen for the type dropdown box - the members dropdown box does not display this behavior.
I'm hoping someone else has seen and resolved this issue and could provide some assistance. Thanks!
Turns out this was caused by me calling LanguageService.SynchronizeDropdowns from my LanguageService.ParseSource method, which was being called on a background thread. I've fixed the problem by setting a flag when ParseSource does a Check parse, and then implementing a check for that flag in my LanguageService.OnIdle function that will call SynchronizeDropdowns. It's now working as expected!
A better solution is to implement the LanguageService.OnParseComplete callback, and call SynchronizeDropdowns from there. OnParseComplete is always called from the main thread, so this prevents any synchronization issues from coming up, and also keeps you from having to keep track of whether or not you need to call SynchronizeDropdowns().
Okay, I'm fairly new to Cocoa and Objective-C, and to OOP in general.
As background, I'm working on an extensible editor that stores the user's documents in a package. This of course required some "fun" to get around some issues with NSFileWrapper (i.e. a somewhat sneaky writing and loading process to avoid making NSFileWrappers for every single document within the bundle). The solution I arrived at was to essentially treat my NSDocument subclass as just a shell -- use it to make the folder for the bundle, and then pass off writing the actual content of the document to other methods.
Unfortunately, at some point I seem to have completely screwed the pooch. I don't know how this happened, but closing the document window no longer releases the document. The document object doesn't seem to receive a "close" message -- or any related messages -- even though the window closes successfully.
The end result is that if I start my app, create a new document, save it, then close it, and try to reopen it, the document window never appears. With some creative subclassing and NSLogging, I managed to figure out that the document object was still in memory, and still attached to the NSDocumentController instance, and so trying to open the document never got past the NSDocumentController's "hmm, currently have that one open" check.
I did have an NSWindowController and NSDocumentController instance, but I've purged them from my project completely. I've overridden nearly every method for NSDocument trying to find out where the issue is. So far as I know, my Interface Builder bindings are all correct -- "Close" in the main menu is attached to performClose: of the First Responder, etc, and I've tried with fresh unsullied MainMenu and Document xibs as well.
I thought that it might be something strange with my bundle writing code, so I basically deleted it all and started from scratch, but that didn't seem to work. I took out my -init method overrides, and that didn't help either. I don't have the source of any simple document apps here, so I didn't try the next logical step (to substitute known-working code for mine in the readFromUrl and writeToUrl methods).
I've had this problem for about sixteen hours of uninterrupted troubleshooting now, and needless to say, I'm at the end of my rope. If I can't figure it out, I guess I'm going to try the project from scratch with a lot more code and intensity based around the bundle-document mess.
Hard to tell without code but I would suggest sending:
closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
... to the document controller and then looking at the controller as it is passed to the delegate to see how its state changes.
If the controller closes the document when you send the explicit message then your problem is with the binding to the window.
I followed Chapter 8 of Hillegass to implement the RaiseMan application there.
Then I decided to follow the same process to implement the code for an exercise in a Cocoa programming class that I am taking, but I got the following very cryptic error message after building and running.
Cannot create BOOL from object <_NSControllerObjectProxy: 0x100460e30> of class _NSControllerObjectProxy
I have no idea what this error message means. Doing a Google search brought up some hits, but their remedies seemed to be to do things that I was already doing.
I stared at all the connections and assignments that I made in Interface Builder and nothing looks obviously wrong.
So I went into the debugger and set a breakpoint inside the init method of the MyDocument class and it is being called twice. How could that happen? What should I be looking for that would make the init method be called twice? The stack trace shows that init is called by system functions that we did not write ourselves.
For comparison, I went back to the project that follows Chapter 8 of Hillegass and set a breakpoint inside the init method of the MyDocument class, and it is being called once ( which is what one would expect ).
Cannot create BOOL from object <_NSControllerObjectProxy: 0x100460e30> of class _NSControllerObjectProxy
It appears you've bound a BOOL property to a controller, and not specified a model key path. Most probably, you bound one of the Cocoa view classes' built-in bindings, such as enabled or editable.
Look through your nib for views whose enabled or editable you've bound, and make sure they are all bound to the correct model key path.
I just ran into this myself. And then I remembered seeing something odd before, whose significance hadn't struck me at the time. Which is that in my XIB file, there was a "My Document" object, in addition to the "File's Owner" object (which is what actually represents the document in the XIB file). I have no idea how it got there, but I deleted it in IB, recompiled, and presto, [MyDocument init] only gets called once now.
Is it possible to take a DLGTEMPLATE and use it as a CWnd-derived control for placing in any other CWnd?
I have a dialog template that I want to use on one of my CDockablePanes
Your question isn't clear, please rephrase. If you're asking if it's possible to instantiate a control from a DLGTEMPLATE and put that instantiation on another dialog or as the child of another control, then yes, it is. It's a major PITA though, read through the Old New Thing blog (the series on dialog templates) if you want to know the details. If you just want to get it to work, use the CDlgTempl class from one of the MSDN samples; start here: http://support.microsoft.com/kb/155257. It won't make CWnd-derived controls but they're not what you want if you're asking what I think you are; you'll get a CDialog-derived object (which is itself derived from CWnd obviously, so in that sense it does give you what you ask).