When the external update process should also update the executable of your main application, that must be terminated before the new exe file can be copyied. So there is no need to get the focus back.
I have managed this kind of problems with success so, dont bother with that.
In another post you mentioned that you are using WaitForSingleObject to wait for the update process to be terminated. If you call that from within your main thread, your application's message loop is blocked so that paint events are not processed.
Thats correct. Windows Vista/Win7/Win8 does not have problems with paint events but XP they have. For that reason I want to disable the parent to avoid such kind of problems.
If you don't want to update the executable itself and must wait for the external process to be finished start the process from within a worker thread where you can call WaitForSingleObject without blocking the message loop. Use a global state variable indicating that the update is executing to disallow specific tasks of your application or just show a modal dialog that is closed automatically when the update has finished.
I update the executables too, but I dont have problems with that. If you download the sample code, you will understand the focus problem i currently have.
My intention was to show you a solution that differs from your current implementation and pointing to the fact that you block the message loop.
You must not call WaitForSingleObject from within your main thread to ensure that the window is repainted (e.g. when moving another window over the application window). That will solve the problem of paint corruption and might also solve your other problems.
Overall I think I must shout: Don't use WaitForSingleObject from within your main GUI thread; especially with long wait times!
I (like most others here) will not download a complete project and build it. Especially in this case where it must be tested with XP too.
You can disable your app window and/or show a modal dialog while the worker thread is active and re-enable when it finishes. So the message loop is not blocked and repainting is ensured while the app itself is blocked.
What do you mean by floating windows? There is no additional window.
I have created a sample console app (windows universal) using VS2015. If I call the method QueryDosDevice(), it results into ERROR_ACCESS_DENIED error. I am deploying this app on Windows 10. Interestingly I can call APIs from ntdll. But seems like it gives access denied error if I try to call APIs from kernel32.
Are there are access (perhaps for volume management APIs) restrictions introduced for universal apps? If yes, Is there any way around it?
Assigning administrator rights to an application requires administrative privileges. So while it does not have these, you can't change it. And you can not elevate the privileges of a running process.
You can use a manifest to specify that your application should run elevated, use the "runas" command or start other applications elevated from within your program. But in all these cases there will be a UAC prompt.
UAC is there for a reason. It is a security feature. The user decides which level of security should be used. An application can not bypass these settings.
l want to ask how l can do the following things in a tab control.
1)That is, for instance: In tab1, when a button is clicked, previous text is wiped and another is written. l had tried but all the texts overlaps and none cleanses off fornew texts.
2)How can l erase the content of a tab control when l switch tabs. As in, when tab2 is clicked, contents in tab1 clears off and the things in tab2 only shows.