|
CPallini wrote: hence GetKeyState(VK_SHIFT) & 0x0001 should do the trick.
I dont think so. Cause the low bit indicates the key is toggled. Suppose the application is started and at that state
if( GetKeyState(VK_SHIFT) & 0x0001) - > will return false.
Then I press shift key and release it. After that
if( GetKeyState(VK_SHIFT) & 0x0001) - > will return true.
Then if i again press shift and release,
if( GetKeyState(VK_SHIFT) & 0x0001) - > will return false.
So basically, checking the 0 bit have no meaning in the case of shift key. 0th have use only in the case of toggle keys such as CAPS LOCK, NUM LOCK etc...
|
|
|
|
|
Again, make a test.
(I did).
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]
|
|
|
|
|
Thanks...
GetKeyState() works fine....
Regards
varma
|
|
|
|
|
phanindra varma wrote: Thanks...
You're welcome.
phanindra varma wrote: GetKeyState() works fine....
Sure.
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]
|
|
|
|
|
Hi,
I used following codes to Open window when double click to the Systray Icon.
No error detected when i compiled the codes. However, the codes does not working...
Any other alternate way to Open window when double click to the Systray Icon???
PLease help me???/
LRESULT CMainFrame::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
// Open window when double click to the Systray Icon
if(message == MYWM_NOTIFYICON){
switch (lParam){
case WM_LBUTTONDBLCLK:
switch (wParam) {
case IDR_TRAYICON:
ShowWindow(SW_NORMAL);
SetForegroundWindow();
SetFocus();
return TRUE;
break;
}
break;
}
}
return CFrameWnd::WindowProc(message, wParam, lParam);
}
regards
usha.
|
|
|
|
|
cb02061 wrote: switch (wParam) {
case IDR_TRAYICON:
Whats is this IDR_TRAYICON?I think that case is unnecessary. Remove it and try..
modified on Thursday, June 26, 2008 10:41 PM
|
|
|
|
|
Hi Naveen,
Not working also?? 
|
|
|
|
|
Show how you added the tray icon and the entry in the message map.
|
|
|
|
|
cb02061 wrote: No error detected when i compiled the codes.
You don't say whether you've debugged your code. Compiling cleanly is MILES away from actually doing what you've asked it to do.
Try doing:
LRESULT CMainFrame::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
if(message == MYWM_NOTIFYICON
{
ASSERT(FALSE);
switch (lParam){
Then see if
(a) message MYWM_NOTIFYICON ever arrives - if not, look at how you set up your little icon.
(b) do you then get the dblclk message?
(c) and does wParam equal your code?
The show-my-window code looks fine to me (no guarantee though!), so I'd concentrate on the wiring to detect double clicks.
Lastly, use the pre tag as described in the "read this before posting" message. The rules there are good ones. Without formatting, your code is hard to read. And you're just lucky you don;t use any <s or >s.
Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
|
|
|
|
|
Hey,
I have seen some similar discussions on this, but thought there might be an answer out there..
My problem:
When I call VirtualAlloc() with a specific memory address, say 0x60abcdef for 100000 bytes, it will fail.
A subsequent virtualQuery sometimes often indicates that it is memory mapped region. The thing is, I haven't loaded any libraries, or memory mapped any regions.
Is there a way to figure out what is in this memory, or who allocated/memory mapped it? And/or strategies for ensuring that as much of the user space virtual memory is as empty as possible?
(I know my process,ntdll and user32.dll aren't mapped to this region either)
|
|
|
|
|
felix15 wrote: The thing is, I haven't loaded any libraries, or memory mapped any regions.
When every you run an application the exe's and dll's associated with that application is loaded into the memory as a memory mapped file. So may be to that locations some dlls is mapped.If you u took the moudle window in the visual studio, you can see from which address to which address each modules are loaded. So take the module window and see if any dll falls in the memory location 0x60abcdef.
|
|
|
|
|
I don't think its the process exe as it was at 0x400000 and the only other two dlls loaded were ntdll and user32 which were in the upper 0x7's... Would a thing like an onboard video card with shared memory use a memory mapped file (or something similar) in user space ?
|
|
|
|
|
felix15 wrote: Would a thing like an onboard video card with shared memory use a memory mapped file (or something similar) in user space ?
Ofcourse no. They steal physical memory, not process memory.
Did you check your process with "Process Explorer". All the memeory mapped files of a process will be listed in it.
|
|
|
|
|
Hi,
I am using VS6 on my xp machine and am not able to my my vs 6 go to definition work.
Can any one tell me if i need to do some settings?
I already checked the generate browser info and generate debug info options.
any advice?
regards,
Ramachandraraju KK
|
|
|
|
|
Try once again by deleting your *.bsc file.
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
after closing the project 
Greetings from Germany
|
|
|
|
|
I have forget how to create a DOS Window to output some program parameters during its run.
Can anyone post this info please.
Thanks,
Andy.
|
|
|
|
|
It can be done using AllocConsole, AttachConsole etc. if that is what you mean.
« Superman »
|
|
|
|
|
From your profile: In short - Nothing seem to work out the way he wants it.
Welcome to my world. 
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
« Superman »
|
|
|
|
|
Hi all,
I've done quite a bit of reading over the last few days with regards to analyzing application crash dumps etc. I've got a customer who occasionally gets an application crash that we're unable to reproduce here. The code looks fine, we have no idea whats going on. From what I'm reading, I can have the customer send me the crash dump fro Dr. Watson, then open it up to see where the FAULT is. Understood, no problems so far. As a test, I compiled the code in release, included symbols, forced a crash and was able to see where the fault was.
My question more or less revolves around the SYMBOLS which tell you where the functions are located in the code, (PDB files). When you release a new version of your software, do you always BUILD these symbol files as part of the release configuration and tuck them away until you need them??
Our current process just bulids a simple RELEASE configuration with no map exports & no symbol building.
Questions:
1) Do you build symbols/maps with your software during the RELEASE compile?
2) Is there any disadvantage to ALWAYS creating these files during the RELEASE compile? Is anything else included in the .EXE/DLLs which may assist in the wrong people trying to debug your application?
3) I'm assuming the version of the .exe and the .pdb have to be from the same compile, correct?
Bottom line, what should I be doing as part of my RELEASE configuration to take full advantage of symbols/crash dumps etc.
Sorry, I'm a little green here with this stuff... anything you can contribute would be greatly appreciated.
Mke.
|
|
|
|
|
Mike Doner wrote: When you release a new version of your software, do you always BUILD these symbol files as part of the release configuration and tuck them away until you need them??
Yes, I always keep the symbol files for release builds. If you've got no symbol files releasing is not an option. As to where to put them the best option is to use Microsoft's Symbol Server[^]. Note that the default settings for release builds is not to generate debug information: the first thing I do when starting a new project is change this.
Mike Doner wrote: Is there any disadvantage to ALWAYS creating these files during the RELEASE compile? Is anything else included in the .EXE/DLLs which may assist in the wrong people trying to debug your application?
Not if you use PDB files (as then the symbols are stored separately). The only thing that's in the EXE is the full path to the PDB file on the build system.
Steve
|
|
|
|
|
Stephen Hewitt wrote: As to where to put them the best option is to use Microsoft's Symbol Server[^].
You mean I an upload my symbols to MS symbol server. Any pointer?
-Saurabh
|
|
|
|
|
|
Saurabh.Garg wrote: You mean I an upload my symbols to MS symbol server. Any pointer?
No, you don't upload them. The Symbol Server is a tool that comes with WinDBG for managing symbols and simplifying debugging by automatically locating the correct symbol files.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
