|
The mouse and it's position has nothing to do with MFC.
The mouse is controlled by the OS's kernel, raw input is recieved from the mouse, the kernel translates this information into something more meaningful, the kernel applies user settings, then the kernel will send a message to whichever window happens to be beneath the mouse.
Applications are only aware of what the kernel tells it about. If the mouse is not over the window, then the window recieves no messages. Take a look on MSDN for the mouse related windows messages.
|
|
|
|
|
WalderMort is correct in that you (we) do not need to know how it is done.
I am one of the few people who have created their own windowing system (before Windows existed) and the details do not matter.
Rethink your question, because this one does not provide enough information.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Hello,
I have to create an application for a system which is haing 2 touch panles as display medium. The application gets controlled from 2 touch panles by 2 users. My application have many frmaes for different purpose. So 2 topuchpanels can have different frames or same frame at a time. I am developing this application using .Net framework in windowsXP embedded.
Please suggest me how to achieve it? While developing the application what all things I have to take care?How to display the frames in different touch panels from single application?
Plz help me..
Thanks in Advance
Bil
|
|
|
|
|
There's a class, I think it's called Screen, it has a property called AllScreens. This gives you the co-ordinates of all the different monitors on the system. As far as windows is concerned, those monitors all are part of one big canvas, you get the co-ordinates, and you draw to them, and each window has different ones. So, one may be 0, 0 to 800, 600 and the other may be 800, 0 to 1600, 600.
Multi monitor stuff is pretty easy, it's not really any different from having one monitor, except for having to iterate over them to position your screens initially.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
[ VC8 on XP SP2 ]
Hey All,
I am having a problem using Bitmap::GetHBITMAP when the image contained in the Bitmap object has a transparent colour. (ie an icon or transparent gif). It seems that no matter what I try I am only able to get the transparent colour to be drawn as a shade of blue.
Maybe I am misunderstanding the documentation, but this is what it says
Syntax
Status GetHBITMAP(
const Color &colorBackground,
HBITMAP *hbmReturn
);
Parameters
colorBackground
[in] Reference to a Color object that specifies the background color.
This parameter is ignored if the bitmap is totally opaque.
hbmReturn
[out] Pointer to an HBITMAP that receives a handle to the GDI bitmap.
Return Value
If the method succeeds, it returns Ok, which is an element of the Status enumeration.
If the method fails, it returns one of the other elements of the Status enumeration.
I read that as saying that colorBackground will be the colour that is used to fill the transparent parts of the image. But for some reason it does not work that way.
Here is my code (ShowGraphic is a function that displays images):
bool CImageViewerDoc::LoadImageFile(CString FilePath)
{
Gdiplus::Bitmap Image((LPCWSTR)CT2W(FilePath));
ShowGraphic(Image, _T("%s loaded into Gdiplus::Image"), FilePath);
HBITMAP bmp;
a: COLORREF BackGround = (COLORREF)AfxGetMainWnd()->SendMessage(WMU_GETBGCOLOUR, 0, 0);
Gdiplus::Color clr;
b: clr.SetFromCOLORREF(BackGround);
if (Gdiplus::Ok == Image.GetHBITMAP(clr, &bmp))
{
c: ShowGraphic(bmp, _T("%s in HBITMAP"), FilePath);
DeleteObject(bmp);
}
}As I step through the code with various background colours this is what I get:
a: Background b: clr c: Actual colour in bitmap
RGB(0, 0, 255) 0xff0000ff RGB(0, 0, 255)
RGB(0, 255, 0) 0xff00ff00 RGB(0, 0, 0)
RGB(255, 0, 0) 0xffff0000 RGB(0, 0, 0)
RGB(192, 192, 192) 0xffc0c0c0 RGB(0, 0, 192)
RGB(236, 233, 216) 0xffece9d8 RGB(0, 0, 216)
As you can see the red and green values I supply are ignored and set to zero and only the blue value is used is the final image.
Am I using the GetHBITMAP function incorrectly? or is the function simply broken?
BTW this code works perfectly if the image does not have any transparent bits.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Hola PJ
What type of image is the source image? How are you looking at the actual colors in the HBITMAP?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Mark Salsbery wrote: What type of image is the source image?
Does not matter, all that matters is if it has transparent parts. I tried with *.ico, *.gif, *.emf, and *.wmf. All gave the exact same error.
Mark Salsbery wrote: How are you looking at the actual colors in the HBITMAP?
By drawing the resultant HBITMAP on the screen using my Image Viewer Utility[^].
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Got interrupted by g/f for lunch and a movie LOL.
Anyway that is unexpected behavior to me as well.
I've been playing with the following code. I can get two background colors, blue and black,
no matter what "clr" I use and no matter how I construct the Color object.
The source image is 320x240 GIF transparent background and a couple squiggly colored brush strokes
on it.
The first DrawImage() renders it transparently fine.
For my own reference I'd like to know what's up 
Gdiplus::Bitmap SrcBitmap(L"C:\\test.gif", FALSE);
Graphics DstGraphics(*this);
DstGraphics.DrawImage(&SrcBitmap, 50, 50, SrcBitmap.GetWidth(), SrcBitmap.GetHeight());
Gdiplus::Color clr(0x00,0xFF,0xFF,0xFF);
HBITMAP bmp;
if (Gdiplus::Ok == SrcBitmap.GetHBITMAP(clr, &bmp))
{
HDC hMemDC = ::CreateCompatibleDC(0);
HDC hDestDC = ::GetDC(*this);
HGDIOBJ hOldBitmap = ::SelectObject(hMemDC, (HGDIOBJ)bmp);
::StretchBlt(hDestDC, 0, 0, 160, 120, hMemDC, 0, 0, 320, 240, SRCCOPY);
::SelectObject(hMemDC, hOldBitmap);
::ReleaseDC(*this, hDestDC);
::DeleteDC(hMemDC);
::DeleteObject((HGDIOBJ)bmp);
}
-- modified at 21:40 Saturday 24th February, 2007
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Mark Salsbery wrote: Got interrupted by g/f for lunch and a movie LOL.
Yeah, we all got lives that pull us away from our code. I actually have to go curling now so I will not be able to look at this any further for the next couple hours.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Isn't it too cold to be curling?
This looks like a bug to me. A "Copy/Paste the line of code for the blue component twice for
the red and green components but forget to change it to access those components" kind of thing...
I'm getting the same results - only the blue component of the passed Color gets used in the
destination color.
hmm
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Mark Salsbery wrote: I'm getting the same results
Well that sucks. That either means we are both doing something wrong or GetHBITMAP is seriously flawed. As I doubt it is our fault I am going to go with the flawed theory. Thanks for looking into it. I will just have to use the work around that I made, not as handy but it does work. Basicly I create a HBITMAP of the required dimensions, fill it with the background colour, then use Gdiplus::Graphics::DrawImage to draw the image overtop of it.
bool CImageViewerDoc::LoadImageFile(CString FilePath)
{
Gdiplus::Bitmap Image((LPCWSTR)CT2W(FilePath));
ShowGraphic(Image, _T("%s loaded into Gdiplus::Image"), FilePath);
CRect Size(0, 0, Image.GetWidth(), Image.GetHeight());
pja::CBitmap Bitmap(NULL, Size.right, Size.bottom);
pja::CCompatibleDC dc;
SelectObject(dc, Bitmap);
FillRect(dc, &Size, CBrush((COLORREF)AfxGetMainWnd()->SendMessage(WMU_GETBGCOLOUR, 0, 0)));
ShowGraphic(dc, _T("memory dc after the fillrect call"));
Gdiplus::Graphics Graphics(dc);
if (Gdiplus::Ok == Graphics.DrawImage(&Image, 0, 0))
{
ShowGraphic(Bitmap, _T("%s in HBITMAP"), FilePath);
CImageData ImageData(Bitmap);
Images.push_back(ImageData);
IsImageFile = true;
return true;
}
return false;
}
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
PJ Arends wrote: As I doubt it is our fault I am going to go with the flawed theory.
I agree
Good workaround. All that code to do it kinda makes me feel like I'm not getting anything out of
GDI+ though 
I posted sample code on MS site as well just for the heck of it.
I do think it's a bug though.
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Mark Salsbery wrote: I posted sample code on MS site as well just for the heck of it.
Good idea. Can you supply a link? I would like to follow that thread as well.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
The link[^]
It hasn't generated much interest yet. Hopefully I used the most appropriate forum.
There's so many I get bored half way through the list. 
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Ok that was the wrong place to post that question
I reposted here[^]
And I thought there was alot of forums at the other one...
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
(Rex Kramer "Airplane!")
|
|
|
|
|
Ok, thanks Mark. I will watch both those links and see what kind of answers come in. Maybe it is a known bug with a hotfix already available.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Here[^] is an MSDN forum entry that talks about a blue "halo" around images and an admitted bug in the GetHBITMAP function. It is dated from May 2005 so one would figure there would be a fix by now. I will keep looking.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thanks for the link!
I would guess it's a pretty simple bug to fix - maybe it doesn't get reported.
It may not be often that we (programmers) need a HBITMAP from a Gdiplus::Bitmap.
Still, I never know - I may want to do it tomorrow and it's not going to work 
One reply so far on the MS GDI board but it wasn't useful.
Thanks for the update!
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Here[^] is some code someone did to fix the problem. Search for
"FixedGdipCreateHBITMAPFromBitmap" on the page to find it
Not necessarily useful - just FYI.
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
|
Thank you! I am SO glad someone else argued with him - I know that's where it was
going in my thread on MSDN (with the same guy!).
Anyway, did you draw any conclusion from all that?
Mark
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
Mark Salsbery wrote: Anyway, did you draw any conclusion from all that?
Yeah, that that guy is extremely stubborn
If he is right, and the result we are seeing is the expected result, then the designers of GetHBITMAP should be shot as it makes absolute no sense.
I think I will just use my workaround as all I have been able to find on the subject is some people complaining about the bug, but no one being able to point to a hotfix or easy to implement solution (hooking the Gdiplus dll is not an easy solution).
I will continue to watch these threads but I will not hold my breath waitng for a solution.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
BTW, I am using version 5.1.3102.2180 of the gdiplus.dll file.
I do not know if that makes a difference.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
My first guess would be the SetFromCOLORREF method. Try passing in a ARGB defined color, and also try using one of the other c'tors. I have a feeling that internally the color is screwed up before your call to get the bitmap.
Can you see the internal members of the color object in the debugger and verify that it is set up correctly?
|
|
|
|
|
In my original post I checked the Color object at the point labeled "b:" just before the call to GetHBITMAP() and as far as I can tell by looking in the debugger the values are set properly. It does not change after the call to GetHBITMAP() yet the colour in the final bitmap is always wrong.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
