|
Hope this helps.
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
I mean that make GetClientRect return the client rect exclude the toolbar rect.
logics
|
|
|
|
|
But your question spoke about making it transparent 
...anyway, to get the actual client area (drawing area), you can create it as a child window that covers the entire space except the toolbars etc. and put all your controls inside that child window. Then a call to GetClientRect with child window as a parameter will give you the desired rect (you can take a look at this[^]example). I am not aware of any other more sophisticated way to achieve this.
It's better to know some of the questions than all of the answers.
Pravin.
|
|
|
|
|
void CPixelView::OnDraw(CDC* pDC)
{
CPixelDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
// TODO: add draw code for native data here
{
COLORREF color[255][255],color1[255][255];
CBitmap bitmap,bitmap1;
CString file1,file2,strText;
file1.Format("C:\\1.bmp");
file2.Format("C:\\3.bmp");
CDC dcMemory,dcMemory1;
int r[255][255],R[255][255];
HBITMAP hBitmap1 = (HBITMAP)::LoadImage(NULL,file1,IMAGE_BITMAP, 0, 0,LR_LOADFROMFILE );//| LR_CREATEDIBSECTION);
HBITMAP hBitmap2 = (HBITMAP)::LoadImage(NULL,file2,IMAGE_BITMAP, 0, 0,LR_LOADFROMFILE );
// Attach the loaded image to the CBitmap object.
bitmap.Attach(hBitmap1);
bitmap1.Attach(hBitmap2);
dcMemory.CreateCompatibleDC(pDC);
dcMemory.SelectObject(&bitmap);
dcMemory1.CreateCompatibleDC(pDC);
dcMemory1.SelectObject(&bitmap1);
pDC->BitBlt(0,0,200,200,&dcMemory,0,0,SRCCOPY);
pDC->BitBlt(0,0,300,700,&dcMemory1,0,0,SRCCOPY);
//for all the pixels
for(int i=0;i<48;i++)
{
for(int j=0;j<48;j++)
{
HDC hDC = ::GetDC(this->GetSafeHwnd());
color[i][j] = ::GetPixel(hDC,i,j);
::ReleaseDC(this->GetSafeHwnd(), hDC);
r[i][j]=GetRValue(color[i][j]);
HDC hDC1 = ::GetDC(this->GetSafeHwnd());
color1[i][j] = ::GetPixel(hDC1,i,j);
::ReleaseDC(this->GetSafeHwnd(), hDC1);
R[i][j]=GetRValue(color1[i][j]);
}
}//got the pixel values
}
}
i am inserting 2 images in this ondraw command and i want to calculate the pixel of both the pictures to compare it...
can anyone tell why it is not working..complilng is done correctly but when exceute it lead to open and window with error file..
please tell asap ....
thank you..
|
|
|
|
|
kaushal kishore sharma wrote: Can anyone tell what is wromg with this code
Yes, it is badly formatted. 
BTW:
(1) Be more specific with question title.
(2) Use the code block button to surround code snippets with <pre> tags.
kaushal kishore sharma wrote: but when exceute it lead to open and window with error file..
(3) Report exactly what the error was.
kaushal kishore sharma wrote: please tell asap ....
(4) urgentz questions go automatically down to the bottom of the reply stack.
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]
|
|
|
|
|
Why dont you use GetDIBits()??
BTW Please use Code block tags for posting code.
Regards,
Sandip.
|
|
|
|
|
Hi all,
we have a SDK for our products, which was placed under the 'program files' folder up to now. Since MS changed the access rights under Vista, I get a message box asking me whether to restart Visual Studio with elevated permissions, when I open a project.
Now there are two solutions for this problem:
1. Place the SDK with all sample projects somewhere else (but where?), or
2. Set file and folder access rights (How?)
Any thoughts?
jung-kreidler
|
|
|
|
|
You can change permissions using Windows explorer.
Find the parent folder, right click, chose properties.
Go to the security tab and set the appropriate access
permissions for the apropriate users and/or groups.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yes, thank you. This is the manual way, but we would like to avoid making thinks for our customers more and more complex. I've found icacls to set permissions during setup. What's MS going to do with their SDK's. Do they place them somewhere else (and where), or do they set permissions?
jung-kreidler
|
|
|
|
|
jung-kreidler wrote: What's MS going to do with their SDK's
The latest SDK by default is installed at
C:\Program Files\Microsoft SDKs\Windows\v6.1
I'm not sure what permissions are set since SDK stuff only has to be read-only.
Setting folder permissions is the job of installers. That's why installers
generally need to run with elevated privileges.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks! That's enough info up to now.
InstallShield (installscript) seems not to be capable of setting permissions, so I wrote my own grant.exe... At the moment I'm struggling with the installscript to call my grant  .
Happy coding!
jung-kreidler
|
|
|
|
|
jung-kreidler wrote: InstallShield (installscript) seems not to be capable of setting permissions
I don't know InstallShield, but that should be a common operation.
There must be a way to do it 
You may want to post another question asking how to set folder permissions
with InstallShield. I'm pretty sure there's a bunch of people here that know
how to use it well.
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yes, there is a common solution: icacls, but you need the user name. Using 'Users' works only on english Vista. German Vista needs 'Benutzer'. French? Japanese?... So, there is no easy way to deal with the user names. I've decided to get the SID by a command line tool. ...and added the permissions stuff, too.
It works now... till the next bug 
jung-kreidler
|
|
|
|
|
Uuups, there is an easy way: Don't use the friendly user or group name, use the following: S-1-5-32-545, which addresses the user group.
Setting S-blah as user to icacls does the job:
icacls dir /grant:r *S-1-5-32-545:rights /T e.g.:
icalcs *.* /grant:r *S-1-5-32-545:F /T gives full access for all users.
This is what I've found out while getting nuts  ...
...need some coffee...
jung-kreidler
|
|
|
|
|
Hello everyone,
Not sure whether any of you met with the same issue. I am using x64 WinDbg, it is fine when debugging on x64 machine for an x64 binary -- the source code window is displayed automatically when a break point is hit.
But with x64 WinDbg, when debugging on a x64 machine for an x86 binary, the source code window is not displayed even when a break point is hit.
My questions are,
1. Is it expected behavior?
2. How to make the source window displayed when debugging x86 binary?
thanks in advance,
George
|
|
|
|
|
do you verify, that you have the proper symbols, the source and image file path set properly in windbg? Also the version of the binaries and the source code are the same...
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
I think so, could you reproduce the problem I described?
regards,
George
|
|
|
|
|
The source code window refuses to open if you don't have proper symbols set or don't have the correct version of binaries and the source. So this would more likely be the case at your end...
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Thanks AnShUmAn,
Here is my source code and related Windbg output after further experiment. My questions/comments,
1. I find if I execute command .effmach x86 at the beginning, also with correct symbol path and source path, source code window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?
3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
More details, I donot know why breaks here,
--------------------
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc int 3
0:000:x86> k
ChildEBP RetAddr
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
--------------------
Here is the whole output.
--------------------
ntdll!DbgBreakPoint:
00000000`77ef2aa0 cc int 3
0:000> .effmach x86
Effective machine: x86 compatible (x86)
0:000:x86> bp main
0:000:x86> bl
0 e x86 00000000`00411430 0001 (0001) 0:**** TestDebug1!main
0:000:x86> g
ModLoad: 00000000`77d40000 00000000`77eb3000 NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000 NOT_AN_IMAGE
ModLoad: 00000000`7d600000 00000000`7d6f0000 C:\WINDOWS\SysWOW64\ntdll32.dll
ModLoad: 00000000`77d40000 00000000`77eb3000 NOT_AN_IMAGE
ModLoad: 00000000`77c20000 00000000`77d2c000 NOT_AN_IMAGE
ModLoad: 00000000`7d4c0000 00000000`7d5f0000 C:\WINDOWS\syswow64\kernel32.dll
ModLoad: 00000000`10200000 00000000`10323000 C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_F863C71F\MSVCR90D.dll
(10e4.1f8): WOW64 breakpoint - code 4000001f (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
ntdll32!DbgBreakPoint:
00000000`7d61002d cc int 3
0:000:x86> k
ChildEBP RetAddr
002dfb48 7d649b01 ntdll32!DbgBreakPoint
002dfcac 7d637010 ntdll32!LdrpInitializeProcess+0x111c
002dfd0c 7d61e99d ntdll32!_LdrpInitialize+0xd0
00000000 00000000 ntdll32!KiUserApcDispatcher+0x25
0:000:x86> g
Breakpoint 0 hit
TestDebug1!main:
00000000`00411430 55 push ebp
0:000:x86> k
ChildEBP RetAddr
002dff68 00411a38 TestDebug1!main [d:\visual studio 2008\projects\testdebug1\testdebug1\main.cpp @ 20]
002dffb8 0041187f TestDebug1!__tmainCRTStartup+0x1a8
002dffc0 7d4e7d2a TestDebug1!mainCRTStartup+0xf
002dfff0 00000000 kernel32!BaseProcessStart+0x28
#include <iostream>
using namespace std;
int foo()
{
int b = 300;
return b;
}
int goo()
{
int a = 400;
return a;
}
int main()
{
int a = 200;
int* b = &a;
foo();
a = 400;
goo();
return 0;
}
--------------------
regards,
George
|
|
|
|
|
George_George wrote: window is showing when break point is hit in source code;
2. My further question is when should we execute command .effmach x86? As the 1st command to debug x86 binary under x64 machine/debugger as best practices or?
.effmach x86 -Use x86, amd64, ia64, or ebc processor mode
This setting influences many debugger features:
-> which processor's unwinder is used for stack tracing
-> which processor's register set is active
So, if you have multiple processors you can use this command early when you start debugging.
George_George wrote: 3. From my output, there is only one break point, but I do not know why it breaks twice, any ideas?
I will try to reproduce this once I get some time off.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
Thanks AnShUmAn,
_AnShUmAn_ wrote: I will try to reproduce this once I get some time off.
Looking forward to your reply. I do not know why for the same breakpoint setting for x64 binary, we only break once, and for x86 binary, we break twice.
regards,
George
|
|
|
|
|
Dear All
in a project I need to load a DLL more than once. (15 times at least)
This DLL is used to compress raw voice into mp3 format.
Is it possible to do this.
If there is any points which I should consider please let me know.
Regards
Monhi
|
|
|
|
|
Gut Mikh Tappe wrote: in a project I need to load a DLL more than once. (15 times at least)
Why?
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]
|
|
|
|
|
The DLL which I want to use is a mp3 compressor which only compresser the sound of a channel.
But I need to do the same job for 15 channels at least.
Thus it was neccessary to load it more than 15 times.
|
|
|
|
|
Well, if I need to use the same function in different threads, I don't load the corrensponding DLL many times... 
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]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
