|
Tim Smith wrote:
If it doesn't matter, get use to using pre-increments.
I'm thinking "STL iterators"! 
|
|
|
|
|
i would also prefer
pre-increments
if i have a option .
Vikas Amin
Embin Technology
Bombay
vikas.amin@embin.com
|
|
|
|
|
its not a matter of preference , its the need.
Every man should marry. After all, happiness is not the only thing in life.
--[v]--
|
|
|
|
|
Good day,
I have made a class that can display a bitmap with transparance (i.e. display bitmap image except for the unwanted color is not displayed). It works fine in Visual C++.
Now i'm porting the class to Embedded VisualC++(EVC3.0) however There is not CDC::SetMapMode in EVC3.0. Anybody knows what is its equivalent?
Anyway here is my code in Visual C++, class CMyBitmap derived public from CBitmap and Draw function and has DrawTransparent function... In the code here I've just comment the CDC.SetMapMode code...
Anybody have suggestion?
Thanks.
void CMyBitmap::Draw(CDC *pDC, int x, int y)
{
BITMAP bm;
GetBitmap (&bm);
CPoint size (bm.bmWidth, bm.bmHeight);
pDC->DPtoLP (&size);
CPoint org (0, 0);
pDC->DPtoLP (&org);
CDC dcMem;
dcMem.CreateCompatibleDC (pDC);
CBitmap* pOldBitmap = dcMem.SelectObject (this);
//dcMem.SetMapMode (pDC->GetMapMode ());
pDC->BitBlt (x, y, size.x, size.y, &dcMem, org.x, org.y, SRCCOPY);
dcMem.SelectObject (pOldBitmap);
}
void CMyBitmap::DrawTransparent(CDC *pDC, int x, int y, COLORREF clrTransparency)
{
BITMAP bm;
GetBitmap (&bm);
CPoint size (bm.bmWidth, bm.bmHeight);
pDC->DPtoLP (&size);
CPoint org (0, 0);
pDC->DPtoLP (&org);
CDC dcImage;
dcImage.CreateCompatibleDC (pDC);
CBitmap* pOldBitmapImage = dcImage.SelectObject (this);
//dcImage.SetMapMode (pDC->GetMapMode ());
CDC dcAnd;
dcAnd.CreateCompatibleDC (pDC);
//dcAnd.SetMapMode (pDC->GetMapMode ());
CBitmap bitmapAnd;
bitmapAnd.CreateBitmap (bm.bmWidth, bm.bmHeight, 1, 1, NULL);
CBitmap* pOldBitmapAnd = dcAnd.SelectObject (&bitmapAnd);
dcImage.SetBkColor (clrTransparency);
dcAnd.BitBlt (org.x, org.y, size.x, size.y, &dcImage, org.x, org.y,
SRCCOPY);
CDC dcXor;
dcXor.CreateCompatibleDC (pDC);
//dcXor.SetMapMode (pDC->GetMapMode ());
CBitmap bitmapXor;
bitmapXor.CreateCompatibleBitmap (&dcImage, bm.bmWidth, bm.bmHeight);
CBitmap* pOldBitmapXor = dcXor.SelectObject (&bitmapXor);
dcXor.BitBlt (org.x, org.y, size.x, size.y, &dcImage, org.x, org.y,
SRCCOPY);
dcXor.BitBlt (org.x, org.y, size.x, size.y, &dcAnd, org.x, org.y,
0x220326);
CDC dcTemp;
dcTemp.CreateCompatibleDC (pDC);
//dcTemp.SetMapMode (pDC->GetMapMode ());
CBitmap bitmapTemp;
bitmapTemp.CreateCompatibleBitmap (&dcImage, bm.bmWidth, bm.bmHeight);
CBitmap* pOldBitmapTemp = dcTemp.SelectObject (&bitmapTemp);
dcTemp.BitBlt (org.x, org.y, size.x, size.y, pDC, x, y, SRCCOPY);
dcTemp.BitBlt (org.x, org.y, size.x, size.y, &dcAnd, org.x, org.y,
SRCAND);
dcTemp.BitBlt (org.x, org.y, size.x, size.y, &dcXor, org.x, org.y,
SRCINVERT);
pDC->BitBlt (x, y, size.x, size.y, &dcTemp, org.x, org.y, SRCCOPY);
dcTemp.SelectObject (pOldBitmapTemp);
dcXor.SelectObject (pOldBitmapXor);
dcAnd.SelectObject (pOldBitmapAnd);
dcImage.SelectObject (pOldBitmapImage);
}
|
|
|
|
|
Hi for all
I would like to know what exactly are the HWND, HINSTANCE, HDC and HGLRC variables, when I use one or another and teh differences among them.
I've read the msdn but I didn't understand nothing.
Thanks for explanations
Alex Cutovoi
|
|
|
|
|
Alex Cutovoi wrote:
I would like to know what exactly are the HWND, HINSTANCE, HDC and HGLRC variables, when I use one or another and teh differences among them.
I've read the msdn but I didn't understand nothing.
What answers did you not understand a couple of days ago when you asked the question the first time?
Simple question[^]
DEBUGGING : Removing the needles from the haystack.
|
|
|
|
|
A couple of days ago the answer that send me is that the only just 32 bit variables and nothing more. I would like more explanations, like when I use one or another and this differences. That's it.
Thanks
|
|
|
|
|
Alex Cutovoi wrote:
A couple of days ago the answer that send me is that the only just 32 bit variables and nothing more. I would like more explanations, like when I use one or another and this differences. That's it.
Okay lets try this,
HWND (from memory)
All windows are assigned a handle (at run time) a unique integer that identifies them. By window I mean virtually everything that a user could interact with, edit controls, static controls, command buttons, tool bars (the object on the tool bar as well), dialog windows, the main frame of a SID / MDI app, system tray, the desktop. Etc. the list goes on.
HDC (stolen from Winprog.org[^] )
Is basically a handle to something you can draw on; it can represent the entire screen, an entire window, the client area of a window, a bitmap stored in memory, or a printer. The nice part is that you don't even need to know which one it refers to, you can use it basically the same way, which is especially handy for writing custom drawing functions which you can then use on any of these devices without changing it for each one.
HGLRC (this one I had to look up, as its part of OpenGL a graphics library)
given an HDC with an appropriate pixel format, we can make a Handle to an openGL Rendering Context (HGLRC)
See OpenGL_Windows_Setup[^]
Hope that provides a little more insite...
DEBUGGING : Removing the needles from the haystack.
-- modified at 9:58 Thursday 6th October, 2005
|
|
|
|
|
thanks peter for the support. The things are more clear now.
|
|
|
|
|
Alex Cutovoi wrote:
thanks peter for the support.
No problem Bob, glad to help.
DEBUGGING : Removing the needles from the haystack.
|
|
|
|
|
I have a class project due in 1 week. My professor won't be back until a day before it's due. Does a switch statment have to have a default? Probably a dumb question, but the way I designed the application there is really no need.
|
|
|
|
|
it does not matter. as long as ur app can run smootly 
<< >>
|
|
|
|
|
No, it's not required. It's often considered good practice to include one anyway, and if you don't expect it to ever be hit to fill it with an assert(false) or other such code to notify you, as a sanity check.
|
|
|
|
|
|
Hi
I know how to assign the window for the status of messages in Http request as:
CHttpSession *pHttpSession;
pWnd = GetDlgItem(IDC_EDIT_RESPONSE);
pHttpSession->SetStatusWnd(pWnd);
How can write these messages into a LOG file instead to a window? Any suggestion please. I have to insert all the messages from Http to the Log file.
Thanks in advance
Shailesh
|
|
|
|
|
Can u get the content of the edit control?
if so, just simpy write it to log file using CFile class
<< >>
|
|
|
|
|
no Edit control does not exist in the picture
Any more suggestion
shailesh
|
|
|
|
|
Couldn't find CHttpSession neither in the documentation nor in the MFC include/source files. I only have VS2005 in this machine; maybe this class was in VC98 and was later removed from MFC? I'll check in a VC98 installation I have in another computer but that won't be until tomorrow.
Meanwhile, I'm guessing CHttpSession is/was a class derived from CInternetSession. Am I right? If so, check your MFC source files to see what use CHttpSession makes of the window you pass in SetStatusWnd. My guess is that the window is being used in CHttpSession's implementation of OnStatusCallback (i.e., constructing a message text based on the callback parameters and then simply calling SetWindowText on the window). You might create your own class derived from CHttpSession and override OnStatusCallback in such a way that the messages are written to a log file.
Other than that, you might also create a derived CWnd class to be used as the status window. You can make that window not visible (i.e., ShowWindow(SW_HIDE); ) but trap all WM_SETTEXT messages to redirect the text to your log file.
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
hi, all
I kinda fixed the issue but still not sure what's wrong with the previous method.
it was having access violation at this point:
void CSurchrgDlg::Exit()
{
if( !m_bCanceled )
{
.....
}
CDialog::OnCancel();
}
now I used "PostMessage( cDlg->GetSafeHwnd(), WM_QUIT, 0, 0 );" replaced the exit funtion at the end of RUN. seems to work.
OR I used PostMessage(WM_QUIT); to replace CDialog::OnCancel(); would work, too.
could someone tell me what's wrong with the calling the CDialog::OnCancel();? Thank you for your time!
|
|
|
|
|
Do u mean that no thing happens when calling OnCancle() method?
if so, try to overide this ... this is just a guess
<< >>
|
|
|
|
|
thanks for your reply.
what happened was everything goes well in debug, but it crashes when it called onCancle() in release mode with access violation.
I couldn't figure out why it that, by the way, is there a outline for when to use onCancle and when for postmessage()? and for the UNICODE, what is sign for UNICODE inside of a function? thanks again!
|
|
|
|
|
valerie99 wrote:
everything goes well in debug, but it crashes when it called onCancle() in release mode
it's out of my control.... 
let me know also if u overcome this
<< >>
|
|
|
|
|
Hello, i've created a program that injects a function into the vertual memory of, another program i made. when appliction1 is finished injecting the thread into the remote process. will cause that remote process to crash, with ~the memory at <some_address> called memory at <another_address>, the memory could not be "written".~ i've put error checks and everything (but you can't put an error check on kernel32.dll).
My second program, thats being injected, crashes right when my first program calls CreateRemoteThread() on it.
I would like to know how can i make my second program not crash program not crash that other program, but still inject the thread..
could it be that the remote thread i made inside program1 is too large? i don't know? but its stressing me out!
I debuged the application2(the one thats crashing) and i saw that right after a new thread is created, theirs an *access violation* and the program crashes.
I don't understand how their could be an access violation? my injecting appliction1 has debug privalages...
Thank you.
-- modified at 9:53 Saturday 8th October, 2005
|
|
|
|
|
GreenLantern wrote:
will cause that remote process to crash, with some kind of memory problem
"some kind of memory problem" sounds a bit vague... I'd say that if you have some kind of memory problem is because what you made has some kind of error.
GreenLantern wrote:
could it be that the remote thread i made inside program1 is too large? i don't know? but its stressing me out!
Why don't you try first with something simpler/shorter so as to validate the general mechanism? Once/if you have it working, you can modify the solution to include the code you actually want.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Jose Lamas Rios wrote:
Why don't you try first with something simpler/shorter so as to validate the general mechanism?
Well i whent as simple as, the remote function just loads a kernel, but keeps on getting that ~The Instruction at "0x7ffa1307" referenced memory at "0x7ffa1307". The memory could not be "read".~ message from the system.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
