|
I'm trying to get write a message-only window to receive device change notification messages for a USB device. I am using MFC, C++, and Visual Studio 2008. Everything compiles, and it runs without crashing or locking up, but the event handler is never triggered. The device of interest is installed on Windows as a virtual COM port.
My main application instantiates the class described below then waits for a character input from the keyboard polling using a while loop. It is during this wait time that I remove and insert my USB device expecting the event to get fired.
class CMessageOnlyWindow : public CWnd
{
DECLARE_DYNAMIC(CMessageOnlyWindow)
private:
DEV_BROADCAST_DEVICEINTERFACE * _pDevIF;
HDEVNOTIFY _hNotifyDev;
public:
CMessageOnlyWindow();
virtual ~CMessageOnlyWindow();
protected:
afx_msg BOOL OnDeviceChange( UINT nEventType, DWORD dwData );
private:
void RegisterNotification( void );
void UnregisterNotification( void );
protected:
DECLARE_MESSAGE_MAP()
};
For simplicity, I've removed all the cleanup and error-handling:
DEFINE_GUID(GUID_INTERFACE_CP210x, 0x993f7832, 0x6e2d, 0x4a0f, \
0xb2, 0x72, 0xe2, 0xc7, 0x8e, 0x74, 0xf9, 0x3e);
IMPLEMENT_DYNAMIC(CMessageOnlyWindow, CWnd)
CMessageOnlyWindow::CMessageOnlyWindow()
{
CString cstrWndClassName = ::AfxRegisterWndClass( NULL );
BOOL bCreated = this->CreateEx( 0, cstrWndClassName,
L"CMessageOnlyWindow", 0, 0, 0, 0, 0, HWND_MESSAGE, 0 );
this->RegisterNotification();
}
CMessageOnlyWindow::~CMessageOnlyWindow() {}
BEGIN_MESSAGE_MAP(CMessageOnlyWindow, CWnd)
ON_WM_DEVICECHANGE()
END_MESSAGE_MAP()
afx_msg BOOL CMessageOnlyWindow::OnDeviceChange( UINT nEventType, DWORD dwData )
{
switch ( nEventType )
{
case DBT_DEVICEARRIVAL:
break;
case DBT_DEVICEREMOVECOMPLETE:
break;
default:
break;
}
return TRUE;
}
void CMessageOnlyWindow::RegisterNotification(void)
{
_pDevIF = (DEV_BROADCAST_DEVICEINTERFACE *)malloc( sizeof(DEV_BROADCAST_DEVICEINTERFACE) );
memset( _pDevIF, 0, sizeof(DEV_BROADCAST_DEVICEINTERFACE) );
_pDevIF->dbcc_size = sizeof(DEV_BROADCAST_DEVICEINTERFACE);
_pDevIF->dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
_pDevIF->dbcc_classguid = GUID_INTERFACE_CP210x;
_hNotifyDev = RegisterDeviceNotification( this->m_hWnd, _pDevIF, DEVICE_NOTIFY_WINDOW_HANDLE );
}
void CMessageOnlyWindow::UnregisterNotification(void)
{
UnregisterDeviceNotification( _hNotifyDev );
}
Any thoughts or suggestions would be much appreciated. If any details are missing, let me know, and I will be glad to add them. Thanks.
Does the message-only window need to be started in a new thread, or does creating a new window automatically spin off a new thread?
ADDITIONAL INFO
Changing the type of recipient handle passed to `RegisterDeviceNotification` to `DEVICE_NOTIFY_ALL_INTERFACE_CLASSES` caused it to start working. Do you know why that would make a difference, or are there any problems, if I leave it like this?
modified on Friday, November 5, 2010 12:18 PM
|
|
|
|
|
AFAIK the window will only get messages when it is "visible" and non-minimized, which means you should show it on the desktop, at any location you like, including (-1000,-1000) to keep it out of sight.
|
|
|
|
|
Thanks, Luc. I tried specifying a location with the same lackluster results:
BOOL bCreated = this->CreateEx( 0, cstrWndClassName,
L"CMessageOnlyWindow", -1000, -1000, 100, 100, 0, HWND_MESSAGE, 0 );
|
|
|
|
|
I was thinking you had to actually show the window (hence the off-screen coordinates), howver my source code (which is C#) doesn't, and works well. I'm afraid I can't help you.
|
|
|
|
|
Hi again,
I happened to require detection of memory stick insertions (in C# again), and experimented a bit more. My conclusion is the app needs a window that is shown, non-minimized, possibly off-screen, and then overriding the wndProc yields the necessary events. So I chose "manual window position" with a bounding rectangle of (-32000,-32000,100,100) and it works well; it does not when minimized or not shown at all.
|
|
|
|
|
I've got that configuration Video capture -> Sample Grabber -> Null renderer to play video file.
I'd like to able to seek to any position in a video file to grab raw image data.
If the filter graph is stopped, then seek is performed to specific position and then run again sample grabber captures the correct image. But graph stop and run takes significant amount of time.
If the graph is already running the seeking does not position to correct location however. It is always the first frame or in some video file only after second seeking operation to the same location sample grabber returns correct frame.
m_pSeeking->SetPositions(&m_pPosition, AM_SEEKING_AbsolutePositioning, NULL, NULL);
Чесноков
|
|
|
|
|
And what about the method return value?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
There are no errors. All HRESULTS are OK.
Initially I wanted to seek to specific location in video file, then run the graph, wait for completion and get buffer.
Seeking function
<br />
m_pPosition = (1000000 * (LONGLONG)millisecond) / 100;<br />
hr = m_pSeeking->SetPositions(&m_pPosition, AM_SEEKING_AbsolutePositioning, &m_pStop, AM_SEEKING_AbsolutePositioning);<br />
if (FAILED(hr)) <br />
return -2;<br />
hr = m_pSeeking->GetCurrentPosition(&m_pPosition);<br />
if (FAILED(hr)) <br />
return -3;<br />
Grabbing function
<br />
hr = m_pMC->Run();<br />
if (FAILED(hr)) <br />
return -2; <br />
long evCode;<br />
hr = m_pEvent->WaitForCompletion(m_TimeOut, &evCode);<br />
if (FAILED(hr)) <br />
return -3;<br />
hr = m_pMC->Stop();<br />
if (FAILED(hr)) <br />
return -4;<br />
hr = m_pGrabber->GetCurrentBuffer((long *)&m_BmiHeader.biSizeImage, (long *)pFrameData);<br />
if (FAILED(hr))<br />
return -5;<br />
I used SetOneShot(TRUE); during sample grabber setup to make sure graph filter stops after single grabbing.
But that resulted in significantly slower grabbing due to filter graph run/stop operation.
I realized that it is possible to seek to any location while filter graph is already running as specified in documentation so I used SetOneShot(FALSE) and moved graph running and stopping from grabbing function.
But with SetOneShot false WaitForCompletion returns 0x80004004 if wait interval is specified or never returns with INFINITE wait period.
Is there fast seeking approach to grab raw image data with sample buffer?
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: But with SetOneShot false WaitForCompletion returns 0x80004004 if wait interval is specified or never returns with INFINITE wait period
And what is the evCode value?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
evCode = 0;
That is wierd. With SetOneShot set to TRUE filter graph does not stop as it should after sample grabber frame capture.
With SetOneShot set to FALSE WaitForCompletion never returns.
Чесноков
|
|
|
|
|
Any pointer to some good example on how to use the CTreeCtrl ?
|
|
|
|
|
|
bad answer... I've already done that and could not find just a full example of the
basic CTreeCtrl, otherwise I wouldn't ask it here, would I ?
|
|
|
|
|
The answer is actually correct.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
With smart-aleck replies like this, you'll be lucky to receive any further help in the future.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
point taken... but I did already my bit in searching the articles first...
neededless to say, giving an answer in search form is a bit pointless as it was my first try to already search the articles... hence what I'm looking for is somewhat different:
a pointer to a short/full application that does use the CTreeCtrl that is not listed in the search
results...
otherwise I'll just feel somebody thinks me to be so stupid to don't search before asking !!!
|
|
|
|
|
federico.strati wrote: otherwise I'll just feel somebody thinks me to be so stupid to don't search before asking !!!
How can we tell, in advance, how stupid are you? 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
you have just to assume what you would do in the first place, like an "I wouldn't do that,
wouldn't I?" ... 
Oh well, I just know I'll end up as always writing my own little app exploring all available options of the CTreeCtrl just for fun in learning...
grazie comunque 
|
|
|
|
|
federico.strati wrote: Oh well, I just know I'll end up as always writing my own little app exploring all available options of the CTreeCtrl just for fun in learning...
That's what I would do. Populating it with files from your computer would be a great exercise.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
federico.strati wrote: you have just to assume what you would do in the first place, like an "I wouldn't do that,
wouldn't I?" ...
As David, pointed out, I assume what would do the average poster of this forum (unless I know him very well).
federico.strati wrote: Oh well, I just know I'll end up as always writing my own little app exploring all available options of the CTreeCtrl just for fun in learning...
By chance you've just found yourself the best route.
Si figuri... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
|
federico.strati wrote: but I did already my bit in searching the articles first...
How were we to know?
federico.strati wrote: neededless to say, giving an answer in search form is a bit pointless
Unless you consider that most folks that visit the C++ forums have NOT done an initial search. They would rather spend more time creating a CP profile and typing in an incoherent question than they would by just Googling. Lazy does not begin to describe some of the ones here. Given that your profile indicates you are indeed an educated person, you probably should have prefaced your post with what you had already tried. That would help to set you apart from the others.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I cannot find a way to force an OpenFileDialog under Windows 7, Visual Studio 2010 C++ to always open the a folder of my choosing. The documentation for OPENFILENAME structure states for Windows 7 "If lpstrInitialDir has the same value as was passed the first time the application used an Open or Save As dialog box, the path most recently selected by the user is used as the initial directory."
I cannot find a way to override this - I have a set directory I always want to open to no matter what.
Of course I am always setting lpstrInitialDir to that folder. That works the first time, but as it says above, next time it opens to the last folder the user selected.
I saw a few C#, .NET flags in other posts to change this, but nothing I can find for MFC/C++.
Any ideas appreciated! TIA
|
|
|
|
|
Does it behave the same way also if you set lpstrInitialDir to NULL and pass the path in lpstrFile?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
|
|
|
|
|
lpstrInitialDir is not supported starting from Vista.
As Code-o-mat said, you can copy the folder to be initially shown in lpstrFile.
An important point to note is that the path must have a trailing back slash.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
