XAML designer in VS2012/Blend not redrawing properly - xaml

I have a dev box with Windows 8 + VS2012 Update 2 on top. Ever since I had this system, the XAML designer has been behaving weird (for Win8 and WPF as well): it redraws only every second time.
Meaning that if I place a control, it does not update (the control cannot be seen, but its outline can be, if I hover over it); but if I place another control, or change the zoom level, or do any other action, then it refreshes. When I do a third action, no update; when I do a fourth action, it redraws. And so on, it is 100% repro-able.
Pretty bad for productivity.
I have the latest drivers and updates, I have loads of RAM (16GB) and a discrete Nvidia video card, I restarted umpteen times, the usual fixes do nothing.
A screenshot: http://sdrv.ms/13BJSof
Anyone with similar experience?

OK, I found a solution - my laptop uses nVidia Optimus (it's a Lenovo W520) and that was the source of this error (amongst others, such as being unable to properly "duplicate" my display to a projector). I solved it by simply turning off Optimus in the BIOS and enabling only the Discrete card.

Related

Camera in Roblox Studio (testing and building) is not working correctly

There are actually two camera problems.
The first is that sometimes the RMB to control the camera angle in Studio doesn't work. Sometimes using the LMB or movement keys helps, other times (like right now) it doesn't do anything. The hand cursor appears to shake in the direction I want to pan the camera but nothing happens. I did have an Advanced Camera plugin.
When I'm testing my game in Studio, I have NO camera control via RMB and zooming is nonfunctional. This is to say that I can turn using my mouse, but RMB doesn't change how mouseview works. Probably unrelated, but I cannot get scripts from the toolbox for run, crouch, zoom, etc. to work, either, even when I place them where instructed.
I get these errors in my game:
 16:36:47.313 ▼ ActivateCameraController did not select a module. (x3) - Client - CameraModule:362
     16:36:47.314    ActivateCameraController did not select a module.
     16:36:47.314    ActivateCameraController did not select a module.
I've been having trouble with Studio eating up too much bandwidth when NOT in use during actual gameplay in Roblox (exe), so I removed all the Studio plugins, thinking one of them might be the culprit (deliberate or accidental), and also hoping it might fix the camera issues. No such luck.
Probably unrelated, but I found a couple of apparently simple viruses (Vaccine and Fire) using clone() and spread() to reproduce within the confines that their simple scripts dictated. I removed all instances, as well as a presumably fake Antivirus. The first two were very basic scripts designed to spread the script and didn't do any damage (although the latter would damage players).
#Kylaaa came up with the answers, but there's no way for me to mark them as answers.
The problems did not occur in a new game until I copied all the stuff I'd added into it (from the troubled game).
Regarding RMB not working in the Studio:
Sometimes, if the Workspace Camera gets set to Scriptable, all mouse inputs stop working. You could try checking if switching the CameraType to Fixed or anything else fixes your problem. It should be in the Properties window when you select the Camera in the Workspace.
What I did: I changed the mode and the problem stopped. I suspect that the Advanced Camera plug-in that I had removed had something to do with the problem.
Regarding the camera not zooming and RMB not working during testing:
you have a malicious script somewhere in your Workspace. You can search/filter the workspace for Script and it will show all of the objects with scripts in them. I would recommend removing or Disabling the each of the scripts until you find which one is causing the errors
When you click on a Script in the Explorer, look in the Properties widget. There should be a checkbox titled Disabled. When you select that, it will prevent the script from running when the game starts
What I did: I deleted a bunch of stuff my son had added, and then disabled ALL scripts, then started enabling them one unique instance at a time (i.e. duplicates were enabled simultaneously). The camera problem didn't come back except when I edited a script during testing. I never located the problem script, despite going through and triggering all scripts.

Why do a .net form and controls not size properly on a given user's machine?

We received a large net desktop application from another agency to implement at our agency. It's messy, but works. It uses a midi form with forms opening inside that, and panels. We compiled and deployed in Visual Studio 2015. It's VB.
All users have Windows 7 64 Pro. For one user, when forms open, the lower portion is cut off. If restored (un maximized), the form shrinks to a tiny window in the upper left of the midi window. If borders are dragged the form will expand, but only a small portion of the form at the upper left will contain anything, as if inside a shrunken panel with scroll bars.
I changed the application so forms have a minimum size that should prevent them from shrinking down, but that doesn't work on her machine. I also changed a couple of panels to "fill" similar to adjacent panels. On other machines the application works excellent, even if display is changed to larger 150%. On the problem machine, the application only works if the display is set to smaller 100% and will not work on medium or larger. The user chooses to have larger.
I can place code on resize events and try to force everything to display correctly, but should not have to do that. The application works correctly everywhere else. Something is different about the problem machine where window metrics are not being computed properly or something similar. All machines are made from the same image and have the same drivers. I cannot see any additional software installed.
I would like to know if anyone else has seen this issue and how it was resolved.

Windows-8 & Internet Explorer-10 broke my ActiveX control drawing?

I am experiencing a very weird behavior while running my Active-X control on “Windows 8” OS, and browser “Microsoft Internet-Explorer 10”.
The control:
My Active-X control is very stable product that my company is already distributing for several years between hundreds of happy customers. The control is an ATL custom-draw control, written in C++, and built with “Visual Studio 2008”.
The problem – the drawing disappears:
While I press the link that opens my control for the first time, I can see that my control is being painted gradually (as my data loading is sometimes slow), but eventually all the drawing disappears, leaving a blank white background color where the controls is located.
Using ‘Spy++’ I can see that my control is really there, but all its painting disappear.
If I move the browser or change its size the control will be re-painted, but otherwise it is simply not visible.
I tried to debug this problem and find out who is erasing my drawing.
I came up with the following technique:
Using WinDBG I added breakpoints at ‘user32.dll’ DLL on the following methods: user32!InvalidateRect, user32!InvalidateRgn, user32!FillRect,
I defined these methods to only show stack and continue with to run,
I ran the above problematic scenario,
When the problem happens I am trying to view who called ‘Invalidate’ or ‘FillRect’,
Since all this happens very quickly I am using the ‘Print Screen’ button to freeze the moment
After doing this several times I find that exactly at the time my control disappears the following stack calls ‘user32!FillRect’:
user32!FillRect
MSHTML!memcpy+0x9805
MSHTML!COmWindowProxy::SwitchMarkup+0x468
MSHTML!CMarkup::SetInteractiveInternal+0x428
MSHTML!CMarkup::RequestReadystateInteractive+0x98
MSHTML!CMarkup::BlockScriptExecutionHelper+0xde
MSHTML!CHtmPost::Exec+0x794
MSHTML!CHtmPost::Run+0x1c
MSHTML!PostManExecute+0x5f
MSHTML!PostManResume+0x7b
MSHTML!CHtmPost::OnDwnChanCallback+0x3a
MSHTML!CDwnChan::OnMethodCall+0x19
MSHTML!GlobalWndOnMethodCall+0x169
MSHTML!GlobalWndProc+0xd7
user32!InternalCallWinProc+0x23
user32!UserCallWinProcCheckWow+0x100
user32!DispatchMessageWorker+0x3ef
user32!DispatchMessageW+0x10
IEFRAME!CTabWindow::_TabWindowThreadProc+0x981
IEFRAME!LCIETab_ThreadProc+0x378
iertutil!CIsoWinMsg::PostQueuedMessagesToComponent+0x4b
IEShims!NS_CreateThread::DesktopIE_ThreadProc+0x66
KERNEL32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x72
ntdll!_RtlUserThreadStart+0x1b
This is consistent.
When examining this stack I found that this message belongs to a window of class Internet Explorer_Hidden, which is window of size zero (0x0), but with a WS_VISIBLE style. This window belongs to the browser.
Does anyone know this phenomenon?
Is it possible that the browser hidden window is causing this problem?
Could you recommend on other approach to try and hunt the stack that is erasing my drawing?
Many thanks for any hint!
Paz Offer
Conclusion:
The bug was in Microsoft Internet Explorer 10
I used Microsoft Support service to farther investigate this problem. Enclosed here are the findings:
Microsoft Support viewed the version of my IE (Internet Explorer) and suggested to first upgrade IE to its latest patch.
As it happens, the machine I was working on was not setup to be automatically updated by the Windows Update service for some time. As part of upgrading IE I had to first update windows using Windows Update service to its latest patches.
During the process of Windows Update the Microsoft Internet Explorer 10 was automatically updated to its latest patch.
Once IE updated the problem disappeared.
In addition, the ActiveX GUI load process became much faster.
The old version of Microsoft Internet Explorer 10, which caused the problem:
Version: 10.0.9200.16384
Update Versions: RTM (KB2718695)
The new version of Microsoft Internet Explorer 10, which solved the problem:
Version: 10.0.9200.16635
Update Versions: 10.0.7 (KB2846071)
Now all is working as expected.
Thanks, Pazo

Washed Out Controls with VB.NET

I recently upgraded my system to Windows 7 Professional. Furthermore, I recently upgraded from VB6 to VB.NET and I've been working with forms and control under the new interface. Controls such as text boxes and tab controls are washed out and very difficult to see.
In my attempt to remedy the situation, I personalized my display by unchecking the box under "Windows Color" entitled "Enable transparency" and adjusting the Color Intensity slider all the way to the right. But no matter what I try to do, I still get washed-out form colors.
Is there a setting for adjusting the default form colors? What am I missing?
It seems to me that you have a couple of choices, all of which you probably won't like.
Change your Textbox BorderStyle from Fixed3D to FixedSingle, this will give you a more pronounced border around the textboxes (no such property on comboboxes though). This will also make your textboxes look a lot more 'flat', which you may not want.
Change either the background of your form or the background of your controls, thereby providing a better contrast between the two. Even slight variations on the same color would help.
Purchase (or make your own) custom controls that have built-in style changing abilities. I use the Telerik controls sometimes. They have the ability to let you change the UI Element's styles, including all kinds of colors and different borders and such. The issue with this option is a lot of these custom controls are overly expensive, although you can find decent ones for fairly cheap sometimes (I found a control set once that was pretty nice for $19).
Whatever you decide to do, you have to remember that your form will look different to users that are using different operating systems than what you're developing on. You noticed a big change when you went from (I'm assuming) Windows XP to Windows 7 right? You have to remember to test your application on all operating systems that your application will be expected to run on. You could design it beautifully on Windows 7 and it may look horrible on XP. You may be able to ignore OSs that are older than XP, but for the time being almost 50% of users still use XP (last I checked).
BTW, there is no setting for adjusting the default form colors... this just happens to be how forms look on Windows 7. I found it an adjustment when I went from XP to Win7, but you get used to it. I very rarely make the background of my controls the same color as the background of my form just because of this... oh, and don't go changing your display, you want to see what your users are going to see - otherwise you'll end up with something that only looks good on your computer. :)

Tips on debugging UI errors in Windows Phone 7

I have a Windows Phone 7 application and I regularly see "weird" UI glitches that take me AGES to debug. It's a range of issues like controls appearing to have extra margin, scrollbars not appearing, animations looking really glitchy, entire page scrolled down, combobox items offset, etc. etc.
I'm happy to admit it might be me - but how to you debug UI errors like this? I know there's Silverlight Spy for the PC Silverlight Apps. Is there anything like this for Windows Phone 7?
Any debugging tips v much appreciated.
I have found that it is a good idea to start with Windows Phone 7 Design Templates, adopt a version control system right from day one of the project and to edit the XAML, use Expression Blend. The Visual Studio is great for writing code, but, to harness the real power of the tools, Expression Blend is the best to style your application.
HTH,
indyfromoz
Here are some tips:
Many people have issues with the emulator due to their graphics card.
Things like slow animations and ui glitches are very common.
Check that your graphics card is Direct X 10.1 at least and that your Driver
Model is WDDM 1.1
Make sure you have the latest drivers.
Windows 7 has less issues with the emulator than Vista
Make sure you have the latest tools, get the RTM release from the website.
In the RTM release, the frame rate counters are displayed by default in a vertical bar on the left, you should monitor these to check for performance issues
Here are a couple of things which I normally do... none of them are real smart, but sharing nevertheless.
Deploy it after every 2-3 controls that you add and ensure things are correctly laying out.
If by chance it doesn't work the way I am expecting it to, I have a parallel Silverlight 3 project running in which I typically paste the XAML and see if it works fine.
After that, I typically check it out as a Silverlight project since even I am not sure of any tools available for Win Phone 7.
I have favorited this question and I hope someone points us to something more interesting.
There's a lot you can checkout with Blend as Indy suggests. This is really good advice.
Regarding some of your specific issues these aren't necessarily glitches. I'll comment on a couple that stand out.
Extra margin - this and padding are built into the metro controls by design. Again, in blend you can dig into this by retemplating the control and changing properties of objects within the control.
The procedure for this is rclick the control, edit template, edit a copy. Then you can look at the different states and objects and change things as suits. While doing this please keep in mind the App Certification Requirements and UI Design Guidelines.
Regarding scrollbars, these are by design hidden until you start scrolling. You can control their availability with Horizontal/VerticalScrollBarVisibility on relevant controls (or on the ScrollViewer embedded in some controls - again retemplate in blend).
Combobox isn't metro themed so is going to struggle in the fitting in department, but there are posts around where people have done work on this. ListPicker is a better fit imo from the Windows Phone Toolkit released with the RTM tools.
If you can't see any obvious causes for the glitches in your code the first thing I would recommend is to actually test your app on a real device. Somethings - particularly animated objects -don't always look exactly the same when you run them on a device.
I thought I had a animation glitch in one of my apps but it only appears in the emulator. When I run on an actual device I don't see it.
Of course this doesn't help you if you can't get a phone to test it on yet, but before you potentially waste hours trying to debug a problem you might not have I would work on the rest of the app until such time as you can test the app on a real phone.
The same goes for anyone creating animations - don't waste time perfecting animations in the emulator. The timings will almost certainly be different on the actual device, so wait till you have one to test on.