I have a program which is able to exchange data with MS Office applications, via the clipboard.
This works fine in Office 2007 and Windows Vista/XP, but fails with Office 2010/Windows 7
IDataObject *d = NULL;
HRESULT hr = ::OleGetClipboard(&d);
if (hr == S_OK)
{
FORMATETC formatEtc;
formatEtc.cfFormat = ::RegisterClipboardFormat("Native");
formatEtc.ptd = NULL;
formatEtc.dwAspect = DVASPECT_CONTENT;
formatEtc.lindex = -1;
STGMEDIUM stgMedium;
hr = d->QueryGetData(&formatEtc);
Following this call, I am returned an error - 0x8004006a Invalid clipboard format
I have tried searching the web, but haven't found any relevant information. Any advice/suggestions would be gratefully received.
Thanks.
i have a similar issue in Office 2007 and Windows-server-2008, my guess the problem is not the office but rather the windows 7/2008. are you running your program as a service? or an as executable?
I'm still waiting for an answer for my question over here:
Clipboard Copy-Paste doesn't work in a service on Win Server 2008/Vista 64bit
please let me know if you have resolved your issue!
Update: i have found out that this is a sessions issue. try finding out if your app and the word/ other office app is running in the same session (try using process explorer for that).
Related
I am trying to help one of my customer to migrate a very old vc++ program which works on Windows 2003 as a win32 service to x64. It was compiled with VC 2005.
I have migrated to VC 2019 with windows SDK 10 & Windows 10.
There were few minor issues in DB and windows service ATL. I was able to fix them all.
Now there is a strange issue with the IOCP wherein the GetQueuedCompletionStatus results in success but the psobSockInfo and PerIoData results in unable to read error. (attached to the process in vs 2019 in debug mode).
bResult = GetQueuedCompletionStatus(sobIocpThParam->hReqRecThread,&BytesTransferred,(PDWORD_PTR)&psobSockInfo,(LPOVERLAPPED *) &PerIoData,INFINITE);
The code is written very similarly to this example and the header file in line with
I have tried to zero both the memory, tried to set the pointers to NULL. Nothing has helped. The bResult is 1. BytesTransfered is 177, The socket handle is valid.
Can any one point me in the right direction?
In earlier versions of Windows this paused automatic updates:
IAutomaticUpdates *automaticUpdates = 0;
HRESULT hr = CoCreateInstance(CLSID_AutomaticUpdates, NULL, CLSCTX_ALL, IID_IAutomaticUpdates, (void**)&automaticUpdates);
if (automaticUpdates != NULL)
{
hr = automaticUpdates->Pause();
}
According to MSDN, "IAutomaticUpdates::Pause is no longer supported. Starting with Windows 10 Insider Preview calls to Pause always return S_OK, but do nothing." IAutomaticUpdates::Pause
We don't want Windows Update interrupting our program. Does anyone know of a workaround?
With Windows 10 a bunch of settings are no longer available. Here the settings of the update service are now no longer free to set by the user.
Because you need administrative rights to even call Pause, you may stop the Windows Update Service at all. But this is a very harsh way to prevent the update service to interrupt you. I wouldn't recommend this a a real practical solution for me. But it may help you.
For some reasons, I have to create D3D9 in my program, which is running as a service.
But I got D3DERR_NOTAVAILABLE for the following code:
ATL::CComPtr<IDirect3D9Ex> d3d9 = nullptr;
HRESULT hr = ::Direct3DCreate9Ex(D3D_SDK_VERSION, &d3d9);
And it works if it's not running in a service.
I saw someone success to do this by checking Allow service to interact with desktop in the Control Panel, but it doesn't work for me.
Is there any setting I have to mention?
In Windows Vista and later, Windows Services run in an isolated context (called 'session 0 isolation') to reduce threats from malware. In some cases, you can create a NULL device and possibly a WARP device, but Direct3D GPU access from a Windows Service is not available until Windows 8.
See KB 978635
I have created a very small win32 console application (AddPrintMonitor.exe) that does nothing more than makes a call to AddMonitor. Here is a small snippet:
MONITOR_INFO_2 m_MonitorInfo2;
m_MonitorInfo2.pName = lpMonitorName;
TCHAR env[12] = TEXT("Windows x64");
m_MonitorInfo2.pEnvironment = env;
m_MonitorInfo2.pDLLName = lpDllName;
if ( !AddMonitor(NULL, 2, (LPBYTE) &m_MonitorInfo2) )
{
DWORD error = GetLastError();
std::cout << "Last error = " << error << "\n";
return PRINTER_ERR_API;
}
When I run this as a member of the Administrators group is fails. GetLastError() returns 5. When I run it as "The Administrator" it succeeds with no issues. I am running on Windows 7 x64. I am trying to install the redmonnt.dll and I do have the 64 bit version of that dll. This task is part of a larger install for a PostScript driver. I've only isolated out the AddMonitor portion to eliminate other external issues.
Error 5 is an access violation or security issue. My first question is why can't a member of the administrators group carry out this function call? What's the difference between the actual administrator and a member of the administrators group given this context?
Other details to note. I am using InstallShield 12 (old) for my Printer installation (addmonitor is only part). I am adding a monitor, port, driver and printer all through win32 function calls. Prior to running my AddPrinterMonitor.exe I made sure that the redmonnt.dll does exist in the system32 directory. Actually, whether the dll is present there or not makes no difference for the error I see. I did see posts about setting SeLoadDriverPrivilege. This is a dead end for me as I checked and the administrators group can Load/Unload device drivers.
Also, I am using win32 calls to get this done. This worked (I mean all of it worked) without any problems on Win2K, WinXP and Windows Server 2003. With the newer OS's like Windows 7 there are several difficulties. Is there a better way that I've overlooked? I been very frustrated trying to get this to work, so I've begun to question the approach for Vista and higher.
More initialization code:
#define MONITOR_NAME "My Redirected Port"
#define MONITOR_FILE "redmonnt.dll"
MONITOR_NAME is passed to lpMonitorName and MONITOR_FILE is passed to lpDllName
thanks
I'm running a C++ program (which works great on 32 bit Win XP) on Windows 7 64 bit in debugger under Visual Studio 2010 and I am unable to open an existing registry key with the following code:
#define ACCESS (KEY_WRITE | KEY_QUERY_VALUE | KEY_ENUMERATE_SUB_KEYS)
HKEY hKey;
long dwErrorCode = ::RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software\MYTHING", 0, ACCESS|KEY_WOW64_64KEY, &hKey);
if (dwErrorCode != ERROR_SUCCESS)
{
// display error message
}
The error code returned is: 5 with the system message being "Access is Denied".
This does work if I run the Visual Studio 2010 as Admin, however I'd rather not have to do that. Can anybody offer a suggestion?
Update: I forgot to mention, what I am doing here is porting legacy code from Windows XP. As such, I don't have the option of changing the fundamental structure of how this software was written. Since the legacy code uses the registry, that is what the ported code must do also.
Also, I would rather not make changes to my specific computer -- since that means I would have to change every computer that I want to run this on. This could get messy as there are a lot of machines affected. For example, I don't want to turn off UAC for the entire machine.
Further update: I haven't found a solution that I'm happy with. Have decided to ignore error code 5 for purposes of debugging and that seems to be working well enough for now. I'm trying to understand how standard apps like Word, Firefox, etc appear to be using the registry for all kinds of settings and yet are not elevated nor do I have to give them special permissions to make changes to the registry?
Ok, I found the answer to my question so I'll post it here in case anybody else needs it for future reference. This thread turned out to be helpful even though it is actually on the topic of C#:
http://social.msdn.microsoft.com/Forums/da-DK/netfx64bit/thread/92f962d6-7f5e-4e62-ac0a-b8b0c9f552a3
Basically, I needed to change my permission to read the 32 bit registry instead of the 64 bit one like so:
HKEY hKey;
long dwErrorCode = ::RegOpenKeyEx(HKEY_LOCAL_MACHINE, "Software\MYTHING", 0, ACCESS|KEY_WOW64_32KEY, &hKey);
if (dwErrorCode != ERROR_SUCCESS)
{
// display error message
}
Voila, everything works now! Thanks for your efforts everyone.
Update: it turns out this didn't work as well on my other machine, which led me to discover that someone must have changed access rights to the 32 bit registry on one of my machines. So it is still necessary to give the User access rights to the registry key you want to work with.
You need to run the process in elevated mode, or turn off UAC. You can of course assign access rights to your specific registry key that allows you access.
I have faced same issue. I have solved using following:
LPCTSTR subKey = TEXT("Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\App Paths");
LONG openRes = RegOpenKeyEx(HKEY_LOCAL_MACHINE, subKey, 0, KEY_WOW64_32KEY && KEY_ALL_ACCESS, &hKey);