"Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
news:euNK4RnmJHA.4448@TK2MSFTNGP05.phx.gbl...
> I've just come across what appears to be a very interesting little bug in
> the VB Pset method when drawing to either a Form or PictureBox (Autoredraw
=
> False). At first I thought it might be just something to do with VB
itself,
> but the bug also appears to exists in the GDI SetPixel function, which of
> course the VB Pset method uses.
>
> I don't normally set pixels individually on bitmaps and when I do I
usually
> use much faster methods than SetPixel so it is probably quite some time
> since I have used Pset or SetPixel and I don't therefore know how long the
> bug has existed on my system. I'm sure that if it was a long time I would
> have come across it before though, so I expect it is something new,
perhaps
> something to do with Vista or one of its updates, although it could of
> course be a hardware problem on my own system that I've not noticed
before.
>
> The bug causes the pixel to fail to be drawn for certain values of X
> coordinate (pixels) but not for others. A quick test seems to indicate
that
> it fails to be drawn whenever bit 8 of X is set. For example, X values of
0
> to &HFF, &H200 to &H2FF and &H400 to &H4FF work fine but X values of &H100
> to &H1FF and &H300 to &H3FF do not. For example, if I attempt to use
> SetPixel (or the GDI Pset function) to draw a horizontal line on a
maximized
> Form I get a "dashed" line where the width of the individual lines and
> spaces is 256 pixels.
>
> The problem does not exist on an Autoredraw Form or PictureBox, and
neither
> does it exists for any values of the Y coordinate whether Autoredraw is on
> or not. It is just non Autoredraw and X coordinates that seem to have the
> problem. This is such an unusual thing that it would almost certainly have
> been noticed by lots of other people had it been in existence for any
length
> of time, so I'm beginning to think that it might be just my own particular
> combination of hardware and software and drivers that is causing the
> problem. I'm currently using Vista Home Edition with Service Pack 1 and
> which is regularly updated on a Intel Core2 Quad Q6600 processor and an
ATI
> Radeon HD 4850 graphics card. I'm using VB6 with Service Pack 6 installed.
>
> There is some simple test code below which, on my system, produces the
fault
> I have described. Just paste the code into a VB Form containing a Command
> Button and run the program and click the button. I really would appreciate
> it if anyone here would be prepared to try it on their own system and
report
> the result, including details of the system and of which VB ServicePack is
> in use. On my system both the blue and the red horizontal lines are
"dashed
> lines" with 256 pixel wide dashes and spaces, instead of the continuous
> horizontal lines that I was expecting.
>
> The code is so straight forward that I can't believe I've done something
> wrong myself, although I am getting a bit long in the tooth these days and
> my brain is not quite as agile as it used to be so it is always possible
> that I've slipped up! If anyone notices a problem with my code then I
would
> appreciate it if you would let me know.
>
> p.s. I've just tested the same code on my laptop (very different processor
> and graphics subsystem than my main machine) and I get the same problem
> there. The only similarities between the two machines are the OS (one uses
> Vista Home and the other uses Vista Business) and the VB Service Pack
(both
> using SP6).
>
> Mike
>
> Option Explicit
> Private Declare Function SetPixel Lib "gdi32" _
>   (ByVal hdc As Long, _
>   ByVal x As Long, ByVal y As Long, _
>   ByVal crColor As Long) As Long
>
> Private Sub Form_Load()
> Me.WindowState = vbMaximized
> Me.AutoRedraw = False
> Me.ScaleMode = vbPixels
> End Sub
>
> Private Sub Command1_Click()
> Dim x As Long
> For x = 0 To Me.ScaleWidth
>   Me.PSet (x, 10), vbBlue
>   SetPixel Me.hdc, x, 20, vbRed
> Next x
> End Sub

"Michael" <w**@where.com> skrev i meddelandet
news:eqfhqbnmJHA.1172@TK2MSFTNGP05.phx.gbl...
>
> "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
> news:euNK4RnmJHA.4448@TK2MSFTNGP05.phx.gbl...
>> I've just come across what appears to be a very interesting little bug in
>> the VB Pset method when drawing to either a Form or PictureBox
>> (Autoredraw
> =
>> False). At first I thought it might be just something to do with VB
> itself,
>> but the bug also appears to exists in the GDI SetPixel function, which of
>> course the VB Pset method uses.
>>
>> I don't normally set pixels individually on bitmaps and when I do I
> usually
>> use much faster methods than SetPixel so it is probably quite some time
>> since I have used Pset or SetPixel and I don't therefore know how long
>> the
>> bug has existed on my system. I'm sure that if it was a long time I would
>> have come across it before though, so I expect it is something new,
> perhaps
>> something to do with Vista or one of its updates, although it could of
>> course be a hardware problem on my own system that I've not noticed
> before.
>>
>> The bug causes the pixel to fail to be drawn for certain values of X
>> coordinate (pixels) but not for others. A quick test seems to indicate
> that
>> it fails to be drawn whenever bit 8 of X is set. For example, X values of
> 0
>> to &HFF, &H200 to &H2FF and &H400 to &H4FF work fine but X values of
>> &H100
>> to &H1FF and &H300 to &H3FF do not. For example, if I attempt to use
>> SetPixel (or the GDI Pset function) to draw a horizontal line on a
> maximized
>> Form I get a "dashed" line where the width of the individual lines and
>> spaces is 256 pixels.
>>
>> The problem does not exist on an Autoredraw Form or PictureBox, and
> neither
>> does it exists for any values of the Y coordinate whether Autoredraw is
>> on
>> or not. It is just non Autoredraw and X coordinates that seem to have the
>> problem. This is such an unusual thing that it would almost certainly
>> have
>> been noticed by lots of other people had it been in existence for any
> length
>> of time, so I'm beginning to think that it might be just my own
>> particular
>> combination of hardware and software and drivers that is causing the
>> problem. I'm currently using Vista Home Edition with Service Pack 1 and
>> which is regularly updated on a Intel Core2 Quad Q6600 processor and an
> ATI
>> Radeon HD 4850 graphics card. I'm using VB6 with Service Pack 6
>> installed.
>>
>> There is some simple test code below which, on my system, produces the
> fault
>> I have described. Just paste the code into a VB Form containing a Command
>> Button and run the program and click the button. I really would
>> appreciate
>> it if anyone here would be prepared to try it on their own system and
> report
>> the result, including details of the system and of which VB ServicePack
>> is
>> in use. On my system both the blue and the red horizontal lines are
> "dashed
>> lines" with 256 pixel wide dashes and spaces, instead of the continuous
>> horizontal lines that I was expecting.
>>
>> The code is so straight forward that I can't believe I've done something
>> wrong myself, although I am getting a bit long in the tooth these days
>> and
>> my brain is not quite as agile as it used to be so it is always possible
>> that I've slipped up! If anyone notices a problem with my code then I
> would
>> appreciate it if you would let me know.
>>
>> p.s. I've just tested the same code on my laptop (very different
>> processor
>> and graphics subsystem than my main machine) and I get the same problem
>> there. The only similarities between the two machines are the OS (one
>> uses
>> Vista Home and the other uses Vista Business) and the VB Service Pack
> (both
>> using SP6).
>>
>> Mike
>>
>> Option Explicit
>> Private Declare Function SetPixel Lib "gdi32" _
>>   (ByVal hdc As Long, _
>>   ByVal x As Long, ByVal y As Long, _
>>   ByVal crColor As Long) As Long
>>
>> Private Sub Form_Load()
>> Me.WindowState = vbMaximized
>> Me.AutoRedraw = False
>> Me.ScaleMode = vbPixels
>> End Sub
>>
>> Private Sub Command1_Click()
>> Dim x As Long
>> For x = 0 To Me.ScaleWidth
>>   Me.PSet (x, 10), vbBlue
>>   SetPixel Me.hdc, x, 20, vbRed
>> Next x
>> End Sub
>
>
> Windows2000 SP4
> VB6 SP5
> Matrox G450/Athlon3200+/Abit AN7
>
> Solid lines - no dashing'
>
> Michael
>
>

"Henning" <computer_h***@coldmail.com> wrote in message
news:49aab002$0$16216$57c3e1d3@news3.bahnhof.se...
> XP Pro SP2
> VB6 SP5
> AMD 4800 DualCore
> MSI MB
>
> Two solid lines.
>
> /Henning
>
> "Michael" <w**@where.com> skrev i meddelandet
> news:eqfhqbnmJHA.1172@TK2MSFTNGP05.phx.gbl...
>>
>> "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
>> news:euNK4RnmJHA.4448@TK2MSFTNGP05.phx.gbl...
>>> I've just come across what appears to be a very interesting little bug
>>> in
>>> the VB Pset method when drawing to either a Form or PictureBox
>>> (Autoredraw
>> =
>>> False). At first I thought it might be just something to do with VB
>> itself,
>>> but the bug also appears to exists in the GDI SetPixel function, which
>>> of
>>> course the VB Pset method uses.
>>>
>>> I don't normally set pixels individually on bitmaps and when I do I
>> usually
>>> use much faster methods than SetPixel so it is probably quite some time
>>> since I have used Pset or SetPixel and I don't therefore know how long
>>> the
>>> bug has existed on my system. I'm sure that if it was a long time I
>>> would
>>> have come across it before though, so I expect it is something new,
>> perhaps
>>> something to do with Vista or one of its updates, although it could of
>>> course be a hardware problem on my own system that I've not noticed
>> before.
>>>
>>> The bug causes the pixel to fail to be drawn for certain values of X
>>> coordinate (pixels) but not for others. A quick test seems to indicate
>> that
>>> it fails to be drawn whenever bit 8 of X is set. For example, X values
>>> of
>> 0
>>> to &HFF, &H200 to &H2FF and &H400 to &H4FF work fine but X values of
>>> &H100
>>> to &H1FF and &H300 to &H3FF do not. For example, if I attempt to use
>>> SetPixel (or the GDI Pset function) to draw a horizontal line on a
>> maximized
>>> Form I get a "dashed" line where the width of the individual lines and
>>> spaces is 256 pixels.
>>>
>>> The problem does not exist on an Autoredraw Form or PictureBox, and
>> neither
>>> does it exists for any values of the Y coordinate whether Autoredraw is
>>> on
>>> or not. It is just non Autoredraw and X coordinates that seem to have
>>> the
>>> problem. This is such an unusual thing that it would almost certainly
>>> have
>>> been noticed by lots of other people had it been in existence for any
>> length
>>> of time, so I'm beginning to think that it might be just my own
>>> particular
>>> combination of hardware and software and drivers that is causing the
>>> problem. I'm currently using Vista Home Edition with Service Pack 1 and
>>> which is regularly updated on a Intel Core2 Quad Q6600 processor and an
>> ATI
>>> Radeon HD 4850 graphics card. I'm using VB6 with Service Pack 6
>>> installed.
>>>
>>> There is some simple test code below which, on my system, produces the
>> fault
>>> I have described. Just paste the code into a VB Form containing a
>>> Command
>>> Button and run the program and click the button. I really would
>>> appreciate
>>> it if anyone here would be prepared to try it on their own system and
>> report
>>> the result, including details of the system and of which VB ServicePack
>>> is
>>> in use. On my system both the blue and the red horizontal lines are
>> "dashed
>>> lines" with 256 pixel wide dashes and spaces, instead of the continuous
>>> horizontal lines that I was expecting.
>>>
>>> The code is so straight forward that I can't believe I've done something
>>> wrong myself, although I am getting a bit long in the tooth these days
>>> and
>>> my brain is not quite as agile as it used to be so it is always possible
>>> that I've slipped up! If anyone notices a problem with my code then I
>> would
>>> appreciate it if you would let me know.
>>>
>>> p.s. I've just tested the same code on my laptop (very different
>>> processor
>>> and graphics subsystem than my main machine) and I get the same problem
>>> there. The only similarities between the two machines are the OS (one
>>> uses
>>> Vista Home and the other uses Vista Business) and the VB Service Pack
>> (both
>>> using SP6).
>>>
>>> Mike
>>>
>>> Option Explicit
>>> Private Declare Function SetPixel Lib "gdi32" _
>>>   (ByVal hdc As Long, _
>>>   ByVal x As Long, ByVal y As Long, _
>>>   ByVal crColor As Long) As Long
>>>
>>> Private Sub Form_Load()
>>> Me.WindowState = vbMaximized
>>> Me.AutoRedraw = False
>>> Me.ScaleMode = vbPixels
>>> End Sub
>>>
>>> Private Sub Command1_Click()
>>> Dim x As Long
>>> For x = 0 To Me.ScaleWidth
>>>   Me.PSet (x, 10), vbBlue
>>>   SetPixel Me.hdc, x, 20, vbRed
>>> Next x
>>> End Sub
>>
>>
>> Windows2000 SP4
>> VB6 SP5
>> Matrox G450/Athlon3200+/Abit AN7
>>
>> Solid lines - no dashing'
>>
>> Michael
>>
>>
>
>

> I've just come across what appears to be a very interesting little bug
> in the VB Pset method when drawing to either a Form or PictureBox
> (Autoredraw = False). At first I thought it might be just something to
> do with VB itself, but the bug also appears to exists in the GDI
> SetPixel function, which of course the VB Pset method uses.
>
> I don't normally set pixels individually on bitmaps and when I do I
> usually use much faster methods than SetPixel so it is probably quite
> some time since I have used Pset or SetPixel and I don't therefore
> know how long the bug has existed on my system. I'm sure that if it
> was a long time I would have come across it before though, so I expect
> it is something new, perhaps something to do with Vista or one of its
> updates, although it could of course be a hardware problem on my own
> system that I've not noticed before.
>
> The bug causes the pixel to fail to be drawn for certain values of X
> coordinate (pixels) but not for others. A quick test seems to indicate
> that it fails to be drawn whenever bit 8 of X is set. For example, X
> values of 0 to &HFF, &H200 to &H2FF and &H400 to &H4FF work fine but X
> values of &H100 to &H1FF and &H300 to &H3FF do not. For example, if I
> attempt to use SetPixel (or the GDI Pset function) to draw a
> horizontal line on a maximized Form I get a "dashed" line where the
> width of the individual lines and spaces is 256 pixels.
>
> The problem does not exist on an Autoredraw Form or PictureBox, and
> neither does it exists for any values of the Y coordinate whether
> Autoredraw is on or not. It is just non Autoredraw and X coordinates
> that seem to have the problem. This is such an unusual thing that it
> would almost certainly have been noticed by lots of other people had
> it been in existence for any length of time, so I'm beginning to think
> that it might be just my own particular combination of hardware and
> software and drivers that is causing the problem. I'm currently using
> Vista Home Edition with Service Pack 1 and which is regularly updated
> on a Intel Core2 Quad Q6600 processor and an ATI Radeon HD 4850
> graphics card. I'm using VB6 with Service Pack 6 installed.
>
> There is some simple test code below which, on my system, produces the
> fault I have described. Just paste the code into a VB Form containing
> a Command Button and run the program and click the button. I really
> would appreciate it if anyone here would be prepared to try it on
> their own system and report the result, including details of the
> system and of which VB ServicePack is in use. On my system both the
> blue and the red horizontal lines are "dashed lines" with 256 pixel
> wide dashes and spaces, instead of the continuous horizontal lines
> that I was expecting.
>
> The code is so straight forward that I can't believe I've done
> something wrong myself, although I am getting a bit long in the tooth
> these days and my brain is not quite as agile as it used to be so it
> is always possible that I've slipped up! If anyone notices a problem
> with my code then I would appreciate it if you would let me know.
>
> p.s. I've just tested the same code on my laptop (very different
> processor and graphics subsystem than my main machine) and I get the
> same problem there. The only similarities between the two machines are
> the OS (one uses Vista Home and the other uses Vista Business) and the
> VB Service Pack (both using SP6).
>
> Mike
>
> Option Explicit
> Private Declare Function SetPixel Lib "gdi32" _
>   (ByVal hdc As Long, _
>   ByVal x As Long, ByVal y As Long, _
>   ByVal crColor As Long) As Long
>
> Private Sub Form_Load()
> Me.WindowState = vbMaximized
> Me.AutoRedraw = False
> Me.ScaleMode = vbPixels
> End Sub
>
> Private Sub Command1_Click()
> Dim x As Long
> For x = 0 To Me.ScaleWidth
>   Me.PSet (x, 10), vbBlue
>   SetPixel Me.hdc, x, 20, vbRed
> Next x
> End Sub
>
>
>
>

"Mike Williams" wrote:

> I've just come across what appears to be a very interesting little bug in
> the VB Pset method when drawing to either a Form or PictureBox (Autoredraw =
> False). At first I thought it might be just something to do with VB itself,
> but the bug also appears to exists in the GDI SetPixel function, which of
> course the VB Pset method uses.
>
> I don't normally set pixels individually on bitmaps and when I do I usually
> use much faster methods than SetPixel so it is probably quite some time
> since I have used Pset or SetPixel and I don't therefore know how long the
> bug has existed on my system. I'm sure that if it was a long time I would
> have come across it before though, so I expect it is something new, perhaps
> something to do with Vista or one of its updates, although it could of
> course be a hardware problem on my own system that I've not noticed before.
>
> The bug causes the pixel to fail to be drawn for certain values of X
> coordinate (pixels) but not for others. A quick test seems to indicate that
> it fails to be drawn whenever bit 8 of X is set. For example, X values of 0
> to &HFF, &H200 to &H2FF and &H400 to &H4FF work fine but X values of &H100
> to &H1FF and &H300 to &H3FF do not. For example, if I attempt to use
> SetPixel (or the GDI Pset function) to draw a horizontal line on a maximized
> Form I get a "dashed" line where the width of the individual lines and
> spaces is 256 pixels.
>
> The problem does not exist on an Autoredraw Form or PictureBox, and neither
> does it exists for any values of the Y coordinate whether Autoredraw is on
> or not. It is just non Autoredraw and X coordinates that seem to have the
> problem. This is such an unusual thing that it would almost certainly have
> been noticed by lots of other people had it been in existence for any length
> of time, so I'm beginning to think that it might be just my own particular
> combination of hardware and software and drivers that is causing the
> problem. I'm currently using Vista Home Edition with Service Pack 1 and
> which is regularly updated on a Intel Core2 Quad Q6600 processor and an ATI
> Radeon HD 4850 graphics card. I'm using VB6 with Service Pack 6 installed.
>
> There is some simple test code below which, on my system, produces the fault
> I have described. Just paste the code into a VB Form containing a Command
> Button and run the program and click the button. I really would appreciate
> it if anyone here would be prepared to try it on their own system and report
> the result, including details of the system and of which VB ServicePack is
> in use. On my system both the blue and the red horizontal lines are "dashed
> lines" with 256 pixel wide dashes and spaces, instead of the continuous
> horizontal lines that I was expecting.
>
> The code is so straight forward that I can't believe I've done something
> wrong myself, although I am getting a bit long in the tooth these days and
> my brain is not quite as agile as it used to be so it is always possible
> that I've slipped up! If anyone notices a problem with my code then I would
> appreciate it if you would let me know.
>
> p.s. I've just tested the same code on my laptop (very different processor
> and graphics subsystem than my main machine) and I get the same problem
> there. The only similarities between the two machines are the OS (one uses
> Vista Home and the other uses Vista Business) and the VB Service Pack (both
> using SP6).
>
> Mike
>
> Option Explicit
> Private Declare Function SetPixel Lib "gdi32" _
>   (ByVal hdc As Long, _
>   ByVal x As Long, ByVal y As Long, _
>   ByVal crColor As Long) As Long
>
> Private Sub Form_Load()
> Me.WindowState = vbMaximized
> Me.AutoRedraw = False
> Me.ScaleMode = vbPixels
> End Sub
>
> Private Sub Command1_Click()
> Dim x As Long
> For x = 0 To Me.ScaleWidth
>   Me.PSet (x, 10), vbBlue
>   SetPixel Me.hdc, x, 20, vbRed
> Next x
> End Sub
>
>
>
>
>

> "Martin Enke" <m.e***@km-enke.de> wrote in message
> news:49abbc28$0$31880$9b4e6d93@newsspool3.arcor-online.net...
>
>> this is a very intresting idea, could you please provide some
>> code on how to point a byte array to a bitmap?
>
> The method varies slightly depending on what kind of bitmap you are
> dealing with (screen compatible bitmap or device independent bitmap) and
> also where you are getting it from. If for example it is a device
> independent bitmap that you have created in code using CreateDIBSection
> then the CreateDIBSection function will return a pointer in the ppbits
> parameter telling you where in memory the bitmap bits are located, or if
> you have loaded a bmp file from disk using LoadImage then the LoadImage
> function is capable of telling you where the bitmap data is located in
> memory. Once you know the address you can then point a SAFEARRAY
> structure at that data and access it from the array. Perhaps a more
> flexible, albeit it slightly slower, method is to use GetDIBits to
> transfer the pixel data of an existing bitmap to an area of memory (an
> standard VB array of Bytes or perhaps Longs) in DIB format because this
> is easier to set up and will allow you to more easily deal with bitmaps
> that you commonly come across in VB6 (the Image bitmap of an Autoredraw
> PictureBox for example, the format of which varies depending on the
> colour depth of your display). This is slower than the previous method
> of pointing a SAFEARRAY structure at an existing block of bitmap data
> because it involves creating a new block of memory (the standard VB
> array of Bytes or Longs) and transferring the data of an existing bitmap
> into it, with the conversion that is required to convert the pixel data
> from screen compatible format to DIB format, but GetDIBits is
> surprisingly fast at converting and shifting such data so it is still a
> very useful technique.
>
> As an example, the following code loads a jpg image and stretches it
> into a screen sized Autoredraw VB PictureBox so that it exactly fits (in
> this simple example I have not taken account of the original aspect
> ratio). However, if you wish, you can easily change the code so that the
> PictureBox sizes itself to the full original image size. When you run
> the code and click the displayed picture the GetDIBits function copies
> the pixel data in DIB format into a suitably sized VB array of UDTs,
> where each UDT contains 4 individual Bytes (I could have instead used an
> array of Longs, but in this case I wanted easy access to the individual
> rgb bytes of each pixel). The code then, just for test purposes, runs
> through the VB array setting the red component of each "pixel" to zero.
> Finally the SetDIBitstoDevice function is used to transfer the VB array
> data back to the PictureBox in the appropriate format. Note that it
> would have been possible to transfer the data as a "three bytes per
> pixel" DIB into a Byte array, but using four bytes per pixel (even
> though it uses a little more memory) is sometimes more appropriate.
>
> Anyway, to try the code paste it into a VB Form containing a PictureBox
> and change the hard coded "c:\temp\jan1.jpg" to a picture that exists on
> your own system. When you run the project and click the displayed
> picture you will see the effect of the removal of the red element and
> the time taken will be displayed in a message box, showing separately
> the time taken by GetDIBits, the time to run through and modify the VB
> array data, the time taken by SetDIBitsToDevice and the overall total
> time. This time to deal with the array will be a lot quicker of course
> when run as a native code compiled exe than it will be when run in the
> IDE. Even though this particular method takes longer than the
> alternative of pointing an array at the existing image data (because it
> needs to actually copy blocks of memory data) it is still very quick
> when compared to SetPixel, typically hundreds of times faster.
>
> Mike
>
> Option Explicit
> Private Declare Function timeBeginPeriod _
>  Lib "winmm.dll" (ByVal uPeriod As Long) As Long
> Private Declare Function timeEndPeriod _
>  Lib "winmm.dll" (ByVal uPeriod As Long) As Long
> Private Declare Function timeGetTime _
>  Lib "winmm.dll" () As Long
> Private Type BITMAPINFOHEADER
>  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
> End Type
> Private Declare Function GetDIBits Lib "gdi32" _
>  (ByVal hdc As Long, ByVal hBitmap As Long, _
>  ByVal nStartScan As Long, ByVal nNumScans As Long, _
>  lpBits As Any, lpBI As BITMAPINFO, _
>  ByVal wUsage As Long) As Long
> Private Declare Function SetDIBitsToDevice Lib "gdi32" _
>  (ByVal hdc As Long, ByVal x As Long, ByVal y As Long, _
>  ByVal dx As Long, ByVal dy As Long, ByVal SrcX As Long, _
>  ByVal SrcY As Long, ByVal Scan As Long, _
>  ByVal NumScans As Long, Bits As Any, _
>  BitsInfo As BITMAPINFO, ByVal wUsage As Long) As Long
> Private Const DIB_RGB_COLORS = 0
> Private Const BI_RGB = 0
>
>
> Private Sub Form_Load()
> timeBeginPeriod 1
> Me.WindowState = vbMaximized
> Me.Show
> Picture1.Move 0, 0, Me.ScaleWidth, Me.ScaleHeight
> Picture1.ScaleMode = vbPixels
> Picture1.AutoRedraw = True
> Picture1.PaintPicture LoadPicture("c:\temp\jan1.jpg"), _
>  0, 0, Picture1.ScaleWidth, Picture1.ScaleHeight
> End Sub
>
> Private Sub Form_Unload(Cancel As Integer)
> timeEndPeriod 1
> End Sub
>
> Private Sub Picture1_MouseDown(Button As Integer, _
>  Shift As Integer, x As Single, y As Single)
> Dim bmapinfo As BITMAPINFO
> Dim SourceArray() As RGBQUAD
> Dim SourceWidth As Long, SourceHeight As Long
> Dim x1 As Long, y1 As Long
> Dim t1 As Long, t2 As Long
> Dim t3 As Long, t4 As Long
> SourceWidth = Picture1.ScaleWidth
> SourceHeight = Picture1.ScaleHeight
> With bmapinfo.bmiHeader
>  .biSize = Len(bmapinfo)
>  .biWidth = SourceWidth
>  .biHeight = SourceHeight
>  .biPlanes = 1
>  .biBitCount = 32
>  .biCompression = BI_RGB
> End With
> t1 = timeGetTime
> ReDim SourceArray(1 To SourceWidth, 1 To SourceHeight)
> GetDIBits Picture1.hdc, Picture1.Image, _
>    0, SourceHeight, SourceArray(1, 1), bmapinfo, _
>    DIB_RGB_COLORS
> t2 = timeGetTime
> ' just some test code to set the red
> ' component of each pixel to zero
> For y1 = 1 To SourceHeight
>  For x1 = 1 To SourceWidth
>    SourceArray(x1, y1).rgbRed = 0
>  Next x1
> Next y1
> '
> t3 = timeGetTime
> SetDIBitsToDevice Picture1.hdc, 0, 0, SourceWidth, _
>  SourceHeight, 0, 0, 0, SourceHeight, SourceArray(1, 1), _
>  bmapinfo, DIB_RGB_COLORS
> t4 = timeGetTime
> Picture1.Refresh
> MsgBox t2 - t1 & " milliseconds to create array and GetDIBits." _
>  & vbCrLf & t3 - t2 & " milliseconds to modify pixels " _
>  & vbCrLf & t4 - t3 & " milliseconds to SetBits back to Image." _
>  & vbCrLf & vbCrLf & "total time is " & t4 - t1 & " milliseconds."
> End Sub
>
>
>
>

> In fact after some more tests I think I've found the cause of the problem,
> although I don't know exactly why it is causing it. The problem occurs
> when the code is run in the VB IDE, and it also occurs in a compiled exe
> if that exe is run whilst the VB IDE is open, even if it is open for a
> completely different program, but it does not occur if the compiled exe is
> run at a time when the VB IDE is not running. I can, however, cause it to
> occur again either by running the VB IDE or by right clicking the compiled
> exe and setting Properties / Compatability to Disable Desktop Compostion.
> Thereafter, running the exe shows the dashed lines. So, the problem occurs
> only when the code is run whilst Vista Aero is turned off.
>
> I'll try various different drivers, but in view of the greatly different
> hardware of the machines on which the problem occurs I don't think a new
> driver will solve the problem. I might even one day try installing an XP
> driver and performing a restart, which will of course render the Vista
> Aero stuff and fancy desktop useless (perhaps not a bad thing, especially
> as it will bring back my 2D harware acceleration)!
>
> Mike
>
>
>

"Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
news:%233XuBG9mJHA.4028@TK2MSFTNGP03.phx.gbl...
> "Bob Butler" <noway@nospam.ever> wrote in message
> news:%23ivAv75mJHA.5520@TK2MSFTNGP06.phx.gbl...
>
>> I did not try Aero but it also fails for me with or without
>> the VB IDE running, native code or P-Code, and
>> regardless of the compatibility settings.
>
> Thanks Bob. As I've just mentioned to Rick, do you have an underlying
> setting that is not visible in the normal Properties / Compatibility tab,
> either in the VB6.exe or its shortcut or in the shortcut of the compiled
> exe? For example if you are viewing the Compatibility tab on each of those
> things I've mentioned and it shows all the ticks cleared and you then
> click the "Show Settings for All Users" button on the compatibility tab
> are all the ticks also cleared in that? When you run the code after
> checking that, does it still produce broken lines even though all the
> ticks on all those things (including the ticks on each underlying
> "Settings for All Users") are cleared?

"Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
news:OWWBDb9mJHA.3644@TK2MSFTNGP03.phx.gbl...
> "Bob Butler" <noway@nospam.ever> wrote in message
> news:%23ivAv75mJHA.5520@TK2MSFTNGP06.phx.gbl...
>
>> I did not try Aero but it also fails for me with or without
>> the VB IDE running, native code or P-Code, and regardless
>> of the compatibility settings.
>
> One thing I forgot to mention in my previous response is that (at least on
> my own two machines) the "broken dashed lines" problem occurs only when my
> system is *not* running Aero, so if you happen to be running with Aero off
> anyway then the ticks in the Compatibility tab will have no effect on the
> problem whether they are checked or not and you will most likely get the
> dashed lines problem. What happens when you repeat the checks with your
> system actually set to run Aero and actually displaying those fancy Aero
> translucent window borders and things? Does the problem go away when the
> code is run while Aero is actually operational and when there are no ticks
> against Compatibility, either normal or "All Users"? Sorry to ask you all
> these questions, but I really would like to pin this one down, even if it
> is mostly just a matter of interest rather than necessity. Thanks.
>
> Mike
>
>

"Randy Birch" <rgb_removet***@mvps.org> wrote in message
news:OoH5rxSnJHA.5832@TK2MSFTNGP06.phx.gbl...
> makes no difference here if aero is on or off.
>
> --
>
> Randy
> ms mvp, visual basic
> http://vbnet.mvps.org/
>
>
>
>
> "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
> news:OWWBDb9mJHA.3644@TK2MSFTNGP03.phx.gbl...
>> "Bob Butler" <noway@nospam.ever> wrote in message
>> news:%23ivAv75mJHA.5520@TK2MSFTNGP06.phx.gbl...
>>
>>> I did not try Aero but it also fails for me with or without
>>> the VB IDE running, native code or P-Code, and regardless
>>> of the compatibility settings.
>>
>> One thing I forgot to mention in my previous response is that (at least
>> on my own two machines) the "broken dashed lines" problem occurs only
>> when my system is *not* running Aero, so if you happen to be running with
>> Aero off anyway then the ticks in the Compatibility tab will have no
>> effect on the problem whether they are checked or not and you will most
>> likely get the dashed lines problem. What happens when you repeat the
>> checks with your system actually set to run Aero and actually displaying
>> those fancy Aero translucent window borders and things? Does the problem
>> go away when the code is run while Aero is actually operational and when
>> there are no ticks against Compatibility, either normal or "All Users"?
>> Sorry to ask you all these questions, but I really would like to pin this
>> one down, even if it is mostly just a matter of interest rather than
>> necessity. Thanks.
>>
>> Mike
>>
>>
>

"Mike Williams" <M***@WhiskyAndCoke.com> wrote...
> "Randy Birch" <rgb_removet***@mvps.org> wrote...
>
>> Hi Mike ... I have Aero on.  The exe shows broken lines too,
>> regarless as to whether the VB IDE is running or not, and
>> whether compiled to native code or pcode. Toggling "Disable
>> Desktop Compostion" does nothing either.  In fact, setting on or off any
>> of the compatibility options does not produce
>> an unbroken line . . .
>
> Do you have an underlying setting that is not visible in the normal
> Properties / Compatibility tab, either in the VB6.exe or its shortcut or
> in the shortcut of the compiled exe? For example if you are viewing the
> Compatibility tab and it shows all the ticks cleared and you then click
> the "Show Settings for All Users" button on the compatibility tab are all
> the ticks also cleared in that?

> I will of course investigate the possibility of video card driver problems
> but at the moment I'm still intrigued as to why my two machines and your
> own and Bob Butler's machines all produce the fault when they all use very
> different video hardware, so before I investigate further I just want to
> make sure we are all definitely running with no compatibility limitations
> (disable desktop composition for example) because on my own machine
> running without such limitations solves the problem. The problem still
> needs investigating further of course because simple pixel plotting code
> such as this should work on all machines at all user settings or there is
> something wrong.
>
> Mike
>
>

> "David Youngblood" <d**@flash.net> wrote in message
> news:uIwBki$mJHA.1168@TK2MSFTNGP05.phx.gbl...
>
>> I install vb6 on my labtop to see if it woult fail. Her are the results,
>> It only fails with Aero turned off.
>> It only fails if the Y value is greater than 19.
>> Pset does not fail in the IDE, Setpixel does fail.
>> Both Pset and SetPixel fail in the compiled exe.
>
> Thanks, David. And thanks to everyone else of course (Michael, Henning,
> Randy, Dan, Mayayana, London Lad, Ivar, Martin, Clive, and Bob . . .
> phew!). It certainly only fails to draw the full unbroken row of dots on
> my own two machines when the code is run whilst Aero is turned off, as on
> your laptop. I'm waiting to (hopefully) hear from Randy and Bob again just
> to confirm what they are getting on their machines.
>
>> That only fails if Y > 19 seems a strange one.
>
> Yep. That does sound strange. But then of course so does the fact that it
> fails only when bit 8 of the X coordinate is set! On my system it fails to
> draw the dot regardless of the value of the Y coordinate as long as bit 8
> of the X xoordinate is set. Curiouser and curioser, as Alice would have
> said :-)
>
> This of course applies only to setting individual pixels, which I imagine
> most people do not do very often, and there is no problem with lines and
> rectangles and circles and other things, but it is interesting
> nonetheless.
>
> Mike

> "David Youngblood" <d**@flash.net> wrote in message
> news:uIwBki$mJHA.1168@TK2MSFTNGP05.phx.gbl...
>
>> I install vb6 on my labtop to see if it woult fail. Her are the results,
>> It only fails with Aero turned off.
>> It only fails if the Y value is greater than 19.
>> Pset does not fail in the IDE, Setpixel does fail.
>> Both Pset and SetPixel fail in the compiled exe.
>
> Thanks, David. And thanks to everyone else of course (Michael, Henning,
> Randy, Dan, Mayayana, London Lad, Ivar, Martin, Clive, and Bob . . .
> phew!). It certainly only fails to draw the full unbroken row of dots on
> my own two machines when the code is run whilst Aero is turned off, as on
> your laptop. I'm waiting to (hopefully) hear from Randy and Bob again just
> to confirm what they are getting on their machines.
>
>> That only fails if Y > 19 seems a strange one.
>
> Yep. That does sound strange. But then of course so does the fact that it
> fails only when bit 8 of the X coordinate is set! On my system it fails to
> draw the dot regardless of the value of the Y coordinate as long as bit 8
> of the X xoordinate is set. Curiouser and curioser, as Alice would have
> said :-)
>
> This of course applies only to setting individual pixels, which I imagine
> most people do not do very often, and there is no problem with lines and
> rectangles and circles and other things, but it is interesting
> nonetheless.
>
> Mike
>

"Mike Williams" <M***@WhiskyAndCoke.com> wrote in message
news:%23bxOMD9mJHA.1252@TK2MSFTNGP03.phx.gbl...
> "Randy Birch" <rgb_removet***@mvps.org> wrote in message
> news:OoBDBy5mJHA.4028@TK2MSFTNGP03.phx.gbl...
>
>> Hi Mike ... I have Aero on.  The exe shows broken lines too,
>> regarless as to whether the VB IDE is running or not, and
>> whether compiled to native code or pcode. Toggling "Disable
>> Desktop Compostion" does nothing either.  In fact, setting on or off any
>> of the compatibility options does not produce
>> an unbroken line . . .
>
> Do you have an underlying setting that is not visible in the normal
> Properties / Compatibility tab, either in the VB6.exe or its shortcut or
> in the shortcut of the compiled exe? For example if you are viewing the
> Compatibility tab and it shows all the ticks cleared and you then click
> the "Show Settings for All Users" button on the compatibility tab are all
> the ticks also cleared in that?
>
> I will of course investigate the possibility of video card driver problems
> but at the moment I'm still intrigued as to why my two machines and your
> own and Bob Butler's machines all produce the fault when they all use very
> different video hardware, so before I investigate further I just want to
> make sure we are all definitely running with no compatibility limitations
> (disable desktop composition for example) because on my own machine
> running without such limitations solves the problem. The problem still
> needs investigating further of course because simple pixel plotting code
> such as this should work on all machines at all user settings or there is
> something wrong.
>
> Mike
>
>