I had options in a VCL program to specify a number of specific styles at run time but have since changed this to take the styles defined in the manifest file and automatically create a menu of available styles. Unfortunately the menu items do not get updated. I am using exactly the same code as in several other programs which work well so am wondering where the information gets stored per program so that I can delete the file and ensure a clean start.
I use Delphi 11.1, have the "Enable runtime themes" box checked, DPI awareness is set to Per Monitor v2 and have defined several themes in the project options Appearance panel. These latter get ignored.
Any suggestions for things to look for would be much appreciated.
Thanks
Bruce
Related
When an app stops in debugging mode and I make changes to the code
Is there a way to save the code with the changes, without stop the app?
Although the VB6 IDE does not provide this natively, an add-in for the IDE called MZTools has been around for ages which adds this feature.
Personally I've used MZTools 3.0 for many years, and this works really well.
This is what its help system says:
Shortcut To Save File At Debug-Time
The Shortcut To Save File At Debug-Time feature allows you to define a keyboard shortcut (Options
window, Shortcuts tab) to save the selected file at debug-time. The
Visual Basic IDE does not allow to save files at debug-time, but often
it is useful to save the modifications that you have made to the
source code at debug-time.
Remarks:
This feature is not available in the VBA version of MZ-Tools. This
feature only works at debug-time. Since Visual Basic disables buttons
or menus of add-ins at debug-time, the only way to save a file at
those times is through a keyboard shortcut. The file must be
previously saved at design-time, that is, MZ-Tools does not prompt for
a name to save the file (it shows an error message instead).
This is the options window for how I have it configured locally:
Note that originally MZTools was free in version 3 and later they switched to a paid version; if I hadn't gotten v3 originally however it would be well worth paying for, not only for this feature.
The short answer is you can't.
If you make the project before the crash, maybe this piece of code can be found in a ".tmp" file. But searching in .tmps is often a waste of time.
I particularly always force myself to stop the debug and save my progress.
And I always use this setting which forces me to remember to save:
Due to the nature of the way we work, we often find ourselves with 2 or more versions of the same project open at one time in different Visual Studio sessions. Unfortunately, these are just stacked on the task bar so without going to a source code file and inspecting the path, we can't readily tell them apart.
Is there a way to apply some ad hoc styling to the IDE to be able to tell them apart more readily? Something like theme would be ideal but at a session level.
N.B. this isn't something we'd want to check into source control so we want to avoid having say, marker files in the solution.
SolutionColor extension allows to set the color of the title bar on a per solution basis.
For several reasons we prefer Nullable<Int32> over int?. Wherever possible we prefer Types over keywords - as we do so since C#2 we have a large codebase already using that style.
I recently switched to VS2015 and got the annoying light bulbs all over my code. For Int32 and other related non-generic types I fixed that by using this answer. For Nullable<T> however I cannot find the option to disable nagging.
How do I disable the IDE0001 Name can be simplified. for Nullable<T>?
In your project properties, under the Build tab, in "Errors and warnings", add IDE0001 to the set of suppressed warnings. I know this isn't really a warning (just a suggestion) but it's the same infrastructure. That removes the suggestion.
There is a feature-request here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9139204-option-to-disable-quick-action-squiggles
concerning disabling the light-bulb. Please add your votes to this if you agree that it is important.
The answer was finally given for another related question:
You can disable analyzers on a per-project basis.
To do it, right click on Project>References>Analyzers in the Solution Explorer and hit Open Active Rule Set
Here you'd need to disable IDE0001 Simplify Names under Microsoft.CodeAnalysis.CSharp.Features.
Additionally you can set Tools > Options > Text Editor > C# > Code Style > predefined type preferences for For locals, parameters and members and For member access expressions to Prefer framework type and Refactoring Only (default). This however is a machine specific config setting.
I want to achieve that when the user installs the WP7 control library he will find it in the Visual Studio toolbox automatically without manually adding it. In addition I would like to organize toolbox tabs in a logical manner.
I know it can be done for other platforms. For example I tried writing *.design.dll as described here - it does not work for WP7.
Any pointers how to work with toolbox for VS 2010 / WP7?
Nobody answered, so here is my brief summary:
The control library cannot be added to the Toolbox automatically unless you program VS plugin (package). Too much work for me...
*.design.dll (see the link above) basically works.
2a) You can hide controls from the Toolbox (BrowsableAttribute) and you can define control icons. That's probably everything you can do for Toolbox. The user has to add Toolbox tabs and "choose items" manually.
Well, I am not quite sure here, because when you drop the control dll file onto the Toolbox, then at least ToolboxTabNameAttribute works, i.e. corresponding Toolbox tabs are created automatically. Unfortunately, the tab is empty.
Also, when the control library is properly installed, then some of the controls are added to Choose items Toolbox dialog. Unfortunately, in my case most of the controls are missing and have to be added by manual browsing.
2b) Designer support (Properties window for the control) is better. You can hide properties (BrowsableAttribute), define categories (CategoryAttribute) and define descriptions (DescriptionAttribute).
Descriptions can be extracted from you documentation xml file, so that you don't need to write them again. To get the code google for MetadataBase.cs. Just be carefull, the files you'll find contain fatal bugs (ParseDescription method) and ignore some properties (getters that return a collection).
After all, the result is not that bad.
I created a Visual Studio Add-in that adds additional commands (four of them) to the top of Code Window context menu. I'm using permanent UI approach. Depending on the cursor position within code only one of the commands would be visible and thus selectable. Other three would be hidden.
I set supported and enabled status within QueryStatus method that does the trick for the correct command and unsupported and invisible for the rest.
The problem
The first time add-in is installed all works well. I can only see a single command in the context menu. The rest are always hidden.
The second time I load VS IDE I detect the same commands and controls (so I don't recreate something that's already there), but now all of the commands (or better
CommandBarControl/CommandBarButton controls) are visible. Instead of hiding 3 and showing only one I can see all four of them. The correct one is enabled and the rest of the pack is disabled/grayed out.
The question
How do I hide existing commands (or CommandBarButton controls) on the next IDE load? I tried setting button's Visible property to false but then even the correct control isn't displayed.
Have you tried having a single command, and changing the text of command depending on the cursor position? I'm not sure if this is possible, just a suggestion.
Solution I used at the end was:
Delete controls at IDE startup (or Add-in after startup if not enabled at IDE startup by default). Deleting commands also removes any controls
Recreate commands and controls and their visibility will work as expected.