I have added some ToolBars(CToolBar [FIXEDBMP]) and a AnimateControl(CAnimateCtrl [FIXEDBMP,FIXEDSIZE]) to a ReBar (CReBar). No Specific positioning is done for any of the Tool Bars or Animate Controls. Now The Animate Control gets MISALIGNED(Goes in the Top Left over the Menu Bar) ONLY in the Release Build, whereas in the debug build it is in the desired position(Top Right along with other ToolBars). I am not sure if there are any Issues with Release DLL or am I missing some thing?
One of the following:
in Debug you have an ASSERT() that evaluates the result of a method call which modifies the state of the AnimateControl. On Release, that method call is not being evaluated.
You have code that executes only on Debug through #ifdef
A variable is either being explicitly initialized differently on Debug and Release, or you are using uninitialized variable in your code.
Without seeing the actual code it will be hard to tell more.
Related
I'm trying to lock an entry widget in tool mode like this:
tool
extends Node
export(bool) var locked=false
export(String) var entry="" setget set_entry
func set_entry(new_val):
if!(locked):
entry=new_val
In theory, this should prevent any changes made to the entry widget
as It would rapidly change back to the previous value hence giving the illusion of being disabled
but in reality, you can type freely and after you select another node and then reselect the original node then the value returns to what it was before locking
How do I disable it completely? (perhaps using _set()?)
Edit
This is the problem I'm facing
To disable it completely, I think you need an Inspector Plugin (I talked a little about creating one elsewhere). You could make one that handles the property you are interested in and displays its value, but does not allow to edit it, or only allows to edit it conditionally.
However, for a quick and dirty approach you can do is tell the inspector that the properties changed:
func set_entry(new_val):
if!(locked):
entry=new_val
property_list_changed_notify()
This will cause the inspector to re-read the values of the properties. It can be a bit annoying, depending on the case. By the way, it seems to be ignored in sub-resources, which I find frustrating.
By the way, Godot 4 has PROPERTY_USAGE_READ_ONLY.
Addendum: We can be a little more aggressive than property_list_changed_notify, by using EditorInterface.inspect_object (we can get an instance of EditorInterface from an instance of EditorPlugin). Godot would reload the inspector (which also results in losing the keyboard focus).
Currently when I run Full Cleanup on a file with NUnit tests R# totally ruins it. For some reason it reorders the methods with [Test] in alphabetical order. How can I turn this "feature" off?
I'm using version 9.2.
This is explained in the documentation here
you need to go to Code Editing | C# | File Layout page of ReSharper options and then remove the default NUnit layout pattern (or change it so that it doesn't reorder alphabetically)
The simplest way to do this via the ui (which seems to be very confusing) is to double click each Type Pattern and make sure you are in composition view (click the icon in the top right corner until its a cog) then double click the method Entry elements until you find the one which has the constraint for the attribute for NUnit framework (somethign like this):
and then change the Sort By option in the bottom right of the main settings window to be none
I'm programming a shader in DirectX (SharpDX). The thing is, I've noticed I need to clean and then build everytime I change something in the shader (.fx file). Is there any way to avoid having to do this? Before I made some changes, It looked like "Build" was enough to apply the changes... For instance. If I'm returning a red color for a line. I may change the color to green, the build and I'll still see it red. If I clean+build, I see the changes (lines in green).
I thought it may have to do with some buffer cleaning, but I'm not exactly sure.
Thanks a lot for any idea.
If I recall correctly, the shader compiler is coming along and compiling your shaders to .fxc bytecode. I believe Visual Studio doesn't keep track of changes to "external files" (i.e. not C#/C/C++/whatever code files), so when the program goes to run, it grabs the already compiled .fxc code, which has no new changes. Cleaning it removes those precompiled files, triggering a recompile. The easiest way to solve the problem is to add a custom build step in the Project Properties to run the DirectX shader compiler (fxc.exe) on your shader manually. You'll lose the nice property page stuff with it (assuming you were using them in the first place), but any time you compile your project, it'll recompile your shaders.
I'm using the Ribbon control located on CodePlex, and following the tutorial located here . Once I add the reference, and the proper code in the designer I get this error when I try to view the form:
Exception of type 'System.ComponentModel.Design.ExceptionCollection' was thrown
And I cant figure out what I'm doing wrong. Anyone worked with this control and know how to resolve this issue?
Interesting; I just ran into this same issue with one of my own forms; which is how I found your relevant and recent question.
Here's how I solved it:
Open two instances of Visual Studio. Open the same project in both.
In one instance, goto Debug->Exceptions and enable all the 'Thrown' options to stop at first chance exceptions. This will stop the debugger when the exception is generated.
In the same instance, select Debug->Attach to Process, select devenv.exe.
In the other instance, open the form to cause the exception
With any luck the first instance should stop somewhere that yields a more relevant exception.
In my case it turned out to be something that I should have conditioned with:
if (!DesignMode)
{
// Do something that should only happen at runtime
}
Don't forget turn turn off all those 'Thrown' options later.
A workaround for me was:
Right-click on the form and 'View Code'
Keep the code loaded in the editor and then attempt to view the designer again.
This feels very glitchy and I cannot confirm whether it's a problem with my code (as I'm working on an entirely new codebase) or whether it's a VS2012 bug. If I find out, I will report back.
Since the solution outlined by pilotcam didn't work for me, I took a different approach:
Make a SVN commit for the file.
Open the “*.designer.cs” file of the form that shows the error in source view.
Remove larger blocks of form element declarations.
Fix all compilation errors with ReSharper (i.e. ensure that nothing is red anymore on the side-indicator).
Save the file. No need to compile.
Open the Windows Forms Designer of the form.
If the error still shows up, do a SVN revert to go back to the initial state.
Repeat steps 2 to 7 until the error does not show up anymore.
Now you’ve encircled the erroneous child control that causes the error.
Repeat steps 2 to 7 with a smaller amount of controls you remove, until you have only one control left.
In my case it was a user control inside a group control inside a tab control, so I first identified the tab control, then the group control and then the user control.
You could isolate the user control inside a new form to further investigate. In my case it was rather easy; I put checks for design mode around most of the functions inside my control to ensure the code only gets executed if the control is not in design mode.
This fixed my error.
I had the same issue and none of the above answers solved the problem.
At the end, emptying the "bin" folder and rebuild has worked for me.
Let me add two more cases when such exception can happen, along with when control tries to do something that is not allowed under design mode:
When it's impossible to compile the user control.
When designer code contains multiple similar (or identical) lines with initialization of same controls or properties, this can easily happen on merge.
All that cases produce same extremely meaningful error message, and in this particular two debugging of Visual Studio won't help, so I just ended up with bisecting my designer code.
[ReadOnly(true)]
[Browsable(false)]
Above all properties worked for me
Has anyone used JustCode from Telerik lately? This question has been asked about two years ago, but I'm sure the issues must have been resolved by now. Especially referring to running it side by side with ReSharper.
I have been using Resharper for a while now. I decided to try JustCode to see how it behave.
After a week of using JustCode, I am uninstalling it and returning to Resharper.
What I like about JustCode:
A single window indicating all warnings/errors in entire solution.
Performance seemed to be a bit better than Resharper.
Refactoring is easier to get to.
Projects can be excluded, or type of file
Language can be excluded (such as XAML)
What I did not like about JustCode:
Sometimes the underline used to open the option for fixing or refactoring is frustratingly hard to click since VS also puts an underline at the same spot (and it is the context menu of the latter that pops up).
Cannot change an hint to be a warning instead.
Saw some minor bugs
JustCode was giving hundreds of false positive warnings in the XAML code (luckily I could turn the inspection of XAML off)
What I was missing from Resharper:
Warnings about method parameter missing/mismatch from the documentation
Hints to transform an expression into a Linq expression.
When writing an opening bracket, resharper automatically adds the closing one and puts you on an empty line in between the two.
When completing a method, Resharper adds the first parentheses. It also adds the last one if that method is parameterless.
I am sure there is a bunch of other stuff that I can't remember now
You can install both Resharper and JustCode alongside. I first suspended Resharper before installing JustCode and used JustCode fine. When I resumed Resharper and restarted VS, both were running together without error.
Together, Resharper was finding more than JustCode.
For example, JustCode did not give a warning for the following: "Value assigned is not used in any execution path."
It even missed an error: "Cannot convert type 'int' to 'bool'." The expression was:
if ((bool)CanDoIt) // Here CanDoIt is a property of type int.
{
...
}
All in all, the tool is not bad. I recommend it over not having any. But if you have the choice between Resharper and JustCode, go with Resharper... for the moment; JustCode is still young.
You can change the size of JustCode's smart tag or turn off Visual Studio's smart tag in JustCode's options menu. I prefer to access VS's smart tag by using ctrl+., so it hasn't been an issue for me.