|
I'm writing a DLL that captures live video from a digital video camera. I have a buffer that contains the "image", and I need to copy this image to the clipboard as a DIB.
If I call "SetClipboardData(CF_BITMAP, hBmp)", I get the black rectangle. If I call "SetClipboardData(CF_DIB, hBmp)", I get an error that says the (bitmap?) handle is invalid.
Here's my code so far. When I paste the image into another app, all I get is a completely black rectangle. Can anyone help? Notice, there's no MFC here, and that's the way I'd like to keep it.
if (::OpenClipboard(NULL))
{
::EmptyClipboard();
RECT rc;
HBITMAP hBmp;
HDC hDC;
HDC cDC;
HWND hWnd = myParmsPtr->liveHwnd;
::GetWindowRect(hWnd, &rc);
long lStillWidth = rc.right - rc.left;
long lStillHeight = rc.bottom - rc.top;
hDC = ::GetDC(hWnd);
cDC = ::CreateCompatibleDC(hDC);
hBmp = ::CreateCompatibleBitmap(cDC,lStillWidth,lStillHeight);
HGDIOBJ oldBmp;
oldBmp = ::SelectObject(cDC, &hBmp);
PAINTSTRUCT ps;
::BeginPaint(hWnd, &ps);
int prevMode = ::SetStretchBltMode(cDC, COLORONCOLOR);
::StretchDIBits(cDC,
0, 0, lStillWidth, lStillHeight,
0, 0, lStillWidth, lStillHeight,
cb.pBuffer, (BITMAPINFO*)(&cb.bih),
DIB_RGB_COLORS, SRCCOPY);
::SetStretchBltMode(cDC, prevMode);
::EndPaint(hWnd, &ps);
if (!::SetClipboardData(CF_DIB, hBmp))
{
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, GetLastError(), 0, (LPTSTR)&lpMsgBuf, 0, NULL);
MessageBox(NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION);
LocalFree(lpMsgBuf);
MessageBeep(0);
}
::CloseClipboard();
::SelectObject(hDC, oldBmp);
::DeleteObject(hBmp);
::DeleteDC(cDC);
::DeleteDC(hDC);
}
|
|
|
|
|
You shouldn't delete hBmp. From SetClipboardData docs:
After SetClipboardData is called, the system owns the object identified by the hMem parameter
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I think I have larger problems than that. Removing the line that deletes the hBmp doesn't hve any affect on the previously stated results.
|
|
|
|
|
Do you know for sure the bitmap itself is good before it hits the clipboard ? In situations like this, I grab a screen DC and throw the image to the screen just to make sure that the problem is ( in this case ) the transfer to clipboard and not the HBITMAP itself.
I also know that I've done screen capture programs that capture a frame at a time from the window DC and build AVI's which have failed to capture video from Media Player, if that is any indication. It's almost like it's draw direct to the screen, but not to the screen DC
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Just beginning with MFC,I am trying to implement a toolbar that will appear next to a child window in MDI application. Should I be using CToolbar and where do I put the code to create the toolbar. Any help will be appreciated.
thanks
|
|
|
|
|
Put the code inside CChildFrame::OnCreateClient:
VERIFY(m_toolbar.CreateEx(
this,
TBSTYLE_FLAT,
WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC));
VERIFY(m_toolbar.LoadToolBar(IDR_YOUR_TOOLBAR));
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
The code worked but instead of having a toolbar on the top of the child window, I would like a toolbar that appears in the main window whenever a child window is open. So, in the main window, you'll have two windows: the child document and a toolbar. Thanks for the help!
|
|
|
|
|
I have a question.
I've incorporated a couple examples that I've found from CodeProject, compiled, and it seems to be working as expected EXCEPT FOR:
I want to edit cells and it appears the list control is not configured to do so. How do I set the properties for the list control so that I can edit cells?
I created the list control (CListCtrl) using the dialog wizard and have the following properties set:
Styles: View=Report, Sort=None, Edit labes (checked), No Sort Header
More Styles: Border (checked)
Extended Styles: <nothing set="">
Thanks for the help - thanks CodeProject (members) for the examples too.
Johnny
|
|
|
|
|
Look up LVN_BEGINLABELEDIT. You must handle this notification, as the default list control window proc does nothing (so no editing happens).
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
Thanks for the advice and direction.
The examples from CodeProject I used are a combination of the Text Callback example and the List Editor ("Some Text", hex value, <3rd column>).
I fixed my code to replicate the above and the only CListCtrl label edit message it traps is the LVN_ENDLABELEDIT -- a LV_DISPINFO is sent somewhere in the code.
Thanks again. I may post my "finished project" to the group as it help someone else like me.
Johnny
|
|
|
|
|
Can anyone tell me how to REMOVE the buttons from a tabctrl ? Is this even possible  ?? I've placed a WTL::CTabCtrl on my dialog with 3 pages inserted, I don't want the tab buttons at the top displayed, I will do the tab flipping in my code.
I looked into using the WTL::CPropertySheet but it won't work for my purposes ... although ... if I can't get ride of the tab buttons I may have to look at it again.
Thanks in advance for any help
Derrick Flannigan
Software Developer
|
|
|
|
|
Maybe I'm but without the tabs there's nothing left.
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
The 'tabs' are still there I just don't want the tab buttons that get displayed at the top of the control ... I know it seems odd  I'm thinking it would be the easiest way to flip between 2-3 pages (or panes) of controls contained in a groupbox ....
D
|
|
|
|
|
It sounds like you're expecting the tab control to show/hide controls when you switch tabs, but that's not how it works. All the tab control gives you is the tabs, you still have to handle switching panes/pages/whatever you have in response to the user changing tabs. So even if there were a tabless tab control, it wouldn't save you any work.
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
I think I've seen code somewhere that does this, but I need to be able to determine for a locked file what the owning process is. It would be even better if I could get a human readble representation of the process, but I'm willing to start at the beginning  . This needs to work on 98/NT/2000. Thanks for any suggestions.
|
|
|
|
|
Hi
I want to learn programming with directX
so if anyone can recommend some resources
I Know nothing about directX programming 
MR.Byte
|
|
|
|
|
try www.gamedev.net
or better http://nexe.gamedev.net
|
|
|
|
|
Any other resources !
MR.Byte
|
|
|
|
|
http://www.wazooenterprises.com is pretty good as well I've found..
|
|
|
|
|
Thanks
MR.Byte
|
|
|
|
|
I may be confusing my memory leak with a resource leak. In any case,
what is happening is that I have setup CRect’s within my dialog window
as the actual areas that I’ll be bltting to.
The program seems to work fine for awhile, however, after
executing the program 20-30 times (opening and closing the app), the
areas (CRects) that had once successfully been bltted, do not show
anything anymore, but only the default gray background. …only rebooting
solves problem. A sign of leakage somewhere?
Another difference I’ve been noticing is that I did my initialization
inside my InitDialog() function and not OnCreate(). Important? I don’t
know…
Here’s some of my initialization code:
CRect rectDialog;
GetClientRect(&rectDialog);
rectDialog.NormalizeRect();
m_rectZoom.SetRect(rectDialog.left + 250,
rectDialog.top + 50,
rectDialog.left + 700,
rectDialog.top + 500);
m_rectZoom.NormalizeRect();
m_rectHead0.SetRect(rectDialog.left + 50,
rectDialog.top + 100,
rectDialog.left + 200,
rectDialog.top + 250);
m_rectHead0.NormalizeRect();
m_rectHead0Source.SetRect(0,0,2000,2000);
m_rectHead0Source.NormalizeRect();
m_rectZoomSource.SetRect(0,0,2000,2000);
m_rectZoomSource.NormalizeRect();
pDC = this->GetDC();
m_dcHead0 = new CMemDC(pDC, m_rectHead0Source);
this->ReleaseDC(pDC);
Of course I left a lot of my code out, but hopefully this may give you
an idea of where I’m at. My OnPaint() got somwhat complicated, so I’ll
try to paraphrase…
On the first call of OnPaint() I draw an ellipse to m_dcHead0 and
StretchBlt that to my paintDC (a’la the pointer returned by BeginPaint
(&PAINTSTRUCT) ). Depending on where my mouse is clicked, I StretchBlt a
portion of m_dcHead0 to the m_dcZoom.
That’s really making a long story short. Please don’t break your back
looking over my code. I was just hoping for some quick ideas, I’d
rather not have you finish my work. Your help has been much appreciated.
-t²
>Oh - ok - I make a distiction between resource leaks and memory leaks - >perhaps what you have is a resource leak.
>
>If you are working with classes derived from CGdiObject (like CBrush, >CPen) the ~CGdiObject destructor should free the resource for you - so >when the testBrush goes out of scope, or its containing class is >destroyed, you should be ok. MFC will ASSERT in debug mode if you try >to call CreateBrush or CreatePen twice without calling DeleteObject.
>
>If you are working with handles returned from say, a call >to ::CreateBrushIndirect (not using CBrush) you must be careful to >destroy the object (after deselecting it from the DC).
>
>What is telling you that you have the leak? - I thought it was a dump >provided by the debug C runtime allocation routines - in which case the >allocation number would be the one in curly braces.
>
>Say - since this thread is getting kind of buried now, why don't you >post a bit of code (showing your SaveDC and RestoreDC calls and stuff >that you are doing in between) in a new thread - rem - use
and >
to surround your code - if its a resource leak, it may not be >obvious - I seem to recall some subtle gotchas that have appeared in >these posts - but I bet you'll get a helpful answer real quick.
|
|
|
|
|
A sign of leakage somewhere?
Sure. First thing to check: OnPaint. Are you sure your GDI objects (CPen, CBrush etc) are not selected into any device context when they are going out of scope? If MFC destructor calls ::DeleteObject, it will fails when object is selected.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I'm trying to cover my tracks and for every function that
draws to some CDC I do do a SaveDC and RestoreDC before actually
selecting any GDI Objects into it. But I'll double check to see
if something slipped by me.
Much Thx,
-t²
|
|
|
|
|
Also check device contexts being destroyed - this also applies to memory DCs.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
BeginPaint(&PAINTSTRUCT) and EndPaint(&PAINTSTRUCT) should cover
that right?
This isn't my whole OnPaint() function, but it should cover important
issues.
PAINTSTRUCT ps;
CPaintDC *paintDC;
paintDC = (CPaintDC *)this->BeginPaint(&ps);
paintDC->StretchBlt(m_rectHead0.left, m_rectHead0.top,
m_rectHead0.Width(), m_rectHead0.Height(),
m_dcHead0,
m_rectHead0Source.left, m_rectHead0Source.top,
m_rectHead0Source.Width(), m_rectHead0Source.Height(),
SRCCOPY);
this->EndPaint(&ps);
-t²
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
