Importing data into a Pic or Graphic control from DC.

[sigmason]

Okay so I'm confused about something and I'm not sure what the issue is with this.

I want to grab a screen capture (using the A3Lib from PaulIT) and put the image in a 800x600 WM_POPUP style window (no title and modal) WITHOUT saving it first.

I've suceeded in grabbing the image as per the examples provided with the library. I've suceeded in displaying the image by either using the GDI+ drawing routines directly to a graphics object formatted for a compatible bitmap, or by drawing the capture into a memory based DC and then bitblting it over to the DC of either the GUI window or an graphic/pic.

However, in all cases, including all the examples, I notice that the window MUST be displayed BEFORE the actual image data is transferred, and I've found that if it isn't the image data is apparently missing. I've even tried prompting redraws of the controls and window and gotten no where.

Now at first I figured this was because the example wrote to the DC of an object that was set to be displayed. However, this is not the case, I CANNOT make even the transfer of an image by bitblt work to a hidden window, the window on the destination MUST be visible (as in one the visible portion of the screen, you can't even get this to work with the image shifted out of the visible range of the screen.)

Unfortunately for me, even the transfer from the memory DC to the visible window is too slow for my needs, which in this case is to display an image of the whole screen full screen. Ideally, I want to be able to draw the image into the picture with the GUI hidden and then unhide it producing a fullscreen copy of my screencapture. The visible artifacts created by such a large bitblt are not acceptable for my needs (if you watch carefully you can see the window background color being covered quickly by the bitblt.)

Now to add my confusion, if one does a GUICtrlCreatePic with a picture filename, one can put the image in the pic WHILE the window is hidden.

I've been puzzling over this for quite a bit longer then I would like.

I do NOT want to resort to layers or transparency to cover up this issue. I require this script to run in Windows 98 and I'm fairly sure those features will not be available.

I've attached some REALLY poorly written code to this request.

Look for the comment with the 3 * in it.

If you comment out the GUISetState() (which is @SW_SHOW) you'll see the image DOES NOT appear in the Pic control after the bitblt.

expandcollapse popup

#include <A3LGDIPlus.au3>
#include <A3LScreenCap.au3>
#include <GUIConstants.au3>

$hScrnCap = _ScreenCap_Capture("")
$hGUI1 = GUICreate("Original", 800, 600, 0, 0, $WS_POPUP)
$GraphicID = GUICtrlCreatePic("",0, 0 , 800 , 600)
$hGUI = ControlGetHandle ( "Original", "", $GraphicID)

$hDDC = _API_GetDC($hGUI)
;MsgBox(4096,"Test1",$hDDC)
;MsgBox(4096,"Test2",_API_GetDC(_API_GetDesktopWindow()))

$hCDC = _API_CreateCompatibleDC($hDDC)
$hBMP = _API_CreateCompatibleBitmap($hDDC, 800, 600)
_API_SelectObject($hCDC, $hBMP)

_GDIP_Startup()
$hImage = _GDIP_BitmapCreateFromHBITMAP($hScrnCap)
$hGraphics = _GDIP_GraphicsCreateFromHDC($hCDC)

_GDIP_GraphicsDrawImage($hGraphics, $hImage, 0, 0)
;_API_SelectObject($hDDC,$hGraphics)

_GDIP_GraphicsDispose($hGraphics)
_GDIP_ImageDispose($hImage)
_API_DeleteObject($hScrnCap)
_GDIP_Shutdown()

;*** If the following line is commented the image will not appear.
GUISetState(@SW_SHOW)
;WinMove("Original","",1000,1000)

_API_BitBlt($hDDC, 0, 0, 800, 600, $hCDC, 0, 0, $SRCCOPY)

;GUICtrlSetGraphic($GraphicID,$GUI_GR_REFRESH)

;WinMove("Original","",0,0)
GUISetState(@SW_SHOW)
;_API_UpdateWindow($hDDC)

_API_ReleaseDC($hGUI, $hDDC)
_API_DeleteDC($hCDC)

SLeep(5000)

Edited August 28, 2007 by sigmason

[Fossil Rock]

Welcome to the forum. Interesting first post.

What is 'DC'? This code is a little over my head, but I'm still trying to learn it for a little project I'm working on.

[sigmason]

Welcome to the forum. Interesting first post.

What is 'DC'? This code is a little over my head, but I'm still trying to learn it for a little project I'm working on.

DC stands for Device Context

Follow this link for more on the topic

WikiPedia on GDI+

From Microsoft's MSDN

Basically a device context, within the confines of my post, is a structure that defines the output characteristics of

of an object. So for example by getting the device context of the screen in effect I'm getting the characteristics of

the screens current display capability. Using that information one can then format the data to exchange between

various devices or structures.

What I've done in my example code, was to create a memory device context that in effect mirrored the device

context of the control on a GUI.

It's rough, but if you copy and paste the code you'll see it works, that is if you don't hide the window while putting

the screen capture data into the Graphic/Pic.

[Fossil Rock]

Thanks for the explanation and links. I don't follow the code at all (over my head). But I follow the output just fine and I like it. Works better than the "from file" method (IMO).

My question is... if the code could be made to work with the line commented, what would be the advantage? How would be it any different than the same code with the line not commented?

Just trying to understand your goal.

[sigmason]

Thanks for the explanation and links. I don't follow the code at all (over my head). But I follow the output just fine and I like it. Works better than the "from file" method (IMO).

My question is... if the code could be made to work with the line commented, what would be the advantage? How would be it any different than the same code with the line not commented?

Just trying to understand your goal.

The advantage I get would be:

If the window can be drawn hidden, then the delay for it to completely display will be reduced to the amount of time Windows requires to render the intact image.

The disadvantage currently is:

With the window showing, the background of the image briefly appears as the image content of the window is transferred by the API bitblt and at higher resolutions this will become much more obvious.

I'm using this image as a mask, set on top of the other windows, to divert the user from interfering in, and complaining about the otherwise minor visual consequences of a script I am writing. As the script is quick, the fact that I'm actually cloaking the desktop is irrelevant. I am, however, dealing with a situation in which the users are:

A. Looking for ways to interfere, and to make excuses about any conceivable consequence to this script operating.

B. Otherwise incapable of being trusted to complete the action the script performs under other circumstances.

C. Unwilling to deal with either the consequences of their own interference or their own requirements.

In short, what I am concealing with this image for a whooping 1 second (tops) is something they demand they want done, don't understand the operation of, will complain unendingly about the particulars of, however will not offer me any other alternative to complete.

(Falls in the category of it's best they don't see what they really won't understand, to keep the peace.)

Edited August 28, 2007 by sigmason

[Fossil Rock]

A. Looking for ways to interfere, and to make excuses about any conceivable consequence to this script operating.

B. Otherwise incapable of being trusted to complete the action the script performs under other circumstances.

C. Unwilling to deal with either the consequences of their own interference or their own requirements.

In short, what I am concealing with this image for a whooping 1 second (tops) is something they demand they want done, don't understand the operation of, will complain unendingly about the particulars of, however will not offer me any other alternative to complete.

Are you a NetAdmin? Sounds like it ... been there - done that (15 years), buncha cryin' whiney babies.

EDIT: You must be deaing with some slow 'puters, it appears on my system all at once, I can't detect any lag.

Edited August 28, 2007 by Fossil Rock

[sigmason]

Are you a NetAdmin? Sounds like it ... been there - done that (15 years), buncha cryin' whiney babies.

EDIT: You must be deaing with some slow 'puters, it appears on my system all at once, I can't detect any lag.

Sadly, yes those computers are nothing fancy.

For the most part they are used for data entry and for that they are marginal with XP Pro.

Unfortunately, I can neither hope the issue will go away or change the fact that several systems are

still running Windows 98, so I'll need to pursue this.

In this case, yes I am the NetAdmin, DBAdmin, programmer, web developer, IT, electrician, HVAC technician, electronic engineer and chief bottle washer

Ain't it just the best (excuse the nervous twitch)

[Fossil Rock]

In this case, yes I am the NetAdmin, DBAdmin, programmer, web developer, IT, electrician, HVAC technician, electronic engineer and chief bottle washer

Ain't it just the best (excuse the nervous twitch)

You forgot PBX tech, help desk, field engineer, scapegoat, punching bag and all around low life know it all whose job wouldn't exist if it weren't for the "customers" (term I had to use).

[Zedna]

Look at my post

There is function  _SetBitmapToCtrl() and

- finished example for using bitmaps

- not finished example for using JPG,GIF,PNG with A3L GDI+ (_ResourceSetImageToCtrl)

Func _SetBitmapToCtrl($CtrlId, $hBitmap)
    Local Const $STM_SETIMAGE = 0x0172
    Local Const $IMAGE_BITMAP = 0

    Local $hWnd = GUICtrlGetHandle($CtrlId)
    DllCall("user32.dll", "hwnd", "SendMessage", "hwnd", $hWnd, "int", $STM_SETIMAGE, "int", $IMAGE_BITMAP, "int", $hBitmap)
EndFunc

[sigmason]

You forgot PBX tech, help desk, field engineer, scapegoat, punching bag and all around low life know it all whose job wouldn't exist if it weren't for the "customers" (term I had to use).

@ Fossil Rock

Well I don't know if our job wouldn't exist without the "customers" shortcomings. In a funny way, I think our jobs probably exist more because of the expectation that most reasonable people get from the hype of computer technology and then discovering that the reality is hardly the demonstration of pre-engineered brilliance that most people were sold into believing their $10,000s+ were buying them. Especially in my case, where I have to be a little more forgiving when the reality is a word processor or terminal and photocopier would actually really be more efficient and cheaper to maintain.

It's just one of those things I guess, I fully resent the days I am the brunt of other people's misgivings of my capabilities, efforts and dedication. Then again, truth be told I used to build mainframes and some days the directions of this PC industry really make even me wonder why most people bother.

LOL, now on that note, just because I have been known to do lewd things with Microsoft Agent to people that step over the line, that hardly makes me a low life... but if that's all it takes then a lower form of life there never was.

On this note, my sincere thanks to the AutoIt community and all those that have contributed here, for years your efforts have made my life just a little bit easier by making things I would otherwise work much harder to do much faster, much more obvious to others I work for, and with, and all around just much more pleasant. AutoIt is one of the very few programs that never ceases to impress me.

@ Zedna

I'm running late this morning your post makes absolute sense given the image is a static control. Something indirectly about this isn't sitting right with me though. I know in the past I was able to use a memory DC to pass an image to a picture control, for instance I do this in VB6 to picturebox control. I guess it's the difference in the control that is the issue? I need to contemplate this more. Thank you for your quick response.

Edited August 28, 2007 by sigmason

[Zedna]

@ Zedna

I'm running late this morning your post makes absolute sense given the image is a static control. Something indirectly about this isn't sitting right with me though. I know in the past I was able to use a memory DC to pass an image to a picture control, for instance I do this in VB6 to picturebox control. I guess it's the difference in the control that is the issue? I need to contemplate this more. Thank you for your quick response.

STM_SETIMAGE is working also with picture control but I set up it after @SW_SHOW

Look here

[sigmason]

STM_SETIMAGE is working also with picture control but I set up it after @SW_SHOW

Look here

VB City example of bitmap in DC moved to VB PictureBox

I knew I used something like this before (but the code is not open source, so above is a public example.

Apparently, there is a difference in the VB PictureBox control and a static control:

Difference between using a DC and a PictureBox

The AutoRedraw function one would need apparently uses the refresh method and a DC:

Mentions how the AutoRedraw in VB works.

VB.Net does not support the form AutoRedraw method....

Tries to emulate the missing AutoRedraw in VB.Net

A little more detail on the same issue with the PictureBox control in VB6 and GDI+

In the end, somewhere along the line the AutoRedraw function in VB6 allows a transfer of

a device dependent bitmap in this manner because they've managed to transfer the image into the control and hook the necessary refresh and paint methods to make this work.

If you were to transfer the image in the same manner I have in my first post in VB6 without the AutoRedraw property of a form set to true, the image would also be clipped anywhere it isn't visible (I just went and reviewed my code and this is in fact the case.) This was what was confusing me, apparently, it's managed to confuse alot of other people to.

This said, I'll change gear to your suggestion of using a SendMessage to set image into the controls persistent storage. This is likely, as you've pointed out, the easiest way to get persistent storage on the form that won't require hooking all the refresh and paint events.

Thanks, I'll post back later....

Edited August 28, 2007 by sigmason

[Zedna]

...

I'm interested in this area too, thanks for the links I will look at them.

If you encountered problem with flickering then look at my posts about flickering problem in AutoIt:

Here is search result for search "flickering" by user Zedna: link

Especially look here

I discovered bug in GUICtrlSetImage() - it's repainting image (picture control) twice:

- first in image original size

- second in stretched size (to size of picture control)

I have problems with this in my Radar project - see my signature

Edited August 28, 2007 by Zedna

[sigmason]

I'm interested in this area too, thanks for the links I will look at them.

If you encountered problem with flickering then look at my posts about flickering problem in AutoIt:

Here is search result for search "flickering" by user Zedna: link

Especially look here

I discovered bug in GUICtrlSetImage() - it's repainting image (picture control) twice:

- first in image original size

- second in stretched size (to size of picture control)

I have problems with this in my Radar project - see my signature

It's been a long time since I've used GDI+ directly, and that's my biggest issue.

Lately I've been using WxWindows, Java Swing and the like ....

That said, I'm not sure this will help you, but have you considered trying the stunt I did in the first post's example.

Although any other windows over your image will clip your window, if you did consistent bitblts to the DC of the picture it wouldn't really be important, and if your window is completely buried you could check the visible property to reduce the system load.

This might work really well for you, because your not concerned with the first rendering like I am.

Using the _API_bitblt directly would enable you to manipulate the image for more then just updates as well (you could do things like XOR animation which prevent flickering in sprites.)

XOR Animation Ain't Spiffy But It Really Works!

By using the bitblt in this manner you should be able to background render your image to a memory DC then bitblt it with an XOR to the DC of the Graphic/Pic GUI control. If the image is over lapped by the window, it will be invisible (so what it would be anyway.) If the image is visible and say another window is clipping a region of it, the only visual artifact would be created by the delay between your bitblt operations. If you could override WM_PAINT in the WndProc (I'm not totally sure AutoIt can do that...I never really looked) then you could even cause the movement of windows clipping your animation to force a bitblt in your script.

This doesn't help me, I don't need to frequently update my image. I need it to draw over the top of the whole desktop image without first blanking the image. In fact, if Microsoft implemented transparency in Windows 98 that would do exactly what I need. I could set the window to transparent, forget about the memory DC and draw the image transparently to the transparent window. Then drop the window transparency and boom, there's the image. I suppose one could try flip book animation like this as well, by stacking windows with images drawing set to transparent and then setting the images non-transparent , that might accomplish much the same thing, but retain the image persistence of the Graphics/Pic objects. Tough I'll bet it might make the load on Windows a bit tricky to control (unlike the memory DC, you're basically swapping windows to top or to non-transparent and that might create focus issues. I suppose alternatively you could do the page swapping trick with Graphic/Pic controls as well. You could stack the controls using layering and then draw into them and change each controls transparency to bring it into visible.

I hope that helps....

Edited August 28, 2007 by sigmason

[Zedna]

By using the bitblt in this manner you should be able to background render your image to a memory DC then bitblt it with an XOR to the DC of the Graphic/Pic GUI control. If the image is over lapped by the window, it will be invisible (so what it would be anyway.) If the image is visible and say another window is clipping a region of it, the only visual artifact would be created by the delay between your bitblt operations. If you could override WM_PAINT in the WndProc (I'm not totally sure AutoIt can do that...I never really looked) then you could even cause the movement of windows clipping your animation to force a bitblt in your script.

AutoIt can trap Windows messages by GUIRegisterMsg() - see in helpfile - and now with great CallBack UDF (no external DLL) - see in Examples forum - is possible to do subclassing. These two methods I have in plan for future tests with WM_PAINT to make some antiflicker workaround. I know about BitBlt API suitable for this purpose but haven't experiences with XOR mode.

Thanks for your explanations. Some are new to me 

Unfortunatelly I can't help your with your need U have no idea better then yours.

[sigmason]

AutoIt can trap Windows messages by GUIRegisterMsg() - see in helpfile - and now with great CallBack UDF (no external DLL) - see in Examples forum - is possible to do subclassing. These two methods I have in plan for future tests with WM_PAINT to make some antiflicker workaround. I know about BitBlt API suitable for this purpose but haven't experiences with XOR mode.

Thanks for your explanations. Some are new to me

Unfortunatelly I can't help your with your need U have no idea better then yours.

Take a look at XOR, it's a cute mathematical trick, I remember using it with PEEKs and POKEs on the Commodore 64...and sprites I drew in the sprite editor on the Commodore 128 so long as you can render images into a memory DC the effect should be okay. The other script I was looking at you posted up here related to GUICtrlSetImage and you noted correctly that it can't draw the image while it's hidden (for much the same reasons I'm having my problem.) Try taking that script and unhide the control. There's really no point in hiding it. So what if the WM_PAINT function fires during the GUICtrlSetImage even if it tries to draw slow several times your output to the DC will override that behavior by drawing the same image very quickly, because your bitblt operations are unhindered by that functions WndProc. It will render very quickly, I'm sure more quickly on something faster then the computer I am on now. The only real benefit of a background memory DC to that particular script would be to mask the delay of loading a large deep color depth picture from the drive by caching it to memory.

On the note of large images, be careful attempting to put large images into a DC.

I believe, it's been a while, that it used to be a limit of about 16MB for bitmap used in this

mode. If you hit that limit, try using device independent bitmap functions (DIB) functions, with those you can splice a huge image together by making tiles.

Edited August 29, 2007 by sigmason

[Zedna]

Take a look at XOR, it's a cute mathematical trick, I remember using it with PEEKs and POKEs on the Commodore 64...and sprites I drew in the sprite editor on the Commodore 128 so long as you can render images into a memory DC the effect should be okay. The other script I was looking at you posted up here related to GUICtrlSetImage and you noted correctly that it can't draw the image while it's hidden (for much the same reasons I'm having my problem.) Try taking that script and unhide the control. There's really no point in hiding it. So what if the WM_PAINT function fires during the GUICtrlSetImage even if it tries to draw slow several times your output to the DC will override that behavior by drawing the same image very quickly, because your bitblt operations are unhindered by that functions WndProc. It will render very quickly, I'm sure more quickly on something faster then the computer I am on now. The only real benefit of a background memory DC to that particular script would be to mask the delay of loading a large deep color depth picture from the drive by caching it to memory.

Thanks for info I appreciate it.

I did some antiflicker double buffering methods in AutoIt already (BlackJack in Examples forum)

it uses hidden memory DC, all painting is done to this hidden DC and finally it's exposed to visible control's DC by very quick BitBlt API.

This BitBlt is really very quick and I think it will not make any flickering so it's exactly what you said and I agree.

But with my Radar project I have no painting stuff only set GIF image to picture control by GUICtrlSetImage

and this GUICtrlSetImage will cause flickering.

My thought was use as workaround simpler way with GUIRegisterMsg or harder way with DllCallBack to cach WM_PAINT message. but now I think I must override WM_PAINT message to avoid flickering so I need to do all loading/converting from GIF to BMP/BitBlt to picture control's DC myself (with Auto3Lib and GDI+). Because if I let to run AutoIt's original WM_PAINT then output will be rendered twice (AutoIt bug) with flicker and then my message BitBlt quickly after that.

So very important is to make it as override method with all that needed stuff.

It's rather complicated and dependend on GDI+ therefore I didn't find moral power to go into that deep testing yet 

[sigmason]

I got what I needed.

There were 2 ways to hide the drawing of a screen capture image in the window.

This script depends on speed to be effective.

1. Set the window transparent while it draws, hence the drawing is hidden. Then reset the window to non-transparent when we need it to appear suddenly.

2. Hook the window WM_ERASEBKGND method to prevent the window from drawing it's background when it's shown so that it is on top, but not aware it is invisible. Then when we want the image make the control visible which will cause it's unhooked WM_PAINT to draw it over a static desktop image that is the same (making the drawing apparently invisible.)

Now for something interesting and somewhat related.

To get the image from the screen capture into the Pic you need to run it through the GDI+ library via Auto3Lib. If you don't the palette will likely (not always) be wrong when it is displayed. This has to do with the way the palette is retrieved from the device dependent bitmap functions and the video drivers. It's counter intuitive when you look at the code. You are apparently converting an image for no reason to another format and back. It's NOT for no reason.

expandcollapse popup

;What this will do...is nearly invisible.
;Basically, for the first 3 seconds this script is running you are usually looking at
; a 800x600 dialog box that is transparent or prevented from drawing it's background.
;For the last 3 seconds this script is running you are looking at a screen capture made
; at the start of the script.
;The drawing of the screen capture is 'invisible' because the background of the image
; is not drawn first or the entire window is transparent when the image is drawn.

#include <A3LGDIPlus.au3>
#include <A3LScreenCap.au3>

;Capture the screen to an HBITMAP structure.
$hScrnCap = _ScreenCap_Capture()

;Create an 800x600 window.
$hWnd = GUICreate("Original", @DesktopWidth, @DesktopHeight, 0, 0, $WS_POPUP)
;Put a picture control in the window...NOT a graphic control.
;It appears the graphic control DOES NOT accept the STM_SETIMAGE message.
$CtrlID = GUICtrlCreatePic("",0, 0 , @DesktopWidth, @DesktopHeight)
;Get a handle to the control we created.
$hCtrl = ControlGetHandle ( "Original", "", $CtrlID)
;Hide the GUI and by association all it's controls.
GUISetState(@SW_HIDE)

;Fire up GDI+, note the DLL has to be present on your platform to do this.
_GDIP_Startup()
;Put the captured HBITMAP structure into a bitmap object.
$hScrnCapBMPObj = _GDIP_BitmapCreateFromHBITMAP($hScrnCap)
;Put the bitmap object into a HBITMAP structure.
$hScrnCaphBMP = _GDIP_BitmapCreateHBITMAPFromBitmap($hScrnCapBMPObj)
;Send a message via the API to perform the SetImage function on the control.
Const $STM_SETIMAGE = 0x0172
Const $IMAGE_BITMAP_CODE = 0x0
_API_SendMessage($hCtrl, $STM_SETIMAGE, $IMAGE_BITMAP_CODE, $hScrnCaphBMP)

;Clean up the GDI+ resources they are limited.
;Let GDI+ dispose of the BITMAP.
_GDIP_ImageDispose($hScrnCapBMPObj)
;Let the API dispose of the HBITMAP structures.
_API_DeleteObject($hScrnCaphBMP)
_API_DeleteObject($hScrnCap)
;Shutdown GDI+.
_GDIP_Shutdown()

;If the window is set transparent here you can accomplish a similar effect as what hooking
; the WM_ERASEBKGND method accomplishes.  This will not work in older Windows operating
; systems as they do not support transparency.  MAKE SURE to select the appropriate part
; to uncomment after the sleep statement below.
;WinSetTrans("Original","",0)

;By hooking the WM_ERASEBKGND method, we can prevent it from drawing the window background.
; MAKE SURE to select the appropriate part to uncomment after the sleep statement below.
GUIRegisterMsg($WM_ERASEBKGND, "My_WM_ERASEBKGND")

;Show the window and the control by association.
GUISetState(@SW_SHOW)

;Hide the control on the window, it seemed when I did this before the show of the window
; the show removed the control's hidden attribute.
GUICtrlSetState($CtrlID, $GUI_HIDE)

;NOTICE carefully, regardless of which of the above ways you use at this point the window
; is 'transparent' either because the WM_ERASEBKGND from the show state is empty or because
; the window image is actually transparent.  You can confirm this be using neither method at
; which point the screen will turn the default window background color initially.

;Wait 3 seconds for the user to see the results.
Sleep(3000)

;Make the window non-transparent if it really is transparent.
;WinSetTrans("Original","",255)

;Make the control appear if we hooked the WM_ERASEBKGND method.  This works because while
; the WM_ERASEBKGND is hooked the WM_PAINT method of the control is not hooked.
GUICtrlSetState($CtrlID, $GUI_SHOW)

;Wait for the user to see the image we capture of their desktop.
Sleep(3000)

;Terminate this script before it executes the attached functions.
Exit

Func My_WM_ERASEBKGND($hWnd, $Msg, $wParam, $lParam)
;Notice that if you don't list the above parameters this routine will still work.
;I've included them because it's more appropriate.
;If you return anything here, it will prevent AutoIt from continuing the original
; method it gave this window.
    Return 0
EndFunc

Edited September 10, 2007 by sigmason

[sigmason]

Just in case anyone finds a use for the code in my last post...

I just successfully verified that the code I created does work perfectly on a Compaq with 64MB of RAM running Windows 98 (First Edition) while a COMMAND box is open. I was just curious.

The reason the code in that last post is speed dependent is because the objective of drawing an image of the screen apparently invisibly is only accomplished if the image shown while the other image is being drawn does not have time to change significantly before the drawing operation covers the areas that might be changing. In this sense the operations that take place between the screen capture and the actual display of the control are a critical section and if for some reason there's too much delay and something under the 'transparent' window is rapidly changing the effect will be lost.

I tested this on a relatively really slow computer to determine whether it might be a good idea to raise the script's priority or take those mostly API calls out and compile them into a seperate executable with some compiled version of BASIC (to retain the readability for the other people working with me here) and then raise that code's priority seperately at execution.

In any case, I think the book is closed on this topic for my needs.

Edited August 30, 2007 by sigmason

[Zedna]

Thanks for sharing your interesting stuff.

I you wish to test something on slow machine you can use software for slowing down your current computer. For example look at Sleeper