I have a simple app that changes numlock state when I'm connected to a docking station. The problem is I don't know how to detect when a second monitor is connected (and disconnected) so that I only set the state once it is connected. So I'm looking for Screen.Resize event or similar.
I'm working on Windows 7 so I will settle for Windows 7 only solution though I'd like a more universal solution if possible.
Another thing - this should be a VS 2008 C++ Express compatible solution ;-), but I have access to full VS at work so MFC requirement would be manageable too.
WM_DISPLAYCHANGE
Related
I am upgrading my development machine to Windows 10, however, our shipping software is browser based. The shipping software interacts with scales, printers...etc via ActiveX. Obviously, Windows 10 has Edge instead of IE and does away with ActiveX I believe, but I will still need to test new features and such. Is there a way to fully emulate IE 9 and 10 in Windows 10? I could do a virtual machine but I am not sure how this would interact with attached printers, dimensioners and scales. So I'm wondering if there are any cleaner methods out there.
As an aside, their software (not programmed by me) runs in quirks mode (I know...), so the emulation would need to be pretty spot on. Worst case, I can dual boot, but that won't be fun.
Windows 10 does still ship with Internet Explorer. There are a couple ways to access it.
Open any webpage in Edge and click the ellipses and choose "Open with Internet Explorer".
From file explorer, browse to "C:\Program Files\Internet Explorer\iexplorer.exe"
I'm running some local application on a mini-PC and lately it has started freezing about once a week. When it's freezing the OS seems to still respond (most of the times). Internet explorer freezing with the message that "Internet Explorer is not responding".
The application is built using HTML/JS/PHP and MySQL. It runs on Internet Explorer using WAMP. (Assume that there is no way to modify the application at the moment).
I want to to find a way to reduce Windows 8.1 resource consumption to minimum. It won't matter how the graphic may look. If possible, only leave the necessary services for running Internet explorer and the localhost application.
I want to take those saved resources and "invest" them in Internet Explorer.
I believe this solution will solve, or at least improve the behavior of the application because when the application is ran on a stronger PC, it simply never crashes even without doing anything to the OS.
Also, if there is a way to do your suggestion with a CMD command so I can make a handy .bat file, it will be great.
I called "Rasphone.exe" from my C code using "ShellExecuteEx" to create a dial-up connection. I found different behaviour on Windows XP and Windows 7.
Behavior in Windows XP :
The RASDial connection gets created without any Pop-up Window.
Behaviour in Windows 7 :
A DialUp window Pops up asking number to be dialed. I didnt enter any number, and clicked "Dial" button. Connection gets connected. The below is the snap-shot window which I get in windows 7?
What is the reason for the difference in behaviour?
What is the reason for the difference in behaviour?
Windows 7 is a different operating system than Windows XP. Before Metro was invented, the Windows team didn't have anything to do, so they sat around changing a bunch of old code just to see if anyone noticed. Looks like you've found one of the things they changed.
No worries, though. The code you had was doomed in the first place. The proper way to dial a network connection is not to launch the network dialer application, it's to call the API provided for this purpose.
The name of the API you want is WinINet, and you'll find the documentation for it here. In particular, you'll be interested in the Establishing a Dial-Up Connection to the Internet section, which mentions the InternetDial function.
Of course, they've changed this, too. Starting with Windows Vista, this function uses the RAS API internally to establish the connection. Skip the middle man by calling the RasDial or RasDialDlg functions directly.
I'm developing a Windows Mobile app using the .NET Compact Framework 3.5 and VS2008, and for debugging using the Device Emulator V3, on Win7, and seem to have constant problems with Windows Mobile Device Centre (6.1) connecting.
Using the Emulator Manager (9.0.21022.8) I cradle the device using DMA in WMDC. The problem is it's so flaky at actually connecting that it's becoming a pain.
I find that when I turn my computer on, before I can get it to connect I have to open up WMDC, disable Connect over DMA, close WMDC down, reopen it again, and then it might cradle. Often I have to do this twice before it will cradle.
Once it's cradled it's generally fine, but nothing seems consistent in getting it to connect.
Connecting with physical devices is often better, although not always. If I plug a PDA into a USB socket other than the one it was originally plugged into then it won't connect at all. Often the best/most reliable connection method seems to be over Bluetooth, but that's quite slow.
Anybody got any tips or advice?
I thought I'd add some notes to this so I could close it off. Generally I found not the following to make it a little more stable:
1) Don't setup a partnership. While this doesn't provide a major issue, if there is a partnership in place, a blank dialog window pops up whenever I connect a device.
2) Always make sure you connect the device (via USB) to the same USB port that it was first on when the device driver was first installed. Moving the lead to a different port will often cause the device to not connect.
3) If it doesn't connect then opening WMDC and un-ticking allow DMA connections, close the WMDC screen, re-open it and re-tick the DMA option, and it will generally suddenly connect.
4) Also if you're using the device emulator and have it cradled, ensure you disconnect the ActiveSync connection before saving the state of the device when closing it. If you fail to do this it will no be able to connect when you restart the device, until you fiddle about with the connection enough for it to realise that it's not actually connected.
If anybody else has any tips to making it more stable then feel free to add them in.
Try deleting the existing device partnerships. That has helped me in the past when WMDC/ActiveSync was playing up.
Go to Control Panel -> Sync Center and delete the device partnerships you see listed there.
Then reconnect your device/emulator and when the WMDC window comes up, make sure you create a new device partnership (in my experience the connection/debugging becomes flakier when you choose to not setup a partnership).
Another thing to point out about ActiveSync, I learnt this the hard way, I noticed the battery drains faster with ActiveSync, even if it is not in the cradle, it is actually running in the background, and whether it is a bug or not, not sure, but, it 'thinks' it is still in the cradle and continuously polling for the connection. Here's the link that explains it. And here's the temporary fix.
The way I dealt with it is to run a small C program that looks for the ActiveSync process and kill it each time I un-cradle the pocketpc.
Let's say you have a slow laptop which can't handle Visual Studio but a blazingly fast desktop that can. Let's also say that you want to develop in several rooms in your house. Are there any drawbacks to having Visual Studio running on the desktop and simply using the laptop as a way to access it remotely? I'd guess that the only thing that you would be concerned about would be the network latency, but if the two computers are on the same network that should be minimal.
Do it.
Since you are running Visual Studio in your own local network, the main drawbacks (security and latency) are not there. In addition, you get the speed of your desktop and the mobility of your laptop.
I do this a lot even over broadband, I've never found speed to be a problem.
This is my standard working practice at work. There are times when you have issues, such as opening TFS document attachments can fail, but overall the experience is fine.
It is also an added bonus that you can leave it running continually (i.e. overnight / weekends) and you can kick off a build before you leave for the evening and come back to a packaged installer (or an error :) ).
I'm looking forward to (in a year or two) be able to do this over Hyper-V - then the application will run as though it IS on my laptop, with no remote desktop required.
No big drawbacks. I've been running VS 2008 remotely on a server 400 miles away, using GNU/Linux and rdesktop on my laptop and the server (of course) running Windows. The only problems I encounter are that it is a mess to move files between the two - but if you have the desktop near and can install anything you like (ftp programs for example), I can't see any drawbacks.
In a corp work environment where I've tried this I never felt particularly joyful. Tried using MSTSC and VNC.
Having a desktop with multiple monitors and trying to view that through a smaller laptop display is typically quite painful, never enough space.
Even when it was PC's on the same switch there always seemed to be some delay in the mouse moving or typing, I'm sure you could adjust, I just found it a bit annoying too.
We haven't tried serving up DevStudio from a CITRIX server yet, that might be worth a go.
I work a lot with Visual Studio over broadband, which is ok.
If you are running linux on your laptop, rdesktop is your friend. There are many options to gain more speed, like using 8-bit color instead of 16 or more. I don't know if mstsc offers such options. Visual Studio 2008 has got many options concerning speed which can be enabled if the connection is too slow: disable fancy menus etc.
greetings
I think that having the dual (or more) monitor set-up does beat the ease of mobility when using a laptop connecting to a remote desktop. I work at home at least two days in a working week using my laptop (which is a 17", 1900x1200 screen, basically what they call a "desktop replacement"), connected to VS and TFS using VPN and I find that experience less than the situation at work where I have the 17" laptop screen AND a 24" TFT (also 1900x1200).
I also have experienced that running VS (or SQL Server Management Studio for example) over an RDP session is just not like the real thing. It does get the job done, however the "feel" isn't just the same.