|
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.
|
|
|
|
|
I have a simple menu written out, it has 5 options on the main menu bar, and under the 4th menu, I have 3 menu items. I'm trying to check or uncheck the last item under the 4th menu option, it is identified as ID_ACTION_FIT.
Here is the code I have so far to check the item:
CMenu * MainMenu = GetMenu();<br />
CMenu * ActionMenu = MainMenu->GetSubMenu(3);<br />
ActionMenu->CheckMenuItem (ID_ACTION_FIT, MF_BYCOMMAND);
That code is inside the event handler for the item I'm trying to check.
I have done this before once with no problems but it's not working now. When it reaches the second line quoted and attempts to get the submenu, it fails a debug assertion. I don't have the code for GetSubMenu so I don't know what is actually being tested. The MainMenu pointer is valid. I don't know what's wrong but I think I have an error that's too obvious to see. Does anyone have an idea of what is the problem?
|
|
|
|
|
Hello,
What does the assertion dialog say? You do have the source code for CMenu::GetSubMenu() since it's MFC. You didn't delete the implementation files did you?
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
All it says is:
Debug assertion failed!
Program: C:\...path\to\program.exe
File: f:\vs70builds\9955\vc\MFCATL\ship\atlmfc\include\afxwin1.inl
Line: 875
For information on assertions...
(Press Retry to debug the application
[Abort] [Retry] [Ignore]
If I press Retry, it tells me Unhandled exception at some address. If I press Break, and go to the call stack and double click the CMenu::GetSubMenu() item on top of the stack, I get a box that says "There is no source code available for the current location." and I can see the disassembly if I want. I never deleted any implementation files but if I do have the source code for that function, VS .NET cannot find it and I don't know how to tell it where it is.
|
|
|
|
|
I added a "MainMenu->AssertValid();" after I get the main menu pointer but before I get the submenu. I get another assertion but this time I got the source code for that function. The assertion line is "ASSERT(m_hMenu == NULL || ::IsMenu(m_hNull);". m_hNull looks valid, on this particular run of the program, it is 0x0000e900 which is not NULL. I don't see how this assertion is triggered, nothing about the menu data looks suspicious.
|
|
|
|
|
The assertion in CMenu::GetSubMenu is ASSERT(::IsMenu(m_hMenu));, so the main menu handle seems to be invalid. Where (in which class and function) do you call this code?
Regards,
BB
http://spin.bartoszbien.com
|
|
|
|
|
I'm calling it in my CChildView class, in the event handler for the menu item I'm trying to toggle. When you said that, I realized that the CChildView only corresponds to the view itself, not the entire app, at least as far high as the menu exists. I changed the code to get the menu like this:
CWnd * pParent = ::AfxGetMainWnd();<br />
CMenu * MainMenu = pParent->GetMenu();<br />
CMenu * ActionMenu = MainMenu->GetSubMenu(3);
Which looks like it's picking up the right things when debugging, I won't be sure it's right until I write more code, but thanks for helping me point that out.
|
|
|
|
|
According to CMenu's documentation, "[t]he return value is undefined if CWnd is a child window". Try changing the first line to:
CMenu* MainMenu = AfxGetMainWnd()->GetMenu();
[UPDATE]: After posting this I noticed you had already found the problem. Sorry.
--
jlr
http://jlamas.blogspot.com/[^]
-- modified at 0:36 Thursday 6th October, 2005
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
