|
jpyp wrote: It is supported by MS Visual Studio 6
Is this home grown application? What language is it written? I am assuming from your post, C++, but it could be VB as well. Who maintains it now, you other group? there are details missing from your post.
Yusuf
|
|
|
|
|
Yes it is a home grown MFC C++ application and we maintain it. I am more concern about the required level of effort to upgrade it to VC++ 2008.
Thanks!
jpyp
|
|
|
|
|
It has been awhile since I worked with MFC. this[^] should get you up with speed with Visual C++ changes. There are sections on upgrades and see any of that stuff is helpful.
Yusuf
|
|
|
|
|
Should be no problem at all. I write MFC applications and have both VS 6.0 and VS 2008 installed on my XP computer. If I open a 6.0 project with VS 2008, it gets automatically converted to the new project format.
|
|
|
|
|
jpyp wrote: ...how hard is it to migrate to this new version?
Not hard at all. The IDE can convert the project in less than a minute. You'll still need to change the code, however, to adhere to the stricter C++ rules.
If you are not using MFC, you may be able to get away with the Express Edition.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Thanks everyone for your thoughts/help. I feel more confident now going ahead with the upgrade.
jpyp
|
|
|
|
|
COLORREF Color6;
color6 = GetPixel(MemDC,Point.x,Point.y);
How do I display the value of color6 in a messagebox.
|
|
|
|
|
For example like this:
CString message;
message.Format("Red: %d, Green: %d, Blue: %d", GetRValue(Color6), GetGValue(Color6), GetBValue(Color6));
AfxMessageBox(Message, MB_OK);
But i guess that is not how you meant...so you could try this: make a simple dialog box and do something like:
class CMyColorDialog: public CDialog
{
protected:
COLORREF m_Color;
public:
CMyColorDialog(CWnd *pParent, COLORREF color);
...
afx_msg BOOL OnEraseBkgnd(CDC *pDC);
};
...
CMyColorDialog::CMyColorDialog(CWnd *pParent, COLORREF color)
:CDialog(CMyColorDialog::IDD, pParent), m_Color(color)
{
}
...
BEGIN_MESSAGE_MAP(CMyColorDialog, CDialog)
...
ON_WM_ERASEBKGND()
...
END_MESSAGE_MAP()
BOOL CMyColorRialog::OnEraseBkgnd(CDC *pDC)
{
CRect Rect;
GetClientRect(&Rect);
pDC->FillSolidRect(Rect, m_Color);
return TRUE;
}
...
COLORREF Color6;
Color6 = GetPixel(MemDC,Point.x,Point.y);
CMyColorDialog Dlg(NULL, Color6);
Dlg.DoModal();
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
The first sugetion gives me an error
CString message;
message.Format("Red: %d, Green: %d, Blue: %d", GetRValue(color6), GetGValue(color6), GetBValue(color6));
AfxMessageBox(message, MB_OK);
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
|
|
|
|
|
what do you think GetRValue, GetGValue and GetBValue returns? that should give you a clue.
Yusuf
|
|
|
|
|
Yes you are right.. I was expecting a long value however I have spent like a good chunk of time. and not sure where i am going wrong..
Hence the heading dunb question...I would first like to be able to display the value of color as a string in a messagebox to see it.
the same routine works fine in Vb and I am trying to migrate it into c++ with some other functions.
|
|
|
|
|
I'm not sure what the problem there is, since that error message you gave is too vague, does this work then:
message.Format(_T("Red: %d, Green: %d, Blue: %d"), (int)GetRValue(color6), (int)GetGValue(color6), (int)GetBValue(color6));
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thank you this works...Is there a way I can display the color6 with long values instead of RGB?
thanks
|
|
|
|
|
How do you mean that?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
ok..here...I have this function...
void HoleCard1()
{
POINT Carpt,Point1;
COLORREF color1;
Carpt.x = 513;
Carpt.y = 20;
Point1.x = 90;
Point1.y = 90;
HWND hWndActWnd;
hWndActWnd= WindowFromPoint(Carpt);
HDC ActWndDC = GetDC(hWndActWnd);
HDC MemDC = CreateCompatibleDC(ActWndDC);
BitBlt(MemDC ,0,0,1000,1000,ActWndDC,Carpt.x,Carpt.y,SRCCOPY);
color1 = GetPixel(MemDC,Point1.x,Point1.y);
}
The long value of color1 should be 1381653. How do I know this the same location in vb gives me that value and based on the usage in the last 2 weeks there has been no problems.
However if I multiply the R,G,& B from color1, which to my understanding should also give me the long value. However I get a value of 16581375
but i just want to be sure and not start making up numbers.
I have purposely posted the code just incase I have done something wrong in this function.
Thanks A million.
|
|
|
|
|
I'm not sure what you mean but...getting the colorref from the RGB components isn't done by multiplying the components. COLORREF is a 4 byte value (a long is a 8 byte value if i recall correctly), the first byte of this value (the least significant i believe) represents the red component, the second one represents green and the trird one represents blue. (It might be the other way around, am not sure but the idea is basicly the same) So:
[1 Byre Red][1 Byte Green][1 Byte Blue][1 Byte unused]
If you have the 3 components, 1 byte each you can make a colorref of them like this:
Red | (Green << 8) | (Blue << 16)
You can read about this here[^] too, it probably explains it better than i do.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Nice link to explain on the RGB and GDI. Looks like we are on the same page as to what we thinking multiplying the integer from the byte for all three will give us the long decimal value. However, can you or someone tell me if there is anything wrong with the code i have posted in my previous message.
If there isn't I could try and get the Red, Blue and Green from the Visual Basic application. I am trying to migrate an application into c++ from Visual Basic.
after reading a couple of books and some articles. I thought it would be nice to migrate and learn from my own application.
Thanks a Million for all the help. I really appreciate it.
|
|
|
|
|
I'd like to help but i still don't understand what you mean by "long value should be"... Just note that DCs you get for windows should be released using ReleaseDC[^] and memory DCs you create with CreateCompatibleDc should be destroyed with DeleteDC[^].
Note: i do not know Visual Basic, i used it with some small projects but that was ages ago...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thanks again. Short of missing the ReleaseDC() and DeleteDC(). There is nothing wrong with that small portion of the function?
Thanks Again.
|
|
|
|
|
Well, first of all, am not sure you can actually query and fiddle with a DC of a window belonging to a different thread than yours, but you probably should not anyways... (WindowFromPoint may return a window handle which does not belong to your process)
Now, you create a memory DC there and blit "onto it", but...by default, a memory DC has a 1 pixel by 1 pixel sized, 1 bits per pixel colordepth bitmap selected into it, so when you call Bitblt, you will blit onto that bitmap which is most likely not what you want. You can use GetPixel on the window DC too, you don't need to BitBlt it to some memory DC. If you DO want to create a copy, you have to use -for example- CreateCompatiblebitmap[^], create a bitmap you want to blit onto with it, select this into your memory DC using SelectObject[^], storing the original bitmap handle SelectObject returns, perform the blitting and whatever you wish to do, then select the original bitmap handle into the memory DC before you destroy it, and then also destroy the buffer if you no longer need it using DeleteObject[^].
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Thank you. I think you have hit me with something. I can see where my problem is. Yes I want the window belonging to a different thread. The WindowFromPoint is the handle i am looking for.
However some of the things you have mentioned, I beleive is what Visual Basic is all about handling the internal process.
I guess I will have to read more before i carry on and use up space here.
Any sugetions on good reading articles for GDI's or any of the functions I an using? Please advice.
Thanks A million.
|
|
|
|
|
MSDN[^]
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
How about this:
COLORREF Color6;
Color6 = GetPixel(MemDC,Point.x,Point.y);
CString str;
str.Format(_T("Color6: %x"),Color6);
::AfxMessageBox(str);
Greetings,
Jonnie
|
|
|
|
|
I am unable to get the Window Client Area Coordinates in Mouse LbuttonDown.
Here I am Converting the Coordinates to String Format.
Problem is arised at Runtime in String varible.
Can u pls Solve the Problem
|
|
|
|
|
"Here i have a variable and there i assign it something and then later somewhere it doesn't work, could you fix it for me?" - would you be able to do it? Give more details (code sniplet would be great, which does NOT mean the whole program...) if you wish for any assistance, please.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
