|
Device Contexts[^] 
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
They exist but if you want something nice looking, it is more complicated than you think. If you just need two axis without any mark and ticks (so just two lines) then you'll need to convert your points that you want to draw into screen position and draw the lines or points.
Furthermore you need to encaspulate all of that in a control (which add also a little bit of complexity if you never did that).
If you want something nicer (e.g. with mark on the axis and titles) then it become already 'complex': you'll need to calculate the margin to write the text, you need to calculate how many labels your gona display on the axis, ...
Of course all of this can be done (I did it, so it is far from being impossible  ) but it depends of how many time you want to spend on it.
But why do you want to write that from scratch when free solutions exist ?
|
|
|
|
|
The project that I'm working on currently is for a prof at my school, and I don't know if he wants me to be using someone else's code incase the program is commercialized someday. Thank you very much for the help everyone, I have found a couple sites about how to do this so I'm gonna give it a try.
|
|
|
|
|
Cedric, I love your chart control and use it often - can you think of an easy way that I could use it but have Dates as the X axis values rather that numeric indices?
kind regards
Lee
lee.harris@leedsth.nhs.uk
|
|
|
|
|
I already thought about adding this feature to the control but it is difficult to think about something generic, and that makes it very complicated. For example using an automatic axis which is also date/time 
|
|
|
|
|
Hi All,
I've been trying to find a way to convert the dwFileDateMS and
dwFileDateLS from the VS_FixedFileInfo structure to a human-readable
date and time format without success. Have searched the net for a day
with no clues in how to do it. Looking at the values in the debugger
of visual studio 2005, they contain valid values.
Is there a way to produce a string of the form "dd-mm-yyyy hh:mm:ss"?
Thanks in advance.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
