Board index » Visual Studio » Picture control max size?

Visual Studio329
I have a picture control that I am using as a print preview for a report.

But, the picture control seems to have a maximum size, which results in me

not being able to view all of the report. When printed, the report

(depending on what is selected) may be up to 35 or 40 pages long.



Through testing, the max size of the picture control appears to be somewhere

in the vicinity of 19500 twips. Can anyone confirm this? Right now, it

needs to be at least 150350 twips, and will need to be larger as my database

grows.



Thanks,



Darhl


-

"Darhl Thomason" <darhlt@papamurphys.nospamplease.com>wrote in message

but the picture control would only be one page at a time, right? You'd use

an array of controls to show more than 1 page on the screen and just build

the pages you need to show.





-

"Bob Butler" <noway@nospam.ever>wrote in message

print to paper, it is 35 to 40 pages long, but I was going to have it be

just one long picture control that they could scroll up and down through.



I'll have to think about doing it as an array of controls, I know it will

take some brain crunching to figure out the paging of that and don't know if

I'm up to it right now, but may be something I go to as an "upgrade"

somewhere down the road.



d





-

"Darhl Thomason" <darhlt@papamurphys.nospamplease.com>wrote in message



The maximum size of a VB Picture Box is 16383 x 16383 pixels, which on most

machines is 245745 x 245745 twips. However, an Autoredraw Picture Box

requires all of those pixels to be in a block of real memory, which of

course on most machines simply is not possible, so on most machines the

maximum size of an Autoredraw Picture Box is very much less. It is the area

that matters.



The same applies to a screen compatible memory DC and associated memory

bitmap that you might create using the equivalent API functions, so it is

not entirely a "Picture Box" problem. In fact the only way you could create

a memory image of the size you require would be to create a DIBSection

instead of a screen compatible bitmap, but a very large DIBSection would be

paged to disk and so would probably not suit your purpose.



As Bob has already said, you would be far better off placing just one page

in the Picture Box, and drawing pages one by one as the user requires. Even

if you create an array of Picture boxes (each containing one page) you will

not be able to make all of them Autoredraw (at least not at the same time)

because you will still come up against the same memory limitation (although

you can usually have slightly more "total area" in a number of small

Autoredraw Picture Boxes than you can in one large one simple because it is

easier for the system to find the required blocks of memory). But none of

this should be a problem. The user cannot see more than "one screenful at a

time" (unless he has half a dozen monitors of course!). You could perform

some little tricks to make it look as though you are scrolling through a

very long set of pages or you could opt for displaying one page at a time

(with that page scrollable or not depending on the scale at which you are

displaying it). The latter of course is much simpler to do.



Mike







-

"Darhl Thomason" <darhlt@papamurphys.nospamplease.com>wrote in message



. . . by the way, if you want a method that produces extremely good printed

output and that at the same time allows you to very easily display print

previews at any scale or magnification you wish then have a look at

metafiles. Creating your pages using such a method will mean that you will

have to forget about the VB Printer Object and instead print and draw your

pages using the various API methods, so there will be a bit of a learning

curve, but it once you've got it all going you'll see just how useful a

method it is. Once you have created a page you can draw it (or any part of

it) either to the printer or to the screen, at any scale you wish, with a

simple "one liner". If you're interested in doing it that way then have a

look at the thread entitled "Data Report: Do it the hard way :-)" which was

started in this group on 24 August.



Mike





-

As others have said, there is a definite limit to how large a PictureBox

control can be. And the size varies with OS (less for Windows98, for

example), and to a lesser extent, from computer to computer. You certainly

need to forget about the 35-40 page preview at one time; that's not going to

work out.



On my most recent project, I ran into the same thing, wanting to provide a

print preview, plus in my case, I wanted to print directly from the

PictureBox using PaintPicture to the printer. The largest PictureBox I found

I could use reliably was 1536x1887, but I had very specific aspect ratio

requirements as well as a couple other things, and wanted to allow a margin

of safety, so you could have one somewhat larger.



I disagree with Mike that this is a common limit for all graphic controls

(maybe not quite what he intimated). I found another graphic control that I

was able to have 16 times as many pixels (16 of the above size Picture Boxes

painted to a 4x4 grid on the new control), making it 6144x7548, but it can

use a half GB of memory or so. The control I use for that is GVBox.ocx from

www.jcoconsulting.com/.">www.jcoconsulting.com/. It's a bit dated (but cheap at $45), but

reads TIF and other formats, and has quite a few image manipulation

features. Problem is, it's not really designed to use the normal

print/line/etc. commands of a PictureBox, simulating a printer. I used a

PictureBox to "print" each section of my printout, then used PaintPicture to

copy each section to the GVBox, then printed using the GVBox, which worked

fine.



Anyhow, print preview and printing of high resolutions is problematic, and

I'd be very interested if anyone else comes up with any better ideas.



--

Regards,



Rick Raisley



"Darhl Thomason" <darhlt@papamurphys.nospamplease.com>wrote in message



-

Thanks everyone for their suggestions.



I think I'll probably not do an array of picture box controls, but will just

have it draw what it needs a page at a time on the same picture box. I

really won't have a ton of records to display/print. Right now there are

about 1000, and while that will grow, it will likely only be by a hundred or

so per year.



Mike, I'll probably take a look at the metafile idea you proposed for later

development, I know I can handle the printing a page at a time so it will be

a relatively quick implementation, while as you said, the metafile will take

some learning to figure out.



Keep the ideas coming, I'm open to pretty much anything.



d





-

"Rick Raisley" <heavymetal-A-T-bellsouth-D-O-T-net>wrote in message



I never said that, Rick. I think you've misunderstood what I actually did

say. I said that the memory limitation (and hence the pixel area limitation)

applies to a screen compatible memory DC and an associated screen compatible

memory bitmap, whether the bitmap is created using an Autoredraw VB Picture

Box or using the equivalent API functions (CreateCompatibleDC and

CreateCompatibleBitmap, for example). The reason I said that was to "defend"

the VB Autoredraw Picture Box (which has been given a "bad press" by many

people) by pointing out that VB itself is not the "culprit" here, but merely

the fact that a VB Picture box uses a screen compatible DC and bitmap, which

optimises drawing speed when transferring chunks of it to the display, and

hence it has to live with its limitations.



I went on to say that these limitations do NOT apply to a bitmap that is

device independent (a DIBSection, for example) because DIBSections

automatically use whatever memory is available, including pagefile memory on

the disk, and can therefore be very large indeed. The chances are that the

control to which you refer uses DIBSections or something similar. You can

easily use DIBSection in your own VB code to create very large memory

bitmaps, and you can make those memory bitmaps whatever colour depth you

require, regardless of the colour depth of the system on which your code is

running. It's just that drawing a DIBSection to the display is not quite as

fast as drawing an equivalent sized screen compatible bitmap.



In any case, for the task that the OP wants to do I would strongly suggest

the use of metafiles, as I said in my earlier response. Metafiles are ideal

for the job because they will draw themselves to the printed page using the

full available resolution of the printer and they will draw a faithful copy

of that page (or any desired portion of that page) at any desired scale to

the screen, automatically making the best use of the very limited screen

resolution (when compared to the printer resolution). I would certainly

advise against drawing stuff to the display and then copying the resulting

bitmap to the printer, either directly or indirectly, as you appear to have

suggested.



Mike











-

"Mike Williams" <mike@WhiskyAndCoke.com>wrote in message

Yes, I did, sorry. I thought the intimation was that the memory usage, or

rather limitation, was the same regardless of the control, which is not what

you said.



I'm not familiar with this method. It still isn't possible to display a much

larger PictureBox, is it?



How would one draw, and then use (display and print), very large memory

bitmaps such as that? I've printed large bitmaps by doing one section of the

total image at time in a PictureBox, then PaintPicture'ing it to the

printer. For display onscreen, usually a lower resolution is okay.



That may be beyond the learning curve I want to get into right now, too, but

thanks for the idea.



--

Regards,



Rick Raisley





-

"Rick Raisley" <heavymetal-A-T-bellsouth-D-O-T-net>wrote in message



That's okay, Rick. It is very easy to fail to make oneself clear (as I

apparently failed to do) when typing a quick response to a newsgroup

question, and it is therefore understandable that people will occasionally

misinterpret what you have said. No problem.



I'm not sure what method you are referring to Rick, but the short answer is

that a VB Autoredraw Picture Box has limitations as to how large it can be,

which are mostly system dependent, and there is no way to overcome that

limitation (other than using somehting other than a VB Autoredraw Picture

Box).



Actually I think that Vista has "upped the ante" a bit on the compatible

bitmap stuff, because in Vista I can create some extremely large VB

Autoredraw picture Boxes, very much larger than I could have created in XP.

But large memory bitmaps created as a DIBSection (or as multiple

DIBSections) can be used in all versions of Windows. Here (below) is a

rather hastily modified version of some code I was working on ages ago that

shows how to create a DIBSection and how to draw into it and how to draw the

result into a device (screen or printer). This specific example creates a

DIB of the size you mentioned in your post (6154 x 7548 pixels at 24 bit

colour depth). Don't take it as a fully finished example though. It is just

something that I was playing with. Let me know if it succeeds in creating

the 6154 x 7548 pixel DIB on your own machine, which you will know by the

fact that it draws part of the DIB into your Form. You can go a lot deeper

than tbhis of course. The example is just a "starter".



No problem. Just post again if you want to know how to handle them. They

really are very useful, especially if you are currently using bitmaps. A

typical metafile is just a very tiny fraction of the size of the bitmap that

it draws into a device.



Mike









-

"Rick Raisley" <heavymetal-A-T-bellsouth-D-O-T-net>wrote in message



That's okay, Rick. It is very easy to fail to make oneself clear (as I

apparently failed to do) when typing a quick response to a newsgroup

question, and it is therefore understandable that people will occasionally

misinterpret what you have said. No problem.



I'm not sure what method you are referring to Rick, but the short answer is

that a VB Autoredraw Picture Box has limitations as to how large it can be,

which are mostly system dependent, and there is no way to overcome that

limitation (other than using somehting other than a VB Autoredraw Picture

Box).



Actually I think that Vista has "upped the ante" a bit on the compatible

bitmap stuff, because in Vista I can create some extremely large VB

Autoredraw picture Boxes, very much larger than I could have created in XP.

But large memory bitmaps created as a DIBSection (or as multiple

DIBSections) can be used in all versions of Windows. Here (below) is a

rather hastily modified version of some code I was working on ages ago that

shows how to create a DIBSection and how to draw into it and how to draw the

result into a device (screen or printer). This specific example creates a

DIB of the size you mentioned in your post (6154 x 7548 pixels at 24 bit

colour depth). Don't take it as a fully finished example though. It is just

something that I was playing with. Let me know if it succeeds in creating

the 6154 x 7548 pixel DIB on your own machine, which you will know by the

fact that it draws part of the DIB into your Form. You can go a lot deeper

than tbhis of course. The example is just a "starter".



No problem. Just post again if you want to know how to handle them. They

really are very useful, especially if you are currently using bitmaps. A

typical metafile is just a very tiny fraction of the size of the bitmap that

it draws into a device.



Mike



Option Explicit

Private Declare Function CreateCompatibleDC Lib "gdi32" _

(ByVal hDC As Long) As Long

Private Declare Function CreateDIBSection Lib "gdi32" _

(ByVal hDC As Long, pBitmapInfo As BITMAPINFO, _

ByVal un As Long, ByVal lplpVoid As Long, _

ByVal handle As Long, ByVal dw As Long) As Long

Private Declare Function SelectObject Lib "gdi32" _

(ByVal hDC As Long, ByVal hObject As Long) As Long

Private Declare Function DeleteObject Lib "gdi32" _

(ByVal hObject As Long) As Long

Private Declare Function DeleteDC Lib "gdi32" _

(ByVal hDC As Long) As Long

Private Declare Function BitBlt Lib "gdi32" _

(ByVal hDestDC As Long, _

ByVal x As Long, ByVal y As Long, _

ByVal nWidth As Long, ByVal nHeight As Long, _

ByVal hSrcDC As Long, _

ByVal xSrc As Long, ByVal ySrc As Long, _

ByVal dwRop As Long) As Long

Private Declare Function CreatePen Lib "gdi32" _

(ByVal nPenStyle As Long, ByVal nWidth As Long, _

ByVal crColor As Long) As Long

Private Declare Function LineTo Lib "gdi32" _

(ByVal hDC As Long, ByVal x As Long, ByVal y As Long) As Long

Private Const BI_RGB = 0&

Private Const DIB_RGB_COLORS = 0 ' color table in RGBs

Private Type BITMAPINFOHEADER '40 bytes

biSize As Long

biWidth As Long

biHeight As Long

biPlanes As Integer

biBitCount As Integer

biCompression As Long

biSizeImage As Long

biXPelsPerMeter As Long

biYPelsPerMeter As Long

biClrUsed As Long

biClrImportant As Long

End Type

Private Type RGBQUAD

rgbBlue As Byte

rgbGreen As Byte

rgbRed As Byte

rgbReserved As Byte

End Type

Private Type BITMAPINFO

bmiHeader As BITMAPINFOHEADER

bmiColors As RGBQUAD

End Type

Private Const PS_SOLID = 0



Private Sub Command1_Click()

Dim pixWide As Long, pixHigh As Long, n As Long

Dim myDC As Long, myDIB As Long, oldBmp As Long

Dim pen1 As Long, penOld As Long

Dim bi24BitInfo As BITMAPINFO

pixWide = 6154

pixHigh = 7548

' set the pixel size and the colour depth of the DIB

With bi24BitInfo.bmiHeader

.biBitCount = 24 ' colour depth

.biCompression = BI_RGB

.biPlanes = 1

.biSize = Len(bi24BitInfo.bmiHeader)

.biWidth = pixWide

.biHeight = pixHigh

' Note: using a negative value for the height (pixHigh) would

' allow us to treat the DIB data as starting at the top left

' corner of the image instead of the default bottom left

' corner (so it agrees with the standard VB arrangement)

' because it reverses the vertical polarity of the "draw"

' when blitting etc the DIB. However, this is at odds with

' a standard "bottom up" DIB arrangement as held in a

' standard .bmp file and the standard "bottom up"

' arrangement that we would have if we used LoadImage

' API to load a bmp file into a DIB. Therefore it is best to

' use a normal positive value for the height and leave the

' DIB with its standard default behaviour. This means that

' if we want to have our "draw bytes into the DIB" code to

' behave in the same way as Pset and SetPixel etc would

' behave (zero is the coordinate at the top) we must make

' the conversion in our code (as we have done below

' using the yInvert variable), but in a native code compiled

' exe this little addition takes almost no time at all.

End With

myDC = CreateCompatibleDC(Me.hDC)

' Create the DIB (note: I'm not sure whether the DIB pixels are

' automatically set to black (0) by Windows when the DIB is

' created, but they seem to be. Perhaps it might be wise to

' fill the DIB with the required background colour juts in case,

' but we can leave that for the moment.

Dim z As Long

'myDIB = CreateDIBSection(myDC, bi24BitInfo, _

DIB_RGB_COLORS, ByVal 0&, ByVal 0&, ByVal 0&)

myDIB = CreateDIBSection(myDC, bi24BitInfo, _

DIB_RGB_COLORS, VarPtr(z), ByVal 0&, ByVal 0&)

If myDIB = 0 Then

DeleteDC myDC

MsgBox "Unable to create DIBSection (probably too large)"

Exit Sub

End If

'myDIB = CreateCompatibleBitmap(Me.hdc, pixWide, pixHigh)

oldBmp = SelectObject(myDC, myDIB)

pen1 = CreatePen(myDC, PS_SOLID, vbRed)

penOld = SelectObject(myDC, pen1)

' draw a diagonal line into the DIB using Pen1

LineTo myDC, pixWide, pixHigh

' Blit the DIB (or at least that part of it which will fit) into

' the Form just to show that we succeeded in creating

' a DIB and drawing into it.

BitBlt Me.hDC, 0, 0, pixWide, pixHigh, _

myDC, 0, 0, vbSrcCopy

' clear up before finishing

SelectObject myDC, oldBmp ' restore the original default single pixel bitmap

DeleteObject myDIB ' delete the DIB we created

SelectObject myDC, penOld ' restore the default pen

DeleteObject pen1 ' delete the pen we created

DeleteDC myDC ' delete the DC we created

End Sub

















-