If it has issues, you're probably doing it wrong. The GUI should really only be updated directly from a single thread. If you have any asynchronous updates (i.e. from an independent thread), they should remain asynchronous. There are asynchronous communication methods within the Windows frameworks, use them.
Is this a Fragility a feature of MFC, and from how it wraps the SDK functions, or, is this a Feature that is Central to Windows, (i.e. the SDK suffers from the same problem) I have read several articles about this, and, the Gist is that it is always unsafe to communicate between two threads. This is clearly to conservative, Microsoft manages it quite well in for instance their MS Office Products.
The GUI elements should only be accessed from the main GUI thread. Accessing from another thread sometimes but not always results in an exception. As the others have said, use PostMessage to trigger an update in the GUI thread.
Is it possible to programmatically under Windows force a USB3 port to operate in USB2 mode, and then at a later time to switch it back into supporting USB3 mode? We need to test that a piece of hardware functions with both USB2 and USB3 connections, and would like to do this programmatically to prevent operator errors.
It will switch automatically if you plug a USB 2 device in, as the USB 3 pins will not be live. But most PCs these days have both types so it should be fairly simple to do. The only other way I can think of would be in the BIOS somehow, or to remove the 3.0 driver.
Yes, I know it will switch to USB 2 mode with a USB 2 device. We need to avoid an operator having to plug the device into a USB 3 port, and then moving it to a USB 2 port, as they can be lazy, or make mistakes. We need the switching to be automatic and fast, and some form of switchable hub that connects to USB 2 and USB 3 ports on the PC may be the answer.
Richard, we have a unit that needs to be tested on the production line, prior to shipping to the customer. The unit must work with both USB 2 and USB 3 connections. I won't go into the reasons why we need to test both connections but we do. At present the operator must manually take the USB cable out of the USB 3 socket, and put it into the USB 2 socket, and vice versa, when requested to do so by the test script. This introduces room for error, as they might get confused, and also they might end up damaging the USB socket since they will do this many times each day.
So a better solution is to have a software controlled way to switch between USB 2 and USB 3 connections. Jochen's suggestion is a significant improvement on the current scheme.
Do not trust software emulation where you can easily use real hardware...
In most computer there are both USB2 and USB3 port, and it is very easy to get a expansion card for $5 if you happened to work with a PC without USB2...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
You may use an "USB 3 sharing switch" (use that search term). They provide connection of an USB device to two or more computers but may be off course also used to connect to two ports of one computer. These usually have a key to switch the ports and may support auto detection.
If you don't want the operator to press the switch key, you may look for one that supports other switching methods. I found at least one that allows switching using a hotkey when connected to a Windows PC. Your test program might then simulate the hotkey activation.
If the switch has an auto detection it should be also possible to trigger that by disabling one of the PC USB ports. But I have done such with Linux only so far and don't know how to do that with Windows. Note that this method (like the one initially asked) requires administrative privileges.
I want to execute a windows command in my C++ program.
I know it can be done by adding system function.
I want to add the windows command to a specific drive. I have coded a program which will collect the specific drive and will store the value in a wchar_t store
so in order to go for that specific drive I used
system("store");//variable in which the disk like D:\ is stored
No that will try to execute a program/script called store. It is not clear what you mean by "add the windows command to a specific drive". Do you mean that you wish to add the drive letter to the command as a parameter, like:
I think I have not explained my problem briefly.here is the brief explanation of my problem
I want to find the attributes of the removable drive so, I need to get the string of the drive I've done everything and stored the string value in the "store" variable I mean the variable consists the drive location(D:\) so that I can execute another system function called attrib to find its attributes.