When editing a declaration I type in my changes and click on the background and it immediately reverts my text.
I have no syntactic issues, I can delete the declaration and write a new one and it accepts it just hunky dory, any ideas what's causing this frustrating behaviour?
The best (unsatisfactory) answer I have come up with is that the java host running CPN TOOLS has had an error and shut down and CPN Tools is now acting erratically.
When you restart the system the editing capability is restored.
Related
Since a week back I'm seeing a very annoying behavior from VS2010:
As I'm debugging a project and the debugger stops on a breakpoint Windows freezes for almost ten seconds. I say "Windows freezes" because the mouse and keyboard are useless during this time period.
The problem only happens as I debug a specific project and I've tried it on two diffrent machines with the same result. The project is WPF and I do hook the keyboard at one point (not the mouse though) but that code hasn't been touched for months while the problem is just a week old.
I did install Telerik's big suite of everything (trial) just before this started to show so my first suspicion was Telerik's VS integration was the culprit. I uninstalled all Telerik VS integrations (the "JustXXX" products) but the problem remain.
I would be very greatful to anyone being abe to give a hint as to what might be going on here.
Thanks
EDIT 1:
I have now tried building a new solution, moving all projects into it but the problem remains.
I then uninstalled everything Telerik, just to make sure, but this also was to no effect.
The next test was to load the exact same solution on a different machine and that did help. That machine has no 3rd party integrations with VS2010 except for reSHarper 6.1.
I have also analyzed the issue bit more and the typical scenario is that the first few times a breakpoint is hit the UI freezes for apeoximately ten seconds. Mouse/keyboard stops responding but the cursor keeps blinking in the code editor. The next few breakpoints does the same and often stepping from one line to another will cause a very long delay (no UI freeze though).
Also, if the first breakpoint is set very early in my application startup code I might not experience the problem. But as I continue to step through the code the debugger becomes more sluggish as the application initializes itself (in separate threads).
As I've said before this happens for a single application so the code is clearly related somehow.
Does anyone have good knowledge of how the debugger operates? Apart from the obvious steps needed whenever a breakpoint is set or the user steps from one line to another (refresh stack trace and watch windows) what is going on in the background that might freeze up everything and how is it possible?
My last hope is a complete reinstall of VS2010 but I hope I can solve this before that option is required.
I have finally found the cause for this weird behavior. As I mentioned in the original post I do hook the keyboard (AND mouse, I had forgotten I did that) during the application's initialization in order to be able to detect user inactivity.
The monitoring takes place in a background thread that simply waits for an AutoResetEvent to discover user activity or inactivity. For some odd reason the AutoResetEvent.WaitOne(...) somehow affects the debugger. My current fix is to just avoid the wait if the debugger is attached.
I still cannot explain why this happens now. It has been working for a year but the cause for the problem is finally found and dealt with.
I have submitted my question to Microsoft, hoping to get a good explanation. If I do I will post it here.
If you really have the problem with one Project / Solution you could try to create a new empty solution and add the project there, maybe this helps.
I don't really know much about the inner workings of Visual Studio (after all it must be one of the most complex pieces of software out there). But what I've learned is, that a reinstall often is the best and fastest solution (even if it takes an hour or two). Just make sure you backup any settings you don't want to lose.
Update:
I found this one here, maybe you've already found it too: http://connect.microsoft.com/VisualStudio/feedback/details/260864/visual-studio-debugger-occasionally-locks-up-the-entire-windows-gui
You could give it a try and disable the language bar.
I'm having issues with Silverlight 4 Out-Of-Browser, as specified in the title.
What I did:
Update project settings to enable Out-Of-Browser. This enabled OOB, but when I ran the app in this way it just displayed a white screen.
What I have done to try to fix this:
All references to the System.Windows.Browser.HtmlPage (to avoid DOM interaction) have been removed as per various sources including this SO question and this blog post.
Remove any references to SizeChangedEventHandler as per this SO question.
Clean projects/solution, including ideas such as deleting *.suo files as per this blog post
Uninstalling the installed OOB app, reinstalling
Also:
As commented on by "kobruleht" here, attempting to attach the debugger does not appear to work. Visual Studio (2010, SP1) reports that it is attached without help from me, but breakpoints are not being hit.
And so:
Can anyone advise on other courses of action? At the very least I'd like to be able to step through and hit breakpoints (or even break on Exceptions!)
OK, I have a resolution.
In AppManifest.xml I specified assemblies to be loaded, one of these was not loading correctly, which meant that App.xaml.cs->App()was never reached. The problem is difficult to diagnose because the program runs, with no errors or exceptions, but then displays a white screen - quite misleading.
For anyone experiencing the same problem, the simplest debugging steps to take in this case is to run the app in in-browser mode, copy the results from the Output window, then compare the results from the Output window when you try to run in OOB mode. Any discrepancies will give a good hint to the problem.
I should also mention, that I have not had trouble with SizeChangedEventHandler as mentioned above.
Not sure what is going on here, if it's just my computer, or a VS bug. It is annoying.
When scrolling, text in VS sometimes gets really messed up. it also happens to other window elements on occasion.
I've noticed something similar in Dreamweaver CS4 & CS5, so I don't know if it's my computer or something with WPF.
Any way to fix this problem?
Windows 7 Pro
This is most likely a general WPF issue, and could be related to your graphics drivers.
I would recommend looking for updated graphics drivers for your graphics card. If this doesn't work, try reducing the amount of hardware acceleration, as this tends to clean up many WPF rendering issues.
I would suspect this is a WPF issue that may be resolved by updating your graphics drivers if your card can handle it as Reed Copsey suggested.
If you don't have any luck with that, you can try turning off some of the hardware-accelerated rendering by going to the Tools menu, selecting Options then disabling the Automatically adjust visual experience based on client performance option and the following two options under the Environment > General section.
MSDN put up an article not too long ago that can help troubleshoot the problem.
http://msdn.microsoft.com/en-us/vstudio/ff716700
The first two things I would try would be to update your video drivers. Then maybe turn down hardware acceleration.
This KB article touches upon how to do it about half way down the resolution section.
http://support.microsoft.com/kb/263039
I have similar problems with my VS2010. It isn't a graphic driver issue but an issue with WPF/VS2010. I was hoping the SP1 would solve this problem, but it didn't.
I am working on my first DotNetNuke website and there is a requirement for all the custom module functionality I am developing to be available with JavaScript disabled.
However, when I create a module that contains a simple submit button, i.e.<input type="submit" />, DotNetNuke displays a critical error with JavaScript turned off but works as expected with JavaScript turned on.
When I attach to the running process using Visual Studio, the unhandled exception is thrown from admin/Skins/Nav.ascx.vb line 177. The inner exception message is "Invalid JSON primitive: ."
My research online only managed to turn up this forum post (Postbacks are not working when Javascript is disabled in the browser) that appears to be the same problem as mine, but no solution is provided.
Can anyone shed any light on this issue? Is it viable to be attempting to write non-JavaScript functionality in this version of DotNetNuke?
Update: it turns out that another website designed recently with Dot Net Nuke by the company I am working for is having the same problem with non-javascript postbacks when using DNN version 5.1.4 but it does not have the problem (i.e. it can postback without javascript) in DNN version 5.0.1.
So perhaps a hard dependency on javascript has been introduced at some point after version 5.0.1. We are investigating this possibility further and I will keep this question updated as we go. Obviously I still welcome anyone's input on the subject.
Update: i've started a thread on the Dot Net Nuke forums to see if I can get any help there. If any solutions come up I'll post them here. Trying to find official DNN stance on support for javascript disabled functionality
One of the developers in the office found a workaround to get postbacks working with javascript disabled. Unfortunately since he does not have a Stack Overflow account, I will try to translate his solution as best I can for those who are interested. Bottom line is postbacks with Javascript disabled is possible once you make a few changes to the Dot Net Nuke environment.
Step 1 - Change the menu module. In our case we used the Telerik RadMenu.
<dnn:NAV runat="server" id="dnnNAV" ProviderName="DNNMenuNavigationProvider" IndicateChildren="false" ControlOrientation="Horizontal" CSSControl="mainMenu" />
becomes
<dnn:RADMENU runat="server" id="dnnRADMENU" MaxLevel="2" EnablePageIcons="False" PagesToExclude="" ShowPath="True" />
Step 2 - Remove the actions and visibility modules.
<dnn:ACTIONS runat="server" id="dnnACTIONS" ProviderName="DNNMenuNavigationProvider" ExpandDepth="1" PopulateNodesFromClient="True" />
<dnn:VISIBILITY runat="server" id="dnnVISIBILITY" minicon="images/DNN-minus.gif" maxicon="images/DNN-plus.gif" />
Step 3 - Download the DNN source and make two changes in the LibraryUI\Utilities\ClientAPI.vb file.
Line 155:
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
becomes
If Not objButton.Page.IsPostBack Then
DotNetNuke.UI.Utilities.ClientAPI.RegisterClientReference(objButton.Page, DotNetNuke.UI.Utilities.ClientAPI.ClientNamespaceReferences.dnn_dom)
End If
Line 355:
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
becomes
If Not objPage.IsPostBack Then
ClientAPI.GetCallbackEventReference(objPage, "", "", "", "")
End If
Step 4 - compile the Dot Net Nuke library.
Note: Also make sure you are not logged in as an admin or host, as the admin/host panel at the top of the page will also break if you attempt to postback with javascript disabled.
Hope this helps someone else. If you feel like I'm missing some important details, let me know and I'll try and fill in what's needed.
DotNetNuke relies heavily on JavaScript and I doubt there is a real easy way around it - at least considering you need to support all functionality. Perhaps you can clarify that?
The the bottom line here is that you're going to need to modify DotNetNuke to meet your needs. It certainly isn't impossible to get it working, but I would venture a guess that it just plain isn't worth it for most people.
If, as you said, you need to retain ALL functionality without using JavaScript, you're going to have a pretty substantial amount of work to do.
I'd suggest, to get started, you download the source package, set up a development environment on your local machine, turn off JavaScript in your browser and start taking notes. This will help to determine the level of effort involved.
I'm guessing you won't get a lot of responses out of this one (as the poster in the forum thread you linked to didn't) as very few people have sat down in front of DotNetNuke with this as a requirement.
Also, keep in mind that any time you're making substantial changes to the DotNetNuke framework, you're interfering with your ability to easily perform upgrades in the future. Just another thing to think about.
I believe that I've seen the leadership in DNN say that they've taken a hard dependency on JavaScript, and have no intention at this time of considering a non-JavaScript compatible scenario.
That being said, being able to do a simple postback shouldn't be too difficult to support. I would look around in the Client API area for the error that you're describing. A lot of the Client API code is in the DotNetNuke.WebUtility assembly, which is a separate download from CodePlex to get the source.
I ran into a strange issue where "fn_key -- F4" combination on my hp laptop to extend the screen would stop working once I have a wpf application running. This happens even when I create an empty app -- as soon as I run it, I can't extend my desktop to a second monitor.
Thanks!
Sounds like an issue with your video driver. What kind of video card is it? Are you running the latest drivers from the vendor?
The problem was a driver issue (as Drew mentioned above).
To diagnose an issue like this, please follow the instructions from the MSDN article (http://msdn.microsoft.com/en-us/library/aa970912.aspx) on how to disable hardware acceleration and render everything in software.
Provided your issue is similar to what I have experienced, you will be able to single out the problem by adding the necessary registry key from the article.