|
Any reason why you are trying to get a file's creation date/time from the version information?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I am in the process of writing a DLL to get version information plus
build date.
This DLL is to be used by one of my java app to keep a log of version
and build dates of all the DLLs it uses. I have written macros to
update the build version post successful build and also have written
macros to update the build date pre-build.
|
|
|
|
|
Hey guys, im trying to use the CImage::GetBits() method, and for some reason im not getting the desired return value. My code is based off many examples found on the internet and MSDN forums. Anyhow, here's the code:
(ChildView.cpp)
CImage image1;<br />
<br />
image1.destroy();<br />
...<br />
hResult = image1.Load(openDialog.GetFileName());<br />
SomeMethod(&image1)
----------
(SomeClass.cpp)
<br />
SomeMethod(CImage* importedImage)<br />
{<br />
if(!importedImage)<br />
return;<br />
<br />
BYTE* pBits = NULL;<br />
pBits = (BYTE*)importedImage->getBits();<br />
...<br />
}
----------
pBits ends up being nothing but garbage. pBits = "ýýýÿýýýÿ..."
Any ideas what I may be doing wrong?
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
pBits is garbage or the data pointed to by pBits is garbage?
Are you expecting to see text?
Those look like white pixel bytes to me (RGB(0xFF,0xFF,0xFF))
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
the data pointed to by pBits is garbage, just the same symbol repeatedly
Im not exactly expecting to see text, its pixel information, so it will be all sorts of symbols / characters. instead of the same symbol repeatedly for all of the pixels. Its CMYK pixel information, and the image has a lot of colors in it, so the data should not be the same symbol repeatedly.
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
CImage is a wrapper for a Windows DIBSection. The file may contain CMYK pixel data but once it's
loaded (CImage uses GDI+) it's in RGB format.
The data you showed still looks like RGB pixel data for white (0xff,0xff,0xff,0xff,0xff,0xff,...).
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark Salsbery wrote: The data you showed still looks like RGB pixel data for white (0xff,0xff,0xff,0xff,0xff,0xff,...).
so would this mean that somehow im not passing the loaded image to SomeMethod(CImage* importedImage), meaning the GetBits() is just a pointer to a bunch of whitespaces?
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
You're passing something.
First, make sure CImage::Load() is returning S_OK, not E_FAIL.
I'm not positive it's whitespace - I don't have the ASCII table memorized. What are the byte
values? You only showed a few - are you sure the first few pixels in the top or bottom (depending
on the orientation of the DIBSection) row aren't white or some other color?
Step into CImage::Load() in the debugger and you can see exactly how it's using GDI+ to load the
image and creating the bits pointer with CreateDIBSection().
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
CImage::Load() returns S_OK.
the color info is all the same symbol, when it shouldn't be. it would make sense to me if there were some whitespace at the beginning or the end of each scanline for alignment purposes, but the data is all the same symbol leading me to believe its not getting any of the data at all. the CImage object has all the other information(pitch, width, height, bits per pixel). So im confused why the m_pBits member would be blank.
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
What type of file is it?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
currently its a tiff file, i just need to be able to get the pointer the bit values so i can pass them on to a dither and weave function that will alter the image before it goes to print
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
I'll check out the image (or a similar one) if you want to send it - send an email from here
if you'd like.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Okay...
The images are fine.
Since the resulting bitmaps created by CImage are bottom-up oriented, the GetBits() method
is returning a pointer to the last row of data.
To adjust your pointer to the beginning of the buffer, something like this should work...
CImage image;
image.Load(_T("D:\\Source\\ImageTIF\\CMYK.tif"));
BYTE *pImageBits;
if (image.GetPitch() < 0)
pImageBits = (BYTE*)image.GetBits() + (image.GetPitch() * (image.GetHeight() - 1));
else
pImageBits = (BYTE*)image.GetBits();
...
And thanks for the images....One of them exposed a VERY old bug in my very old TIFF loader code!
Luckily I don't use it much anymore
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
well, the good news is, the < 0 formula is a big hit; however the bad news is, the value in pBits is still "ýýýÿýýýÿ...". There is some tiny stupid mistake im making somewhere, and I dont think the back of my desk can take much more kicking, or my boss can take much more of the obscenities coming from my cube.
when i try to look at the m_pBits member of image there is a memory address "0x64545(made up number)," and there is no data there either. obviously there has to be pixel information, is there anyway that it could be 0'd out or reset between load() and getbits()?
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
VonHagNDaz wrote: the bad news is, the value in pBits is still "ýýýÿýýýÿ...".
I'm seeing that as well on the CMYK.tif image...the background isn't bright white, it's RGBA
0xFD,0xFD,0xFD,0xFF. If I copy the pImageBits pointer from my sample code to a debug/memory
window, I have to scroll down a ways before the color changes - the bottom of that image is mostly
background and since the image is flipped vertically I expect that.
Using the TINY.tif image, if I copy the pImageBits pointer from my sample code to a debug/memory window, I see the first three pixels as "4c ae f2 ff ec 77 2f ff ec 77 2f ff..."
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
If you don't trust that the bits pointer is pointing to valid data, try this anywhere in your code
CImage image;
image.Load(_T("...\\CMYK.tif"));
BYTE *pImageBits;
if (image.GetPitch() < 0)
pImageBits = (BYTE*)image.GetBits() + (image.GetPitch() * (image.GetHeight() - 1));
else
pImageBits = (BYTE*)image.GetBits();
HDC hdc = ::GetDC(0);
image.Draw(hdc, 0, 0, image.GetWidth(), image.GetHeight());
::ReleaseDC(0, hdc);
Also remember for CMYK.tif, the bits pointer is pointing to an array of 3173868 bytes!
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
alright, since the image appeared in the top left of the screen it means that i am getting valid data. if thats the case, then after wasting a good 5 - 6 hours of your time, i need to be looking into my image processing code to find out why its not altering the data as its supposed to.
------------------------------
I win because I have the most fun in life...
|
|
|
|
|
Any image I get that breaks my TIFF loader code is worth it! I tried to make it as robust
as possible (it was way before GDI+ existed). These days I use GDI+
VonHagNDaz wrote: i need to be looking into my image processing code to find out why its not altering the data as its supposed to.
Remember the format in the array, taken as bytes, is (4 bytes each pixel) BGRA BGRA BGRA BGRA...
If your processing code is expecting CMYK or RGB there will be problems
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Forgot to mention....the resulting CImage pixel bits are 32-bit RGBA format in case your image
processing code isn't prepared to deal with that
Mark
-- modified at 14:52 Tuesday 29th May, 2007
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi everybody.
I´m trying to write in the Edit Box and its impossible to do it.
Selecting the edit box by clicking on it and then writing does not work. To write on it what I must do is reach the Edit Box by pressing tab key (check that proyect y uploaded in Megaupload to get an example of what is happening to me...)
Can somebody tell me what am I doing wrong?
http://www.megaupload.com/?d=K43YK4CM
Thanks
|
|
|
|
|
I have a clue.
When I set the focus on the edit box like this:
SendDlgItemMessage(IDC_EDIT,WM_SETFOCUS);
I cannot write. I took off that line and now I can write with no problem.
Anyway, I need the focus on that control when the dialog opens...
Lets follow...
|
|
|
|
|
garfield185 wrote: SendDlgItemMessage(IDC_EDIT,WM_SETFOCUS);
Have you tried SetFocus() instead?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
SetFocus does not work...
The only way to put the focus was that line, but if I use the SendDlgItemMessage I cannot write!! What a dilemma...
|
|
|
|
|
Hi All,
Can somebody tell me,how to replace a menu item with Image.
Thanks in advance.
Appu..
"My blood group is not B+.But I have it my blood"
|
|
|
|
|
Did you search on the codeproject or did you see Menu section?
|
|
|
|