|
Put the bitmap into a stream using CreateStreamOnHGlobal() and write the bitmap contents to it.
Then use the GDI+ Bitmap::FromStream() to load it into a bitmap object, then you can create a Graphics object on the HDC and display it using DrawImage.
Whenever you are using bitmaps from any of the major formats or trying to create, manipulate, convert a bitmap/image, GDI+ will save you loads of time and effort. You can hybrid GDI/GDI+ without much effort so you don't have to give up what you already know.
|
|
|
|
|
Thanks, but I would like to avoid to use GDI+.
Maybe LoadImage can be used with a named pipe?
|
|
|
|
|
ABuenger wrote: I would like to avoid to use GDI+.
For each his/her own.
Good day.
|
|
|
|
|
|
Thanks, here is the working code, pvImage points to the beginning ('BM') of the bitmap file.
PBYTE pBitmapData = (PBYTE) pvImage;<br />
<br />
BITMAPFILEHEADER *pBitmapFileHeader = (BITMAPFILEHEADER *) pvImage;<br />
<br />
pBitmapData += sizeof(BITMAPFILEHEADER);<br />
<br />
BITMAPINFO *pBitmapInfo = (BITMAPINFO *) pBitmapData;<br />
<br />
PBYTE pData = (PBYTE) pvImage + pBitmapFileHeader->bfOffBits;<br />
<br />
CClientDC clientDC (NULL);<br />
<br />
HBITMAP hBitmap = CreateDIBitmap (clientDC, &pBitmapInfo->bmiHeader, CBM_INIT, pData, pBitmapInfo, DIB_RGB_COLORS);<br />
<br />
pBitmap = new CBitmap;<br />
ASSERT (NULL != pBitmap);<br />
<br />
VERIFY (pBitmap->Attach (hBitmap));
|
|
|
|
|
I have a program with a thread which appears to work, but it does something strange. The thread contains an infinite loop with a particular condition to exit the loop. The program runs as a console program. The thing that is strange is that the function that creates the thread starts the thread and I can see the numbers being printed on the screen, but then it suddenly ends. I can increase the amount of numbers being printed on the screen by putting a Sleep method in the calling function that creates the thread. Why does it do this? I would expect that the thread should continue to print numbers until the condition to jump out of the while loop is reached. I don't really understand threads that well so maybe my assumptions are wrong. It seems like the function that creates the thread ends and then the thread ends as well. Is this what is happening and I need to somehow stall the calling function from ending in order for the thread to do everything that I want it to do?
Z.K.
|
|
|
|
|
Well, I got it to work the way I want, but inserting a getche() in the function that creates the thread.
Z.K.
Z.K.
|
|
|
|
|
Hi,
Does anyone know how to declare an enum type in Vs7 so that it is exposed on the COM interface in an ATL project?
It is easy to do this in VS6, you just edit the IDL file, compile and it's done. In VS7 however, the IDL file is
compiled from the ATL interface header file. I've tried declaring the enum in this header file, but when it's
compiled only the interface code appears in the generated IDL file.
Any help greatly appreciated
Ian McLauchlan
|
|
|
|
|
I need a plot curve the example? Who may provide? Extremely thank!
alantop
|
|
|
|
|
|
See Here[^] maybe it is some helpful to you
whitesky
|
|
|
|
|
Thanks two.I want the curve is free, no rule, casually for two, may draw passes
through these two curves.
alantop
|
|
|
|
|
hi friends,
in my application i have applied a bitmap image as the background of dialog but when i do this the background of static controls,radio buttons is not changing how can i get rid of this problem.
please suggest a solution for this problem.
sathish
|
|
|
|
|
Use ModifyStyleEx(0, WS_EX_TRANSPARENT); for control.
As well as you have to handle the OnCtlColor of the Dialog and Return the NULL brush for controls
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
For Static Controls
See Here[^]
(You can also do this)
For a radio button try this in OnCtlColor as A_Laxman suggests:
if(pWnd->GetDlgCtrlID()==IDC_RADIO1 || pWnd->GetDlgCtrlID()==IDC_STATIC) //IDC_RADIO1 is controlID for radio button
hbr=(HBRUSH)GetStockObject(NULL_BRUSH);
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
i my project io have one list control and one add button.one we click on the add button a new window is open to enter the item after clicking ok the item should be entered in list control.up to here my program is working
after that once we again complie we did not get the aded items.please solve my problem.
thank u,
vasu.
|
|
|
|
|
Do you mean that you are closing your application, Compiling the source code again and then again running it to see the output?
If yes you will need to save the entries of the list control somewhere in a file/ database and set those entries again in the list control, at the time you show up your dialog containing the list control.
Or else please make your problem clear if I understood it incorrectly.
and yes you can use CListCtrl::SetItemText() to set the items of the list control
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
-- modified at 8:53 Saturday 17th June, 2006
|
|
|
|
|
vasusree wrote: i my project io have one list control and one add button.one we click on the add button a new window is open to enter the item after clicking ok the item should be entered in list control.up to here my program is working
after that once we again complie we did not get the aded items.please solve my problem.
thank u,
Save the entries of the ListBox before exiting from the application some where in file/Registry
And when you run the application search for the information stored, if present load it else do regular routine..
That's ALL
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
You need to save your values(list) that when you run your program this values insert to your list
you can use registry or file or another ways.
whitesky
|
|
|
|
|
In my dialog based MFC application, I initiate windows hook as follows
HHOOK TheHook; <br />
LRESULT CALLBACK ShellProc( int nCode,<br />
WPARAM wParam,<br />
LPARAM lParam<br />
);<br />
<br />
BOOL CTmphookDlg::OnInitDialog()<br />
{<br />
..<br />
..<br />
HINSTANCE ppI = AfxGetInstanceHandle();<br />
TheHook=SetWindowsHookEx(WH_SHELL, ShellProc, ppI,0);<br />
..<br />
..<br />
}<br />
<br />
LRESULT CALLBACK ShellProc( int nCode,<br />
WPARAM wParam,<br />
LPARAM lParam<br />
)<br />
{<br />
<br />
if(nCode==HSHELL_WINDOWCREATED)<br />
{<br />
HWND hWnd = (HWND)(wParam);<br />
char szClassName[256];<br />
GetClassName(hWnd, szClassName, sizeof(szClassName));<br />
AfxMessageBox(szClassName);<br />
}<br />
<br />
return CallNextHookEx(TheHook, nCode, wParam, lParam);<br />
}
What I want is when any window (other applications) is created on the operating system.. it should flash a message telling its class name.
But this code only shows its class name initially when the dialog is being created. I tried to open notepad or other windows of other applications, it didnt flash any message.
Why is that so.? What to do to get this?
Row
|
|
|
|
|
You're calling SetWindowsHookEx with the dwThreadId set to zero and the hMod set the the .EXE module handle. If you look at the documentation you'll see the following:
dwThreadId
[in] Specifies the identifier of the thread with which the hook procedure is to be associated.
If this parameter is zero, the hook procedure is associated with all existing threads running
in the same desktop as the calling thread.
All global hook functions must be in libraries.
In short you're you're using a global hook and global hook procudures must be in a DLL (that's how it gets into the address space of another process; the other processes loads it). You're hook procudure is in the MFC .EXE.
Steve
|
|
|
|
|
|
|
WH_KEYBOARD_LL and WH_MOUSE_LL are special cases. The following is a quote from MSDN:
"However, the WH_KEYBOARD_LL hook is not injected into another process. Instead, the context switches back to the process that installed the hook and it is called in its original context. Then the context switches back to the application that generated the event."
This is why the example he gave works; it has nothing to do with his Microsoft conspiracy theories. My advice is to follow the rules and ignore that article.
Steve
|
|
|
|
|
You are right steve.
Regards,
FarPointer
Blog:http://farpointer.blogspot.com/
|
|
|
|