I have created a default [Swift] Cocoa application. I attempted to Ctrl drag from the default Open button in the menu to my View Controller in the assistant editor, but nothing happens.
Is my approach wrong? I assume there is some kind of default file chooser dialog, but I do not know how to make it appear or enable the Open menu item. From the documentation I feel I could make one appear programmatically, but I want to enable the menu button.
My first attempt at an OS X program hit a wall very fast :-/
First, control-Click on Open, and see if it is already attached to a function. If so, click the x to detach it, then try again.
Second, be very sure that the Assistant Editor is presenting the correct file to do the control-Drag. I have found that I need to manually choose the correct file much of the time.
Related
I recently updated to Xcode 11 and some of its user interface changed. in older version of Xcode there was options of accessing files in assistant editor using automatic or manual. but in this version of Xcode I can't see any manual option in assistant editor. so I am not able to add IBOutlet and IBAction methods to particular storyboard.
so can anyone tell me how to add these actions and outlets, that would be great help. thanks
By pressing the above button, Xcode will split the view and allow you to select a custom file using the file tree at the top.
You are correct.
The Manual option is no longer visible. You can still achieve the same result by doing a quick open using Cmd+Shift+O then type the name of any file you want to open. Press the Alt key and the file will open in the Assistant Editor Window.
As others have noted the new add editor button allows you to add new editors and open files into them. You could file a bug report but you may want to consider that you're likely to get a "works as designed" type of reply.
You can always change or add new keyboard shortcuts to get the behavior you want by viewing the preferences key bindings area and search for the command you want to shortcut.
Note
You can still ctrl+drag from storyboard to the class by the Adjust
Editor button in the upper right of the storyboard. Then just select
Assistant Editor on the list. After which you can make IBOutlets/IBActions.
open your storyboard, hold option key and select the file you want
In the documentation outline of storyboard, try to choose the "correct" item, which you want to set up outlet connections. Say you want to set up an outlet connection for cell of table/collection view.
View Controller > Collection View > Cell > Content View > Image View.
Try to select Cell, "Content View" or "Image View", then check the jump bar of assistant editor, you're probably able to switch to the .swift file you want.
Reference
So, after struggling with horrible interface choices of Xcode 4, I'm finally on 5.1.1.
The tabs became almost usable. Double clicking can be configured to open a file in a new tab. Good. Double clicking another file opens it in a new tab. Good. Double clicking first file again switches to previously open tab. Good! Double clicking first file while it is open in current tab opens a second tab with that file. Ok, I can live with that, since from there on they just switch from one to another.
So far a surprisingly sane behavior.
Unless you make a single click in the navigation panel by mistake. Single click opens whatever you click in the current tab, all logic and reason be damned.
The question is, how to change single click behavior to "Use separate tab" (or however Xcode refers to that behavior)?
Is there any way to disable single clicks from doing anything at all aside from highlighting the selection?
There's no option to disable the single-click behavior. Two options that get you close to your desired behavior are:
Use a single separate window for most of your tabs. Use a "main" window that has the file navigator visible, and a separate "work" window with the file navigator hidden. If you want to add a tab to the work window, create it in the main window and then drag it's tab over to the work window. This is an extra step, but you'll never have a single click change any of the tabs that you care about (thought it'll still change the primary or focussed editor in the main window, depending on your settings).
Use separate windows for each file. There's a preference setting that lets you create windows instead of tabs when you double-click a file in the file navigator. Use Mission Control instead of the tab bar to navigate between your files.
I have an app which is run from the menu bar only (LSUIElement is set in the info.plist) which means there is no main menu except the menu I attached to the status item. The problem is I would like to enable some edit commands when using an NSTextView (like command-c to copy) but all command keys seem to be disabled since the app is technically not active (I get beeps when trying any key combinations).
Is there anyway to add a standard edit menu somewhere and enable command keys that would redirect to it? I'm thinking there could be a hack to make the app temporarily active or something but I can't figure anything out.
Thanks.
They're not disabled. They're gone, because you deleted them.
You need to put back your Main Menu.
If you use version control, you may be able to resurrect it from the past using that. If not, you'll have to create a new project, copy anything custom from your Main Menu nib (if you even still have one) into that one, and move that nib into your actual project to be your new Main Menu nib.
The Edit menu commands, window-related commands (e.g., Close), and numerous other commands all live in the Main Menu. If you delete the Main Menu, you don't have those features anymore.
Your Main Menu isn't visible in a UI element app, but that's not a reason to delete it—it's a reason to keep it, even though your app won't have the menu bar, because not being visible means that it won't peek out from behind the curtain but will remain there keeping the magic of your keyboard shortcuts working.
Is there a quick way to jump to an action associated with a control.
Say there is a button on a XIB file that has an associated action. The way to find the code associated with this is rather tedious. Is there a short cut that can quickly jump to the code.
I am spoiled by Visual Studio - double click on a button and it takes you to it's handler
The fastest way I know to at least get quickly to the source file in which the action resides is the following:
select the button in the UI editor
hit ctrl+1 (this will open the “Related Files” drop down)
navigate to the “Sent Actions” sub-menu, e.g. via s, enter
select the relevant class (I think in this case there can only be one, so just hit enter again)
Once you are in the class, the action should be easy to find. If that's not the case, because your source file is so big, type ctrl+6 to open the “Document Items” drop down and start typing the name of the action. Once you see the action, select it via keyboard or mouse.
If you often don't know the name of the action, you will have to look it up before navigating to the class, e.g. by right clicking on the button.
I would advise to use ^+⎇+⌘+Enter to get to referenced code file. There you can search for #IBActions or #Outlets. If a UIButton has a segue attached, this method won't help to find it.
To review a list of actions, segues and outlets you can select an object on the storyboard and press ⎇+⌘+7 to open Connections Inspector on the right pane.
In Xcode 4 (4.2), is there a way to keep the Project Navigator view open and Debug Navigator view open as well. Must a user have one or the other, but not both? And the other navigators?
Apple seems to have decided that if you want to see the debug view, you don't want to see the files in your project. WTH? Am I getting this wrong? Did Apple Xcode UI guys even talk to developers before designing the UI for Xcode 4?
Sigh...
You can indeed have more navigators open at once, if you are prepared to have multiple windows open. I know it's not exactly what you're asking for, but for multiple display setups it's very handy. Xcode provides "behaviors" to help automate this process if you only want certain things showing at certain times.
For example, a common pattern that developers follow is to setup a behavior for "Run starts" that opens up a new window setup for debugging. Start by creating a new tab in your main Xcode window by pressing command-T, and double-click on the tab's title to rename is "Debug", or whatever you like. Then drag that window out (or leave it as a tab if you like), and customise the view as required - for example, for a deb window you might have the Debug area showing at the bottom (or even covering the whole editor view), and remove the toolbar at the top by right clicking and selecting "Hide Toolbar".
Next, go to "Xcode > Behaviors > Edit Behaviors..." and choose "Run starts" in the left panel. Check the box for "Show tab" and enter the name of your newly created tab. You can also ask that tab to automatically show the Debug Navigator, and show the debugger with variables and/or console view. If you like, you can then choose "Run completes" and show the original "tab" (window), which I've setup to be called "Coding", and show the required navigator (in my case, Project Navigator).
On successfully running, Xcode will now open up your new window (or bring it to the front if it's already open) with all the settings you left it with. On stopping, your main editor will be brought back to the front.
There are loads of useful behaviors, so I would really recommend looking through them and taking the time to setup Xcode to suit your style as best as possible. All software dictates to the user how to go about doing things, and the developers can never please everybody when they decide to change the UI. The best anybody can hope to achieve is to customise the interface as best as they can to fit their style of working. If it's still an issue for you, you can either adapt to it, or, if possible, move to something else.
I'm not a fan of every new interface feature in Xcode, but I've "made it mine" with some customisations and I can still be very productive. That being said there are a lot of things that I do really like about it, and for that I can forgive it for some of the less friendly features - after all, you can't please every user.