I'm having a weird bug on one of my computers with Visual C++. For some reason the screen will stop refreshing where my source code is. I can force a single refresh if I minimize and maximize Visual C++.
For example if I try to type something or use the scroll bar, it will not show any changes until I minimize and maximize. If I type something the changes have been made however. I can save and those changes will remain.
Oddly auto-complete still works as intended. If I type myClass.get_ it will bring up the auto-complete window.
It seems to occur randomly. It can happen if I leave the program up for a bit while doing other things or when I first start up the program. A fresh reboot nearly always fixes at that moment but what ever the cause is will occur after time. One thing that nearly always causes the program to stop working is if I start a video game.
I'd appreciate any help, thanks.
Assuming this is VS2010 - I think it does new-fangled GUI things with WPF and notably relies on hardware acceleration and write combining quite a lot more than before.
I had display issues in a virtual box gues installation (with multiple-monitor support in the guest enabled). I worked around it by lowering / disabling the hardware acceleration settings for the (virtual) graphics adaptor.
right click desktop
screen resolution
advanced/performance
use the slider to adjust acceleration level
Changing this setting apparently required a reboot on my system when I did it.
Related
I maintain a gtk3 (though a mixture of gtk2hs and gi-gtk) application that serves as a standalone status bar for tiling window managers called taffybar.
Taffybar has a long standing bug where something happens that causes one of its windows (it can have multiple windows e.g. when displaying on multiple monitors) to stop updating completely (issue here). I have verified through various logging mechanisms that the code that is supposed to be updating the window IS in fact continuing to run. Also, if taffybar is displaying on multiple windows, windows will become affected one at a time -- that is, the hang only seems to affect the window on which it occurs, which rules out anything strange happening on the UI thread or something like that.
Unfortunately, I do not have a consistent way to reproduce the issue. What's worse is that I haven't even been able to come up with a way to detect the issue programmatically. With that said, it is relatively easy to get the issue to occur as it has gotten much worse recently with the new icon loading mechanisms that have been added (it seems to happen about once every 5 minutes in the latest version). This reminds me that another thing I should mention is that I am relatively certain that the issue has something to do with pixbufs and image display because I have never seen the issue occur when the workspace images module is not active.
I hate to ask a question without even being able to provide a consistent way to reproduce the issue, but I'm simply at a loss as to how to go about tackling/debugging this issue. It's hard for me to imagine how the behavior that I have described is even possible, actually. I'm hoping that something about the idiosyncratic nature of the issue might be enough for someone more knowledgable about gtk than I to make some guesses as to what the issue might be.
To make my questions as explicit as possible I'll phrase it as follows:
What could cause a gtk application window to hang (stop updating) without crashing the application or the UI thread, or affecting any of the other windows created by the application?
EDIT: One more interesting quirk of this bug is that even though the window stops updating, it still responds to mouse input.
EDIT2: Another thing worth noting is that occasionally, I have gotten this message:
gtkicontheme.c:3956:proxy_pixbuf_destroy: assertion failed: (icon_info->proxy_pixbuf != NULL)
I have also gotten the following message when I attempt to destroy the hung window in code:
Source ID 363524 was not found when attempting to remove it
I am loading icons from the icon theme sometimes
I believe that the cause of this issue was simply that some UI updates were not being performed on the main UI thread. I can't be 100% certain of this because I was never able to reproduce. See this comment for more details:
https://github.com/taffybar/taffybar/issues/228#issuecomment-402591159
Running an up-to-date Gentoo on my Sager NP8298 (Clevo P177SM-A), and I am heartbreakingly close to having all of my hardware running beautifully. I found a nice open source driver to run my keyboard backlight at this GitHub repo, but the problem was it was made for a Clevo chassis that didn't have the touchpad light that mine does. Kinda tacky, I know, but the problem is that the default color for the touchpad light is blue, and can be kind of distracting when the keyboard is set to a different color.
I'd at least like to be able to turn the light off, if not control its color. I have a Windows install and am able to access the proprietary driver that came with the computer. I just don't quite know where to start on trying to modify this driver, if there were some Windows utilities that I could use to see what the driver is doing and how to access the LED programatically, it would be a huge help. Any ideas?
Other functionality that I'd like to add is Fn+Num pad 7 through 9 for toggling the left, center, and right part of the keyboard individually, and Fn+5 for a num pad light toggle, as the Windows driver does. I just need to know what signals need to be sent to the hardware and how to send them.
Whatever I end up with I'll be sure to fork the project and share the results with other users of this hardware.
You need the source code of driver you want to change. With that and all required bits and bobs (a.k.a. dependences) you can change it to do whatever you want.
That said, there are quite a few things to consider. You need to know, at least at a reasonable level, the language used to build the driver, platform dependencies if any.
I've done similar work for some network drivers like 15 years ago and no it's not a fun job.
I'm currently stuck with a pesky little issue. I developed an application that zeroes out the DXGI mode desc. structure and calls FindClosestMatchingMode() to, as advertised, "gravitate towards the desktop resolution".
This works fine if the laptop(s) run fully on their own display -- as soon as I plug in another monitor it goes berserk. In the case I extend my desktop it will still correctly get the laptop monitor resolution, yet the attached one (running 1080p) will yield a preference for 800*480 :) (sure, poor man's 16:10, but...)
Doing the same thing with the monitors cloned/combined (results in 1 output device), even if their resolution is equal, gives the same 800*480 crap.
What gives? And has anyone perhaps found a way to properly get a display's current mode through DXGI or a pointer for a wholly different yet functional approach to this here problem?
Life was easier back in the D3D9 days =)
-- Update
As it turns out any FindClosestMatchingMode() call made on the IDXGIOutput instance belonging to the external monitor behaves differently (and in most cases plain wrong) compared to the internal display, even though their native resolution is identical. To top it all off, other systems don't have this issue yet I can't get around supporting this particular laptop including it's drivers.
Time for a good old setup dialog.
Not the best solution but as I was constrained to these exact machines I settled for getting the monitor's current resolution through GetSystemMetrics() (SM_CXSCREEN/SM_CYSCREEN), which admittedly only works for the primary monitor but there's other ways, and feeding this resolution to the ModeToMatch structure fed to FindClosestMatchingMode().
It then settles for the correct (desktop) resolution.
Better answers are very welcome of course ;)
I'm starting my first project that runs on a 7 inch touch screen running Windows CE 6.0 (and NETCF 3.5).
The touch screen doesn't respond to touch too well when I use my finger. The only way for me to navigate around is by using a stylus (or similar).
Since I've never worked with Windows CE or a resistive touch screen, I'm not sure if I should expect to be able to use my finger or if the stylus method is, essentially, the only way to effectively navigate around. - or, maybe, I have a touch screen that simply isn't that good.
If you have experience with WinCE running on a touch screen, do you find that a stylus is the only way to go?
A resistive touchscreen can certainly provide feedback for a finger - I've even configured them for hands-in-gloves. It sounds like the touchscreen driver is tossing out the data samples it's getting from the panel and the key for you is going to be to figure out why.
In my experience there are really two primary reasons for your samples to be ignored.
The driver has been configured to too tight of a tolerance.
Sensitivity is often a configurable item. Maybe through recompile of the OS, maybe through the registry - depends on how your OEM implemented it. Check with the OEM and see if you can adjust it.
The panel has too much noise, causing your samples to get tossed
This one is easy to check. Drag a selection rectangle on the desktop with a stylus and hold the end point down (don't lift the stylus). Is it steady, or does it "wiggle" a lot at the final point? If so, you have noise. Grounding the panel usually helps, but it could be a hardware issue. I've done rolling-average work in touchpanel drivers to help smooth this out, but you then have to fight hysteresis.
Be aware that larger touchscreens have different resistivity properties than smaller ones, so if you just swapped panels from small to large, it's quite possible that the output range difference of the panels is not workable with the current driver settings. Again, some OEMs provide the ability to adjust these settings.
So can it work with a finger? Well there's nothing in the physical theory that would prevent using a finger. In fact if you can't use a finger, there's something wrong. Will it work in reality? Check with your OEM.
I'm currently designing my first ever GUI for Windows. I'm using MFC and Visual Studio 2008. The monitor I have been designing my program on has 1680x1050 native resolution. If I compile and send my program to one of my coworkers to run on their computer (generally a laptop running at 1024x768), my program will not fit on their screen.
I have been trying to read up on how to design an MFC application so that it will run on all resolutions, but I keep finding misleading information. Everywhere I look it seems that DLUs are supposed to resize your application for you, and that the only time you should run into problems is when you have an actual bitmap whose resolution you need to worry about. But if this is the case, why will my program no longer fit on my screen when I set my monitor to a lower resolution? Instead of my program "shrinking" to take up the same amount of screen real estate that it uses at 1680x1050, it gets huge and grainy.
The "obvious" solution here is to set my resolution to 1024x768 and redesign my program to fit on the screen. Except that I've already squished everything on my dialogs as much as possible to try and get my program to fit on screen running at 1024x768. My dialog fonts are set to Microsoft Sans Serif 8 but still appear huge (much larger than 8 points) when running at 1024x768.
I know there HAS to be a way to make my program keep the same scaling... right? Or is this the wrong way to approach the problem? What is the correct/standard way to go about designing an MFC program so that it can run on many resolutions, say 800x600 and up?
I assume your application GUI is dialog based (the main window is a dialog)?
In that case you have a problem, because, as you discovered, MFC has no support for resizing a dialog correctly. Your options are:
Redesign your GUI to use a SDI or MDI GUI.
Use a dialog resize extension. There are many available, for some very good suggestions see this question. Another options are this one and this one.
Don't use MFC. wxWidgets has much better support for dialog resizing.
MFC is only a thin wrapper over the Windows API. They both make an assumption which is hardly ever true: if you have a higher resolution screen, you'll adjust the DPI or font size in Windows to get larger characters. Most of the time, a larger screen size means a larger physical monitor, or a laptop where you want to squeeze as much information into a small screen as possible; people value more information over greater detail. Thus the assumption fails.
If you can't squeeze your entire UI into the smallest size screen you need to support, you'll have to find another way to make it smaller. Without knowing anything about your UI, I might suggest using tabs to group the controls into pages.
I've had good luck making my windows resizable, so that people with larger screens can see more information at once. You need to do this the hard way, responding to the WM_SIZE message to the window and deciding which controls should be made larger and which ones should just move.
There is no automatic way to resize the content of your dialogs when resolution changes. So, you need to set some boundaries.
Option 1.
If you are developing your app for customers, pick one minimum resolution (like 1024x7678), redesign you dialogs so that everything fits. Maybe break up some into several, or use tab strip control.
Option 2.
Create separate dialog forms for each resolution you'd like to support, but use the same class to handle it. At runtime detect resolution and use the appropriate form.
Option 3.
Write your own resizing functionality, so that user could adjust the size of your dialogs to his liking.