PasteImageFromClipboard()
Blitz3D Forums/Blitz3D Programming/PasteImageFromClipboard()
| ||
I've been using a function from the code archives (http://www.blitzbasic.com/codearcs/codearcs.php?code=1767) to paste an image from the clipboard into a Blitz image. It works very nicely most of the time. However if I do a screen grab using the Print Screen key and then use the function, it seems to just return a solid red rectangle. Can anyone suggest why this might be happening? Thanks. |
| ||
no idea. Print screening worked for me (win98se). |
| ||
Bizarre, isn't it? I know the screen grab itself has worked because I can paste the image into Photoshop. I wonder if the problem is caused by some difference between Windows 98 and XP then. In any case, thanks for the functions! |
| ||
i have a xp and print screen not work! return a red rectangle! mongia2 |
| ||
I get the same in XP. Thought I might try changing from a 32bit to 16bit desktop, but then it just MAVs. Maybe it needs options for if bpp=16 or 32? Dunno -- only gave it a quick squiz. EDIT: I think I'm right. If you change the line "If bpp=24" to "If bpp=24 Or bpp=32" you will get a wrongly coloured approximation of the clipboard (assuming its a 32 bit grab) -- or, as in my case, the top left of it! The function 'just' needs extending to cope with 32 and 16 bit formats it seems. EDIT: Okay, got 32bit looking okay now - gonna see if I can do 16bit and we should be sorted. |
| ||
Well I'm not really sure what's going on in 16bit mode, but the altered code block for tentative 32bit support looks like this...If (bpp=24 Or bpp=32);get rgb offset If bpp=24 Then multiplier=3 If bpp=32 Then multiplier=4 PokeByte btmp,0,PeekByte(btmp,offset+(x*multiplier)) ;blue PokeByte btmp,1,PeekByte(btmp,offset+(x*multiplier)+1) ;green PokeByte btmp,2,PeekByte(btmp,offset+(x*multiplier)+2) ;red Else ;get palette index, 1/4/8-bit PokeByte btmp,0,PeekInt(btmp,sizeInfo+(index*4)) PokeByte btmp,1,PeekInt(btmp,sizeInfo+(index*4)+1) PokeByte btmp,2,PeekInt(btmp,sizeInfo+(index*4)+2) EndIf Over to some other sado-masochist! |
| ||
looks like you solved it Sledge! In win98 afair there is no 16 or 32 bit image that can go on the clipboard, high-color is always 24bit. It must be different in xp. The solution for 16 bit would be to peek a short and then convert that to 3 bytes. Looking up BITMAPINFO in the Win32 help it says 16bit is 555, saying that it could be 656. You'd just have to try it. |
| ||
ok, I've figured out the 16 bit problem, hopefully! I just need someone to test it for me as I don't have xp. |
| ||
Thanks for your efforts with this Sledge and Mark. Mark, in 16 bit mode the above code does return an image but the colours are all screwed up. I know that's not a very helpful description so I'm e-mailing you an image which shows exactly what happens. |
| ||
that's pretty cool actually! Thanks for the image Joe. I suspect the problem is the bit shifting I used, as it's almost right. In the code first it gets the short/word and masks the correct bits, then if its green Shr 5, red Shr 10 so all the values are 0 to 31, 5 bits. Now to get 0 to 255 I did Shl 3 which must be the problem. Instead I think you need to multiply by 8.2 to get a constant range (31*8.2=254). I have updated the above code for this, so see if that works better now. Edit: you could also try just multiply by 8 which would give values 0 to 248. Shouldn't make much difference. |
| ||
I don't think that was the problem. The updated code produces essentially the same result. :( |
| ||
in xp it work a 32 bit! mongia i test a 16 bit! |
| ||
a 16 bit dont work perfecty! the color is a strange! mongia2 |
| ||
ok, please try the code above again. The problem was that in 16bit the rgb bit order is 565 not 555. Also, for 16/32bit images they use the BI_BITFIELDS in the biCompression field. Which stands for 3 rgb color masks in the palette, 12 bytes. So it should now work fine. |
| ||
it work! thanks! mongia2 |
| ||
Yep, works perfectly now. Thanks! |