The new version of VSCode 1.75 contains the new function Profiles, which I was waiting for.
It looks like you can install, activate or deactivate extensions in each profile, without affecting the other profiles.
So far I only managed to install, activate or deactivate extensions via the extension manager, or via the view page of the respective extension.
There is this new view that can be displayed via [Settings-Wheel]-[profiles]-[show contents]
There you can find a checkbox for each extension.
Intuitively, one would assume that the extensions for a profile can be either completely switched on or off (install) or at least activated / deactivated.
For me this checkbox has none of the mentioned effects.
The profiles work nevertheless, as said, with an activated profile extensions can be installed and uninstalled, the profiles can then be switched, and a profiles extension states get properly restored when reselected.
However, the view with these checkboxes seems largely pointless to me at the moment.
So my question is: what is their purpose?
Should their purpose be what I suspected, and the feature just isn't "ready" yet?
The checkboxes are for exporting the profile without including undesired configuration options. For example, the "UI State" option will save the currently open menus and submenus as a part of the profile's configuration, which you likely don't really want in most cases.
Notably, when I created a new blank profile and accessed this menu the only field present was the UI State, which implies that if a field is the same as the default configuration it won't be saved to the file.
When you export, you can name the profile and either save it locally as a ".code-profile" file, or upload it directly to GitHub as a gist. The file uses a syntax that I believe is unique, though it's very possible I just don't know it. It would be nice to have a simple JSON schema, but I'm sure the community is going to automate the hell out of this process within a few weeks/days.
I'm pretty sure the purpose of those checkboxes is to select whether or not each extension gets exported as part of the profile. Presumably they are all activated upon importing the profile and installing those profile extensions.
Related
I can get#recommended:workspace extensions to work correctly but I am unsure as to why I cannot get the general #recommended to show anything. Where am I supposed to put the extensions.json file?
My goal here is to have PowerShell install VSCode, copy over some JSON files for specific settings and then have the user shown the companies recommended extensions to install once they open up VSCode.
I know I can force them installed with code --install-extensions but I want the user to be able to pick and choose from the companies recommended list based on what kind of files they'll be working on. What I can't seem to figure out is how to get that list to show except within a workspace.
For example, we have a Chef team, an Azure team, Linux team, etc. each needing different extensions.
The #recommended option has no config. VS Code decides which extension to recommend based on the file types that exists in the folder/workspace that you opened (official release info).
So, in your scenario, I guess the best option is to use Workspace Recommendations (#recommended:workspace), using a different recommendation for each team/project.
Confluence version: 5.5.2.
I need to know how I can see the actual source code of a macro in Confluence. I tried adding macros, then right-clicking the page to view the source code, but that doesn't really help.
What I am trying to do:
With the existing macro, task list (the checkboxs), I need to modify the code in a way such that changing the value from true to false (pretty sure it is the onClick() function) or vice versa will send an e-mail to all "Watchers" of that page.
Would this even be possible? The changes I make need to be recognized on the server so that the changes don't only take place on my computer. Also, I don't even know if I can view the actual source without downloading an external plug-in (which won't work for certain reasons). Has anyone done something like this?
The source code for Confluence macros can be found either in the User Macro section of the Administration panel for inhouse macros or in the plugin code. The first port of call is bitbucket.org for Atlassian plugin code.
To view the code for Atlassian plugins you will need to access the source from Atlassian. E.g. Tasklist Plugin in BitBucket.
You can also download the jar installer for this plugin from the Atlassian Marketplace Dynamic Tasklist 2 page, change the extension from .jar to .zip and then unzip the plugin to view the plugin contents.
Found a work around. If you go into settings (under profile pic), then go to e-mail and select all the checkboxes provided, it will solve my problem. Any small cahnge made in the document will be e-mailed to all watchers.
I know netbeans syncs the original files once I save, but if there is a file changed externally is there a way for netbeans to recognize this and either tell me to re-sync it or automatically resync it with the new changes?
Here's what makes this behavior possible:
NetBeans 6.9 contains a feature that automatically looks for external changes to keep informations about files up-to-date. We have some reports that it can slow down NetBeans mainly, when an open project has many folders. When NetBeans find out that files were externally changed, it re-scans the files to keep data up-to-date that are used with features like code completion, navigation etc. Unfortunately the notification and following re-scanning can take some time and during this time many mentioned features are waiting for the finishing of scanning. There is option Enable auto-scanning of sources that can switch off this behavior. The option you can find it in Options dialog, Miscellaneous category and Files tab.
The default behavior is that NetBeans also looks for external changes when the main window gets focus. This is can be during developing a web application very often when user switches between browser and IDE. The mentioned option also switch this off.
When you switch off option Enable auto-scanning of sources you can still keep the information up-to-date, just invoke Scan for External Changes action from Sources menu manually.
(Here's the original article by Petr Pisl)
I find it counterproductive to leave this setting on, as sometimes auto-loading external changes to a file opened in the UI without asking for permission first can ruin your day when you're forced to make small local changes that you don't want replicated in your repository. I'm sure other people can think of more reasons to advocate for "warn before loading external changes" behavior to be implemented in NB. That is one of the reasons why I like Eclipse better sometimes.
I want to give the users an option to leave their data when the app uninstalls, is there a way to do this?
Both yes and no.
No UI is shown during uninstall, that's why you cannot give users this option.
Yet you can remove these files as described in the answers to the question linked by Morten.
Additionally you can use RemoveFolderEx element from Util extension. This element correctly handles removal of subdirectory structure.
As for UI part, some programs do not display several buttons, like Uninstall, Change, Repair, on the Control Panel rather have one button Uninstall/Change. In the latter case, there's usually UI shown when they are uninstalled.
I'm trying to integrate our Source Control(SourceAnywhere) with VS and are getting a lot of push back because of this one issue.
Almost every time we open some of our Windows forms using 'View Designer' it edits the file (* appears beside file name). Nothing has yet been changed, I've tried comparing the before and after files and they are exactly the same. If we have the solution bound it will check the file out, but even if its not bound it still 'edits' the file. When you try to check the file back in, it doesn't get a new version or anything.
I've done some searching and haven't been able to find any way to change this behavior.
This is a huge pain point for me as if someone already has the form checked out and someone else tries to open it, they just get told that it can't be checked out, and the form won't open. Or, someone who has no intention to edit the form, will now have the form checked out but hasn't made any changes.
Thoughts?
This usually happens when there are controls within the form that have "Dock" set. If the IDE feels it needs to resize the form, then those controls will also be resized, and all of that information needs to get re-written to the source file. In the case where you're editing a form named "Form1" this source file is not Form1.cs, but rather Form1.Designer.cs - try comparing that file with the version from source control.
Alternatively, move to a source control system that doesn't use locking by default (for example, Subversion) or disable that feature in SourceAnywhere. This will require users to manage merge conflicts, but allows multiple users to work on a single file at the same time.