|
|
If you have to ask a question like that, and word it like that, I would suggest going with whatever one has the easiest-to-use graphic library, to lessen the chance of breaking something. (I would guess that VB.Net would be the safest choice for you.)
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
McDonalds makes a Fish Filet
led mike
|
|
|
|
|
|
I still like that, I have developed it into a statement... waiting for the next appropriate VB Lounge thread to unleash it. 
led mike
|
|
|
|
|
 Some days there's a ton of 'em in a row....and when reading through your replies I think
it's like your picking them up in a bus for their one way ride to McDs! LOL
|
|
|
|
|
I'm using VC++ 6.0 and I can't figure out how to find the location of the virtual store in Vista. Everything works okay until I call a shell command to open a file. Any thoughts or suggestions would be appreciated!
Will
|
|
|
|
|
What is the "virtual store"?
|
|
|
|
|
I believe it's a folder under the %userprofile%\AppData\Local\ folder.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Can you CreateCompatibleDC/Bitmap from a printer DC?
I'm trying to write out what i print as a .BMP file
But all i get is a big black bitmap...
Any ideers?
...Steve
(_hdc below is the printer DC and has already been drawn on
fn is the .bmp filename and w,h are the size of the _hdc)
Oops - debugging output here:
fn=c:\test_00.bmp w=6400 h=4900
Canvas::SaveBmp bgn
got bitblt
got di bitmap
got bm
got bmi
got size=94080000
alloc'd n got bits
writin file
cleanup
Canvas::SaveBmp end
HDC mCnv;
if ((mCnv = ::CreateCompatibleDC (_hdc)) == NULL)
Die ("Canvas::SaveBmp CreateCompatibleDC");
HBITMAP mBmp, pBmp;
if ((mBmp = ::CreateCompatibleBitmap (_hdc, w, h)) == NULL)
Die ("Canvas::SaveBmp CreateCompatibleBitmap");
if ((pBmp = (HBITMAP) ::SelectObject (mCnv, mBmp)) == NULL)
Die ("Canvas::SaveBmp SelectObject");
if (::BitBlt (mCnv, 0, 0, w, h, _hdc, 0, 0, SRCCOPY) == FALSE)
Die ("Canvas::SaveBmp BitBlt died");
BITMAP bm;
::GetObject (mBmp, sizeof (bm), (LPVOID) & bm);
DBG(" got bm");
BITMAPINFOHEADER bmi;
MemSet (& bmi, 0, sizeof (bmi));
bmi.biSize = sizeof (bmi);
bmi.biWidth = w;
bmi.biHeight = h;
bmi.biPlanes = 1;
bmi.biBitCount = bm.bmBitsPixel;
bmi.biCompression = BI_RGB;
DBG(" got bmi");
if (! ::GetDIBits (mCnv, mBmp, 0, h, NULL, (BITMAPINFO *)(& bmi),
DIB_RGB_COLORS))
Die ("Canvas::SaveBmp GetDIBits died");
if (bmi.biSizeImage == 0)
Die ("Canvas::SaveBmp GetDIBits - no size");
sprintf(dbg," got size=%d", bmi.biSizeImage);DBG(dbg);
char *bits = new char [bmi.biSizeImage];
if (! ::GetDIBits (mCnv, mBmp, 0, h, bits, (BITMAPINFO *)(& bmi),
DIB_RGB_COLORS))
Die ("Canvas::SaveBmp GetDIBits(2) died");
DBG(" alloc'd n got bits");
BITMAPFILEHEADER bmf;
MemSet (& bmf, 0, sizeof (bmf));
bmf.bfType = ((WORD) 'B' | ('M' << 8));
bmf.bfSize = sizeof (bmf) + sizeof (bmi) + bmi.biSizeImage;
bmf.bfOffBits = sizeof (bmi);
File f;
if (f.Open (fn, "w")) {
DBG(" writin file");
f.Put (& bmf, sizeof (bmf));
f.Put (& bmi, sizeof (bmi));
f.Put (bits, bmi.biSizeImage);
f.Shut ();
}
DBG(" cleanup");
delete [] bits;
::SelectObject (mCnv, pBmp);
::DeleteObject ( mBmp);
::DeleteDC (mCnv);
DBG("Canvas::SaveBmp end");
|
|
|
|
|
Steve Hazel wrote: fn=c:\test_00.bmp w=6400 h=4900
That is quite a large bitmap. On my machine CreateCompatibleBitmap falls over and GetLastError() returns 0x00000008 - "Not enough storage is available to process this command" when I try to create large bitmaps.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thanks for checkin' into it - I appreciate that
Yep. I noticed it was biiig, but this machine handles it ok
and I only need the app to work for -me- so I can get this bitmap for my docs.
I wonder how to get around this...
I wonder how the printer driver handles this big of a bitmap?
Keeps it compressed or somethin?
I'd really like to have a full resolution bitmap (or jpg or whatever) for
my docs for this app. (which eventually will just do a regular printpreview)
Anybody got any ideers?
Thanks
...Steve
|
|
|
|
|
Steve Hazel wrote: I'd really like to have a full resolution bitmap (or jpg or whatever) for
my docs for this app. (which eventually will just do a regular printpreview)
This may be a dumb question, but if you have access to the application (and presuming it shows the image on screen), why not just print-screen and extract the necessary image using Paint?
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
When my app prints, it uses a different drawing function than when drawing in a window.
(Takes advantage of the higher printer resolution, etc)
We're talkin music printing here, by the way.
On screen, it's a regular piano roll as my docs show here:
http://shazware.com/ditty/12_tinker.html[^]
On the printout, a couple pianorolls are squashed on the page in parallel down the page (as space permits).
Ok, so how can i get that big ole bitmap... But non-black ?
The bitmap file =is= being created, (93 meg!) but it's all black.
The size can be alloc'd - width * height * 3 (bytes for RGB).
So either the BitBlt ain't workin or the GetDIBits() ain't workin...
Hmmm...
Bet it's the GetDIBits runnin outa space...
[edit] nope - the new works so why would GetDIBits need space? [/edit]
Maybe it'll work on my machine at home... I think it's got more ram
...Steve
|
|
|
|
|
Steve Hazel wrote: Anybody got any ideers?
Yeah - don't know if they are good or not though
Saving at a resolution higher than the highest source resolution is a waste of resources IMO.
Compressing with a lossy compression algorithm kinda negates the reason for saving the high res
data.
Maybe something like a metafile would be more appropriate. That way the saved data isn't bound
to a certain device.
I don't think you can count on being able to read from a printer DC. You could, however, create
a memory DC and an appropriate bitmap (DIBSection would be handy) at the desired resolution and
do all your drawing on that DC and save the DIB section as a BMP.
|
|
|
|
|
Thanks SO much for the help
Ok, I only need the bitmap file for my docs.
(read my reply to James Twine above...:/)
So what's this "metafile" thing you speak of?
And "DIBSection"?
Time to hit google which will point me back to CP...
Then read up in MSDN for a while...
Then come back here...
Unless you can gimme some shortcuts
Thanks very much,
...Steve
|
|
|
|
|
A DIB section is a DIB that can be selected into a DC like a DDB. Besides giving you direct
access to the pixel data, it's also already in DIB form which makes writing a BMP file simple.
If memory is the problem though, that method won't help
Metafiles[^]
|
|
|
|
|
I don't think memory is the problem...
The machine slows down, but mem -is- alloc'd at the last step that needs to alloc.
at char *bits = new char [sizeVarWhateverThatWas];
But the bitmap is black (all 0s)
So GetDIBits() must not be workin... It works to get the size, but not to actually set the DI bits...
Dang.
All I can come up with is to pop a dialog with the biggest custom control that'll fit on screen,
draw in it, screen print, move it (the control is the size of the full printer bmp),
printscreen, move it, printscreen
then knit all the printscreens back together with mspaint 
If you got any better ideas, i'm all ears
How does a metafile get me to a .bmp?
And my drawing code doesn't flip bits or set pixels, it does the usual graphics via HDCs...
...Steve
|
|
|
|
|
Steve Hazel wrote: So GetDIBits() must not be workin... It works to get the size, but not to actually set the DI bits...
Yeah...once you've written to a printer DC, I don't think you can read the resulting pixels
from the DC. They may not even be in RAM.
You can still always create your own dc and draw to it the same as you draw to a printer DC.
Way easier than the "draw in it, screen print, move it " method
Steve Hazel wrote: How does a metafile get me to a .bmp?
It doesn't. It gives you a metafile, a recording of all the drawing you do to a DC.
The docs explain it better than me ...
Enhanced metafiles provide true device independence. You can think of the picture stored in an
enhanced metafile as a "snapshot" of the video display taken at a particular moment.
This "snapshot" maintains its dimensions no matter where it appearson a printer, a plotter, the
desktop, or in the client area of any application.
You can use enhanced metafiles to store a picture created by using the GDI functions (including
new path and transformation functions). Because the enhanced metafile format is standardized,
pictures that are stored in this format can be copied from one application to another; and,
because the pictures are truly device independent, they are guaranteed to maintain their shape
and proportion on any output device.
That may even be what a printer device driver uses to avoid needing a huge chunk of memory for a
bitmap.
Anyway, if you need a BMP, you can create one at any time, at any size, by "playing" a metafile
on to a DC. A DIBSection could again be used to make saving easy.
|
|
|
|
|
Problem Solved !!
And, again, thanks for your help
What i do now is
- first create the memory HDC + HBITMAP,
- pass the hdc to my PrntGfx function that draws,
- THEN do the bitmapinfo/bitmapfile/GetDIBit()/file writing stuff
- (and cleanup, etc)
I have a few misc things to do like make sure the memory bitmap is WHITE like a printout and PrintGfx needs to be able to do ONE page at a time or somethin.
But there is now a WAY OUT of my hell
Thanks so much for kickin me in the right direction!!
...Steve
|
|
|
|
|
Cool That's what I was getting at using a DIBSection. With a DIBSection instead of a HBITMAP
it saves you the GetDIBits step. Otherwise it's the same.
Cheers!
Mark
|
|
|
|
|
More info on the differences between printer DCs and screen DCs...
About Printing[^]
|
|
|
|
|
(my english is not so good)
I'd like to draw a window in a game (like XFire) but I don't have an idea how to do this. I think something like a Hook would be great. Best would be a non-MFC Code (I usualy use normal Win32).
|
|
|
|
|
You say "semi transparent" but what do you mean?
1. A window that is not square?
2. A window with a glass effect ( blended with the background )?
|
|
|
|
|
semi means "half" also, so i understand it as if he asked the alpha=50%
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
