I'm trying to find out if a window belongs to the current virtual desktop.
I found the VirtualDesktopManager class form the winapi, but even though it is supposed to be in the "shobjidl.h" header according to here, when I compile the code it throws this error:
85:5: error: 'VirtualDesktopManager' was not declared in this scope
important piece of my code:
#include <shobjidl.h>
...
BOOL is_on_current_desktop = FALSE;
VirtualDesktopManager g_pvdm;
g_pvdm.IsWindowOnCurrentVirtualDesktop(hwnd, &is_on_current_desktop); // hwnd is a window handle acquired previously
g_pvdm.Release();
How could I make this work?
Apparently this interface was not included in the "shobjidl.h" header in mingw64 which I was using, running it in Visual Studio it finds it. So the issue was in the header.
Related
So I am reading up on some OpenGL and I want to use the QOpenGLWidget for drawing to maybe create some other helpful UI elements later. I am using glad for resolving the function pointers to OpenGL but I have no idea how to use Qt's getProcAddress function!
Inside my QOpenGLWidget subclass' initializeGL() function I have tried:
if(gladLoadGLloader((GLADloadproc) currentContext()->getProcAddress) {}
but that did not work out since Qt's function is overloaded. When I use
if(gladLoadGL()) {}
it doesn't work either. My includes are:
#include <glad\glad.h>
#include "OpenGLViewport.h"
#include <QDebug>
#include <QOpenGLContext>
I have searched Mr. Google and I've had a diligent look through the Qt documentation and found nothing. I want to use GLAD just so my rendering code is not bound to Qt too tightly, in case I want to switch later.
EDIT: I am aiming to use the noninstanced OpenGL functions with Qt (though the documentation recommends otherwise if I recall correctly). Because then I'd be able to seemlessly switch to GLFW for providing a window etc.
Moved solution from question to answer:
ANSWER: So it turns out I just had some things mixed up, this is how I got it to work, in case anyone has the same problem:
add glad.c in your project
add the necessary headers to your include directory
the .cpp file of your QOpenGLWidget subclass should have following components:
// Subclass.cpp
#include <glad/glad.h>
// important, subclass header file after glad!!
// otherwise glad won't "hook"
#include "Subclass.h"
void Subclass::initializeGL()
{
if(gladLoadGL()) initialized = true; // initialized is a class member here
else; // handle errors
}
void Subclass::paintGL()
{
if(initialized); // render here
}
Problem
I'm trying to open an MFC program that reads a Microsoft Access database (.mdb) and allows the user to view or modify the data. This is an existing program (and source code) given to me by a group in another lab where the program opens and works just fine.
In our lab, I have yet to see it load properly. When run, it pops up a dialog box that says, "Attempted an unsupported operation". Windows then offers me a chance to debug and such before it crashes.
Environment
In the other lab, they use Windows 7 and Microsoft Office 2010, and it works.
In our lab, I've tried Windows 7 with Office 2013 and Windows XP with Office 2010. The latter crashes without giving me the dialog box. I don't know if we have a Win7/MSO2010 machine.
The Function
I have the source code for the program. The solution file implies it was last developed in VS2010, which the computers I tested on had installed as well. Running it out of Visual Studio 2010 or straight from the executable yields the same results.
I have added additional debug dialog boxes to the code that narrow down the problem to this function call, which the code never gets past:
CwinApp:OpenDocumentFile(LPCTSTR lpszPathName)
The single string passed into the function is a path and filename for the MS Access database to be opened. It exists in a temporary directory created by another program. This is on a drive other than C, though I've tested some there, as well. Problems with programs related to this one often stem from files with "read only" status, but I continually check the temporary files created, and they are write-able.
Documentation
I found this information titled "Breaking Changes in Visual C++" for VS2010 through another SO question:
A new virtual function was added to the CDocTemplate class. This new virtual function is CDocTemplate::OpenDocumentFile. The previous version of OpenDocumentFile had two parameters. The new version has three parameters. To support the restart manager, any class derived from CDocTemplate must implement the version that has three parameters. For more information about the function, see CDocTemplate::OpenDocumentFile. The new parameter is bAddToMRU.
Code
I feel this might be the answer! But I don't have a strong idea of exactly what to change to get this to work. Here's where I stopped:
Program.cpp
CDocument* ProgramApp::OpenDocumentFile(LPCTSTR lpszFileName, BOOL bAddToLRU, BOOL bMakeVisible)
{
// Add specialized code here and/or call base class
// Debug messages added
CDocument* tempDoc;
AfxMessageBox(lpszFileName);
tempDoc = CWinApp::OpenDocumentFile(lpszFileName, bAddToMRU);
AfxMessageBox("Opened database!");
return tempDoc;
}
Program.h
class ProgramApp : public CWinApp
{
public:
...
virtual CDocument* OpenDocumentFile(LPCTSTR lpszFileName, BOOL bAddToMRU, BOOL bMakeVisible);
afxwin.h
class CWinApp : public CWinThread
{
...
virtual CDocument* OpenDocumentFile(LPCTSTR lpszFileName);
virtual CDocument* OpenDocumentFile(LPCTSTR lpszFileName, BOOL bAddToMRU);
Changing the Program.cpp call to be from a "Template" class caused errors, but I wouldn't be surprised if that's towards the answer. This solution looks similar, but I'm not sure exactly what to do.
My hope is that this problem has a simple solution that someone more knowledgeable can give me. I would be much appreciative, and additional context would help a lot.
Edit: Debugging
I drilled down into the Windows code to see what was precisely going wrong. It seemed too dense to understand, but a coworker and I may have clues based on it. The failure message happens here:
dlgdata.cpp
// Could be a windowless OCX
pSite = m_pDlgWnd->GetOldControlSite(nIDC);
if (pSite == NULL)
{
TRACE(traceAppMsg, 0, "Error: no data exchange control with ID 0x%04x.\n", nIDC);
ASSERT(FALSE);
AfxThrowNotSupportedException();
}
...Although we are seeing debugger issues here:
occcont.cpp
COleControlSiteOrWnd *pemp = new COleControlSiteOrWnd(hwndCtrl, pOccDlgInfo->m_pItemInfo[i].bAutoRadioButton);
ASSERT(IsWindow(pTemp->m_hWnd));
if (IsWindow(pTemp->m_hWnd))
{
hwndStart = pTemp->m_hWnd;
...
My coworker believes this could have little to do with the opening of this document as I suspected and more to do with objects/controls we don't have on our lab computers trying to be used for the program.
I have faced the same problem in opendocumentfile(), there was a control in CFormView class which i was not using so i commented it out but forget to delete from .rc file. Once i remove the control entry from .rc file the problem disappear.
there should be no control variable uninitialize , please check that also
my compiler says: destroyWindow isn't an element of cv. (hope i translated it correctly)
i included opencv/highgui.h and actually there exists:
destroy window and all the trackers associated with it
CVAPI(void) cvDestroyWindow( const char* name );
I am using the latest version of opencv.
Yes, this function exists within the namespace cv as:
void destroyWindow(const string& winname)
And you should include:
#include "opencv2/highgui/highgui.hpp"
which is the appropriate header to add when working with the C++ interface of OpenCV. If you need samples, check samples/cpp/ffilldemo.cpp (can be found inside OpenCV's source code).
I'm very much a C++ newbie, so please bear with me.
This line of code which resides within a function:
CWnd* pWnd = CWnd::FindWindow("Shell_TrayWnd", "");
CWnd is coming up as "undefined". I know I need to define it in the global scope, but how? What header do I need to include to use this class? Project is MFC.
Using VS 2010.
Here's how to solve this problem independently.
First, Google for "cwnd"
Second, click the first link.
Third, read the page
Requirements
Header: afxwin.h
My MFC application using the "ESRI MapObjects LT2" ActiveX plugin throws an ASSERT at me when closing it.
The error occurs in cmdtarg.cpp:
CCmdTarget::~CCmdTarget()
{
#ifndef _AFX_NO_OLE_SUPPORT
if (m_xDispatch.m_vtbl != 0)
((COleDispatchImpl*)&m_xDispatch)->Disconnect();
ASSERT(m_dwRef <= 1); //<--- Fails because m_dwRef is 3
#endif
m_pModuleState = NULL;
}
I built the (native C++) application with VC9.
When I compile the application with VC6, it behaves nicely.
What could be the reason for this?
That looks like a reference count. Could this "target" be referenced by something else, something that's not releasing it?
You can trace the Addref and Release calls defining _ATL_DEBUG_INTERFACES
from http://msdn.microsoft.com/en-us/library/sycfy8ec(VS.80).aspx
_ATL_DEBUG_INTERFACES
Define this macro before including any ATL header files to trace all AddRef and Release calls on your components' interfaces to the output window.
Using _ATL_DEBUG_INTERFACES did not yield any additional output...
I defined it on the first line of stdafx.h, directly after #pragma once so I guess this is early enough.
Maybe the reason is how I am using the ActiveX control:
I'm not calling AddRef() or Release() by myself.
The MapObjects Installer comes with sample code with lots of wrapper classes which must have been generated by VC6 or something earlier.
I tried to generate wrapper classes myself with VC9 but there occured errors which I wasn't able to fix.
I use the control by letting one of my windows have a member of type CMap1 (derived from CWnd), which is one of those generated wrapper classes. In CMyWnd::OnCreate() I also call CMap1::Create() and that's it, I'm finished: I can add a layer and the control displays a world map.
I have pretty much no idea what the reference-count stuff is about as I have not added or released any references. At least not knowingly...
The control is pretty old: The .OCX file has the year 2000 in its version information.
It's also not officially supported anymore but I don't have any substitue.
The following solved it for me:
In the window that contains the control, add an OnDestroy() handler:
void CMyWnd::OnDestroy()
{
// Apparently we have to disconnect the (ActiveX) Map control manually
// with this undocumented method.
COleControlSite* pSite = GetOleControlSite(MY_DIALOG_CONTROL_ID);
if(NULL != pSite)
{
pSite->ExternalDisconnect();
}
CWnd::OnDestroy();
}