Problems getting a window capture with Bitblt and PrintWindow.

Quote:

---

Originally Posted by VanGoghGaming

VB.NET sucks! :D But I'm sure you can find a kind soul here who has been swayed by the dark side! ;)

---

;) VB.NET isn't that bad. It's a lot easier to program there. But also somehow more boring and not as challenging as with VB6. :D

Somehow the whole .NET suite has flown right past me so I have zero experience with any of it but somehow I still doubt it's "a lot easier" as you put it. From what I've read, it would seem quite the contrary. I am also mostly a hobbyist like yourself but if I was going to move to another programming language I would try TwinBasic since it is compatible with VB6. Still waiting for it to mature though (or at least go out of perpetual "Beta"!).

Quote:

---

Originally Posted by VanGoghGaming

Somehow the whole .NET suite has flown right past me so I have zero experience with any of it but somehow I still doubt it's "a lot easier" as you put it.

---

It's easier in the sense that you don't have to manually import half the Windows API just do some simple task and you don't need too many clever tricks to get by. The IDE also provides a lot of value in the form of many new features like code refactoring and the intellisense is more powerful. It all adds up to a less stressful experience when trying to get things done. At least that's how I feel.

Others may feel differently. It comes down to familiarity. If you're more familiar with VB6 that's going to feel better but those of us familiar with both tend to favor .Net more. Not all but most. Some people will always prefer VB6 no matter what. Just the way it goes.

Quote:

---

Originally Posted by VanGoghGaming

I am also mostly a hobbyist like yourself but if I was going to move to another programming language I would try TwinBasic since it is compatible with VB6.

---

I looked at TwinBasic and experimented a bit with it. It's still not quite what I would like it to be. However, the TwinBasic project is going in the right direction and could eventually replace VB6. I can only recommend you to take a look at .NET and try it out.

e.g. I always wrote my WinRT projects with VB6 first and only then translated them to VB.NET. From this you can already see which language I prefer. :bigyello:

Trying it only cemented my resolve to never use it.

Wound up going the other way; still focused mostly on VB6 and now tB, but I'm learning more C/C++ instead.

Quote:

---

Originally Posted by fafalone

Trying it only cemented my resolve to never use it.

Wound up going the other way; still focused mostly on VB6 and now tB, but I'm learning more C/C++ instead.

---

I'm not surprised. You do a lot of lower level stuff like drivers or fiddling with the inner workings of type libraries and such. .Net isn't going to appeal to someone like you. It is not suited to the kind of programming you do. This is also why you find C/C++ appealing.

I'd also recommend you get comfortable with assembly. I'm not assembly expert but I'm comfortable enough with it to tell you it's not as difficult as you might think. The language itself is actually among the easiest to learn. The difficulty in assembly actually comes from the need to understand how the CPU works, not from the language itself. Based on the types of projects you do, I know you will absolutely love assembly when you get to know it.

Heh, "WHAT DO YOU MEAN THERE'S NO VarPtr()!??! How will I do ANYTHING!" --me, the first time I ever tried rewriting a project in VB.NET.

I dabbled with 68k a bit way back in high school, because all the best games for my TI-89 calculator were written in it (sometimes my French teacher wondered why I needed my calculator out in her class, LOL), but forgot just about all of it since the 8 years after college in my life, were, well, I forgot a lot... only have the most superficial understanding; the most common instructions, the basic ideas of registers and the stack. It's been on the 'to-do list' for a long, long time, because I'm fascinated by the things people like The trick, wqweto, etc do with thunks in VB6, and would eventually like to be able to do them myself.

I was contemplating an approach of learning x86 and x86_64 simultaneously, since going forward I want to write everything compatible with both like I'm doing now with tB... but there's virtually no beginner-friendly resources for the latter, any recommendations?

Quote:

---

Originally Posted by fafalone

Heh, "WHAT DO YOU MEAN THERE'S NO VarPtr()!??! How will I do ANYTHING!" --me, the first time I ever tried rewriting a project in VB.NET.

---

Haha. I feel you. VarPtr doesn't really fit into .Net all that well. For one thing, objects in .Net are not fixed in memory so you never want to allow programmers to just grab pointers all will-nilly. Another thing is that P/Invoke is very flexible. You have very fine control over how types are marshalled so you never need something like VarPtr when calling into an unmanaged environment like the Win32 API. You can just tell P/Invoke to marshal your parameters as pointers without needing to explicitly do it.

Just for fun, one can write their own VarPtr function if they are so inclined:-

Code:

---

Imports System.Data.OleDb
Imports System.Runtime.InteropServices

Module Module1

    <DllImport("kernel32.dll", EntryPoint:="RtlMoveMemory")>
    Public Sub CopyMemory(ByVal Destination As IntPtr, ByVal Source As IntPtr, ByVal Length As UInteger)
    End Sub

    Sub Main()

        'Unfortunately for this to work we MUST box primitive
        'value types assigning by them to an Object type variable
        'instead of Integer, otherwise VarPtr returns the address
        'to a copy of the value type. By boxing it, we make value types
        'behave like reference types so VarPtr will return the correct address
        Dim a As Object = 12I
        Dim b As Object = 200I

        CopyMemory(VarPtr(a), VarPtr(b), 4)

        'Prints 200 proving the copy operation worked
        Debug.WriteLine(a.ToString)
    End Sub

    'This cannot be made to work on value types so we use the Class
    'constraint to make sure the compiler only allows reference types are passed to VarPtr.
    'If we allow value types to be passed, VarPtr will always return the wrong address because
    'it would be returning the address of a copy, not the original. GCHandle.Alloc
    'is the culprit here as it's first parameter is passed by value. We cannot do anything about that.
    Private Function VarPtr(Of T As Class)(ByVal obj As T) As IntPtr
        Dim h = GCHandle.Alloc(obj, GCHandleType.Pinned)
        Try
            Return h.AddrOfPinnedObject
        Finally
            h.Free()
        End Try
    End Function


End Module


---

However, I'd recommend no VB.Net programmer ever do that EVER. While the above works it's a disaster waiting to happen. The GC can move those objects in memory at any time so there is potential for VarPtr to return an invalid address.

I think you might have preferred C# though. The C# compiler is far less constrained than the VB.Net compiler and it allows you to do low level programming very easily. The above code would look like this in C#:-

Code:

---

using System;
using System.Diagnostics;

class Program
{
    static void Main()
    {
        unsafe
        {
            int a = 12;
            int b = 200;

            // Get the addresses of a and b
            int* aPtr = &a;
            int* bPtr = &b;

            // Copy the value of b to a
            *aPtr = *bPtr;

            // Prints 200 proving the copy operation worked
            Debug.WriteLine(a.ToString());
        }
    }
}

---

Quote:

---

Originally Posted by fafalone

but there's virtually no beginner-friendly resources for the latter, any recommendations?

---

Hmmm..Let me see how best I can advise you here because I went though the same struggle. For years I tried to get a handle on assembly but nothing I ever found was beginner friendly enough. It wasn't until I stumbled on a specific article completely by accident did it really click for me. The article was about using the Flat assembler to compile ASM code into machine code and calling it from .Net as a function. To this day I'm not sure why this specific example made it click for me but I think it has something to do with the fact that it was within the context of an environment I was already familiar with, in this case .Net.

To that end, what I'd recommend is that you download trick's assembly VB6 add-in and start writing very simple functions in assembly and call them from VB6. This way it cuts out all the noise like setting up sections, import tables and all that. You can just jump right in and start with something very basic. Things will start clicking for you and you can then start learning more and more at your own pace. I've seen the kind of things you do, trust me, you would be a very capable assembly language programmer. You just need to stop letting it intimidate you. ;)

I've been think about writing a very basic article on using assembly in VB6 or .Net. Nothing fancy, just something simple enough that anybody could start wetting their feet. I really do think it's possible for anyone to learn the basics but as you've said, it's really hard to find something that beginner friendly enough.

I decided to go ahead and make an assembly language article myself. Hopefully it's simple enough for anyone to understand, even if it's a bit long:-
https://www.vbforums.com/showthread....VB6-The-Basics

Quote:

---

Originally Posted by -Franky-

Look at post #54. There I wrote where you can find this vb6 example already translated to VB.NET.

---

I can't do it, I didn't find 54 examples in the post

Just got around to revisiting this capture project (from post #41 above) with a fresh approach. It always bothered me that the process of acquiring new frames was done synchronously in an endless loop by repeatedly calling the "CaptureFramePool_TryGetNextFrame" method until it returns a valid object pointer:

Code:

---

While pIDirect3D11CaptureFrame = 0: Call Invoke(pIDirect3D11CaptureFramePool, IDirect3D11CaptureFramePool_TryGetNextFrame, VarPtr(pIDirect3D11CaptureFrame)): Wend

---

Even if this loop only takes a few milliseconds until a new frame is available in the frame pool, it has many limitations. For example if the capture target window is closed then a new frame will never arrive and the program will be stuck in an endless loop. Using "DoEvents" inside the loop is pretty lame too.

Fortunately, the "CaptureFramePool" object exposes a "FrameArrived" event that signals the arrival of a new frame in the pool buffer so we can fetch it and go about our business. Unfortunately, this event cannot be implemented in VB6 without an adequate "TypeLib" so the solution was to create the event object from scratch (VTable and all) and then make it available with the "CaptureFramePool_AddFrameArrived" method. Apparently, "WinRT" doesn't care this isn't a true "TypedEventHandler" object, as long as it responds to the correct GUID to "QueryInterface" and it exposes the "AddRef", "Release" and "Invoke" methods, it's happy with it!

Now our capturing class can become much more responsive and implement events of its own. There's also the added benefit of detecting when the target window has changed its size or was closed by the user and react accordingly.

The capturing speed has improved a lot as well, it takes only 4-5ms on average to capture, process and render each incoming frame in a PictureBox. So the debate above about needing a WinRT "TypeLib" vs going old school with "DispCallFunc" has reached a conclusion, that is, the performance difference is definitely negligible, even though a "TypeLib" would make things much easier in the long run.

I've put the refactored project in the "CodeBank" for whoever wants to take a look: VB6 - Capture any Window, even in background, with WinRT / Windows.Graphics.Capture

Thanks again -Franky-, you've been an inspiration! :D

@VanGoghGaming Very good work. It's nice to see how an idea to make WinRT accessible for VB6 turns into a completely new and improved project. So if you need more inspiration, I have a VBC_WinRT.zip on ActiveVB where I gradually add more WinRT classes as I find the time. :D

Quote:

---

Originally Posted by -Franky-

@VanGoghGaming Very good work. It's nice to see how an idea to make WinRT accessible for VB6 turns into a completely new and improved project. So if you need more inspiration, I have a VBC_WinRT.zip on ActiveVB where I gradually add more WinRT classes as I find the time. :D

---

I've already downloaded your WinRT project a few days ago. That's exactly where I got the idea of a custom EventHandler object! ;) Man, your project is HUGE! At first I thought there was something wrong with it because VB6 takes a while to load it but if you're patient it works very well once loaded, haha!

Also I took the liberty to make a few modifications to the process of making the EventHandler objects:

- Instead of having a separate .BAS module for each one, I just use one module which holds an array of ITypedEventHandlers(0 To EVENT_HANDLERS_COUNT - 1)

- They all share the same EventHandlerQueryInterface, EventHandlerAddRef, EventHandlerRelease and EventHandlerInvoke procedures. This works well in a single-threaded environment like VB6 but I'm not so sure it would work multi-threaded when they all tried to execute a procedure at the same time, haha!

- I've changed the Object type (late-bound) to IUnknown (early-bound)

- The EventHandler objects don't need a separate IID for each one (although it certainly doesn't hurt), they work just fine with IID_IUnknown. I've seen they get queried for a bunch of different interfaces anyway (IAgileObject, INoMarshal and then some) and for each they return E_NOINTERFACE anyway.

- An EventHandler object doesn't need to hold a full reference to the object that created it (one more thing you need to destroy when cleaning up). A weak reference (like passing them ObjPtr(Me)) is enough for Callback purposes with OleInvoke.

- All of the above are just personal preferences of mine that I'd thought to share. Finally there is a little bug in the process of removing an EventHandler (or unsubscribing from it as they say).

I've seen that other programming languages, like C# for example, have specific operators for subscribing and unsubscribing from such EventHandlers ("+=" and "-=" in C#). Of course this doesn't help us much with VB6. We are stuck with manually calling the interface methods _addEventName and _removeEventName, which works just fine.

Usually the _addEventName method takes two parameters: a pointer to the EventHandler object and an "EventRegistrationToken" which is used later for removing the EventHandler.
The _removeEventName method takes just one parameter, the "EventRegistrationToken" previously obtained.

It was driving me crazy that the _removeEventName method would always fail silently. I mean OleInvoke returns zero (S_OK) but the call to DispCallFunc inside it fails with error 0x80020010 (DISP_E_BADCALLEE) which doesn't say much. Now this wouldn't bear any relevance since usually you only want to unsubscribe from such an EventHandler when you close the app but still it's a nuisance that needed to be addressed.

I've finally managed to fix it today (before writing this post) when I checked the Windows SDK header files for the definition of "EventRegistrationToken" and I've found it defined like this:

Code:

---

typedef struct EventRegistrationToken
    {
    __int64 value;
    }

---

So it seems to be a 64bit integer and we've been declaring it as "Long" all this time. Changing the declaration to "EventRegistrationToken As Currency" promptly fixed the error! Now I need to upload a new project with this fix included! :D

wanted to try the demo but I can't add the typelib for directx11.
I get an error of reference. (can't add a reference to the specified file)
anyone knows why or how to make it work? im in windows 7

The version I uploaded to the CodeBank above doesn't need any TypeLibs but Windows.Graphics.Capture requires at least Windows 10 I'm afraid...

I figure it out, the .tlb was corrupted. re-downloaded it and it works.
but I can't run the demo, I dont have the .DLL "combase"

IIDFromString can be switched to ole32
but the other 3 Im not sure.

@VanGoghGaming

Code:

---

typedef struct EventRegistrationToken
    {
    __int64 value;
    }

---

Ohhh. What a stupid mistake on my part. :eek: Of course you are right. Is an Int64 -> Currency and not a Long. Ok, Search&Replace on my project to fix the error. Thx

Quote:

---

Originally Posted by -Franky-

Ohhh. What a stupid mistake on my part. :eek: Of course you are right. Is an Int64 -> Currency and not a Long. Ok, Search&Replace on my project to fix the error. Thx

---

No worries mate, these things happen all the time when translating stuff from another language into VB6. Rock on!

Also you would need more than a "Search & Replace" since, right now as far as I've seen, your _removeEventName method calls are incorrectly using two parameters (like the _addEventName ones) instead of just one of type Currency. :)

Quote:

---

Originally Posted by baka

I figure it out, the .tlb was corrupted. re-downloaded it and it works.
but I can't run the demo, I dont have the .DLL "combase"

IIDFromString can be switched to ole32
but the other 3 Im not sure.

---

Baka, the capture process is performed by the Windows.Graphics.Capture API and that absolutely requires Windows 10, that's why you don't have a "combase.dll".

The "D3D11" part is used only for acquiring a "D3D11Surface" and transferring a "Texture2D" from the GPU to the CPU so that we can access its pixels and make a GDI bitmap that can be rendered in a PictureBox! :)

I don't know why you don't want to move on to Windows 10, you're missing out on a lot of great new features like this. I wouldn't recommend Windows 11 since that's still fairly new but Windows 10 is a very mature operating system by now and it blows Windows 7 out of the water in every possible aspect. In my opinion you're only doing yourself a disservice.

I can't move to 10 until I know 100% of all users are using it.
as long theres a % that still uses 7 I need to stay.
also, 7 is great in many ways, even if now old and outdated and lack some features.

but, its nice to see that VB6 can be used this way and still keep it up with features.
I mean, a tool created 25 years ago when windows 98 was the OS and now uses features made in windows 10/11

Yep, pushing VB6 limits like this is a wonderful thing to behold, isn't it? :D

Quote:

---

Originally Posted by VanGoghGaming

Also you would need more than a "Search & Replace" since, right now as far as I've seen, your _removeEventName method calls are incorrectly using two parameters (like the _addEventName ones) instead of just one of type Currency. :)

---

Yep, I corrected that too. There are guaranteed to be more errors in my project.

@baka: You could set up a Win10 VM or install Win10 and a Win7 VM on the PC.

At present, screenshots are a good method, and for today's OCR recognition, screenshots are the first step
OpenGL DirectX is a more advanced approach

What more advanced approach are you talking about? Got any code to show?

DirectX 11 for VB6 1.0 Type Library by wqweto

I would like an example in directx11 that can screen capture that also works in windows 7.

now, VanGoghGaming is using directx11, but also Windows.Graphics.Capture.
u mean u can do the same with only directx11?

Quote:

---

Originally Posted by baka

u mean u can do the same with only directx11?

---

I think there will be some examples on the internet. e.g. here: https://stackoverflow.com/questions/...-using-directx The example also partially uses WIC (SavePixelsToFile32bppPBGRA). You could also use GDI32/GDI+ here. The Windows.Graphics.Capture namespace simplifies the whole thing a bit and offers a corresponding GraphicsCapturePicker dialog, which can also be used to select a window or screen for recording.

Quote:

---

Originally Posted by baka

I would like an example in directx11 that can screen capture that also works in windows 7.

now, VanGoghGaming is using directx11, but also Windows.Graphics.Capture.
u mean u can do the same with only directx11?

---

Don't think so because DXGI Desktop Duplication is Win8+ feature.

cheers,
</wqw>

thx for clarifying that.
when I created my "capture" tool I used bitblt and to make use of upscaling I change that hdc into direct2d-bitmap, since I couldn't find anything in direct2d that can do that. since its based on directx11 I suspected it couldn't do it. theres other features that I can't use in windows 7, like more interpolation modes with better quality. I can just use Nearest-neighbour and linear interpolation.
for curiosity here a small code to show the "loop" that I use to capture in real-time another window and make use of direct2d interpolation instead of stretchblt/alphablend

Code:

---

Sub TheLoop()
    Dim cConverter As IWICFormatConverter
    Dim wicBitmap As IWICBitmap
    With Frm
        .running = 1
        Set wicBitmap = cWICFactory.CreateBitmapFromHBITMAP(.mem.hBmp, ByVal 0&, WICBitmapUsePremultipliedAlpha)
        Set cConverter = cWICFactory.CreateFormatConverter()
        cConverter.Initialize wicBitmap, WICPixelFormat32bppPBGRA, WICBitmapDitherTypeNone, Nothing, 0, WICBitmapPaletteTypeMedianCut
        hTarget.BeginDraw
        hTarget.Clear bcolor
        Set hBitmap = hTarget.CreateBitmapFromWicBitmap(ByVal cConverter, ByVal 0&)
        hTarget.DrawBitmap hBitmap, oRect, 1, .scaling, iRect
        hTarget.EndDraw ByVal 0&, ByVal 0&
        Set wicBitmap = Nothing
        Set cConverter = Nothing
        Set hBitmap = Nothing
        BitBlt .mem.hDest, 0, 0, .width, .height, .hdc, 0, 0, vbSrcCopy
        .running = 0
    End With
End Sub

---

You cant use the Windows 10 UWP stuff, sadly, the .NET and 64-Bit problems, I also had problems with them too, litterally open-shell start button is invisible when screenshotting with PrintWindow and BitBlt etc, so stick with it atleast if you dont want to read bare signals from a HDMI or VGA port

Yeah, good ol' "BitBlt" does a good job usually but in many cases it fails to work at all, especially with aplications that make heavy use of DirectX, OpenGL or other graphic engines. In post #8 above I presented a "PrintWindow" alternative that overcomes this annoying issue with "BitBlt" but it also requires Windows 8.1 or above and it can capture only entire windows (not just parts of them).

The advantage of capturing APIs like "Windows.Graphics.Capture" or indeed wqweto's "Desktop Duplication" is that they provide a continuous stream of frames all powered entirely by the GPU and thus taking very little CPU resources. It's also very easy to customize them for your needs. For example I have updated my previous WinRT Capture - Demo Project to include the capturing of a particular region instead of the whole window or monitor.

Capturing a whole window:

Attachment 189125

Capturing a rectangular region from a window:

Attachment 189126

Of course, "BitBlt" can also capture such rectangular regions but it wouldn't work with the "VLC Player" window from the above screenshots for example.

yes. I remember the issue when the video was rendered in a directx-surface. my "tool" was just to take a .hdc window so bitblt worked well.
I think PrintScreen (in windows 7) worked and even the windows own "printscreen" can capture that. but I dont remember 100%

the first attempt used bitblt+gdiplus
and the window I was "stealing" the screen from I use the SetParent API and after that I make the window transparent.
the reason was that that application could just do a "fullscreen" resize with no-aspect ratio setting. and that looked weird.

Also some stuff: prt sc key uses printwindow and bitblt too

Quote:

---

Originally Posted by -Franky-

Yep, I corrected that too. There are guaranteed to be more errors in my project.

---

Hey, Franky, I've decided to take this screen grab project to the next level and implement video encoding of the frames as well: VB6 - Screen Capture to Video

I've seen you haven't updated your monstrous WinRT project in quite some time now, what's up with that? :D There were quite a few missing classes necessary for video encoding (like MediaStreamSource for one) and I had to go spelunking for IIDs and VTable offsets in the dark recesses of the Windows SDK files, not fun at all! Now I've truly come to appreciate the work you've put into your WinRT classes, cheers mate! :thumb:

Quote:

---

Originally Posted by VanGoghGaming

I've seen you haven't updated your monstrous WinRT project in quite some time now, what's up with that?

---

I put the project aside for now and concentrated on the XAML controls via WinRT. I also thought that I have now shown enough how it works with WinRT. :D At least I showed how easy it is to convert videos and audio using WinRT compared to the MediaFoundation. There are already a few interfaces that are used for encoding.

No idea about MediaFoundation but yeah, WinRT is pretty straight forward once you get used to working with it.

Got anything juicy to share about those XAML controls? I thought designing user interfaces with an XML-like syntax wouldn't be very exciting, no?

You are welcome to decide whether the XAML controls via WinRT via the XAML islands are interesting. :D I have two test projects here. A calculator that doesn't calculate correctly, but shows how a surface can be designed using XAML. You simply don't have to worry about resizing the controls and font size here. Just load and compile and run the exe. I load the XAML from the RES at runtime. There is also a corresponding manifest in the RES so that this works at all. The second project is again a monster project where several ways in which XAML controls can be created are shown. However, all the events are still missing here. So that this can also be tested in the IDE, vb6.exe also needs a corresponding manifest. However, with certain controls and when you start the code a second time there is a problem and the IDE simply crashes.

First off you are an ANIMAL for doing all this work. Second, how are you able to get the 2nd big example project to compile? There are quite a few things that complain about "Programmatic ID string too long" when you run make. "ManipulationInertiaStartingRoutedEventArgs" as an example.

Quote:

---

Originally Posted by DrBobby

how are you able to get the 2nd big example project to compile?

---

Unfortunately the Monster project cannot be compiled. I test this in the IDE with the corresponding manifest for vb6.exe. Unfortunately, the class names in WinRT are sometimes very long. This page describes what must be present in a manifest for the XAML controls to work: https://learn.microsoft.com/en-us/wi...ml-islands-cpp

Yeah the length limitation in class names is a major bummer. I've had to make lots of global search-and-replace in your WinRT project just to abbreviate class names in order to get it to compile. Many WinRT functions don't work in administrator mode (when the IDE is run elevated) so I had to compile the project just to see how it works!

Quote:

---

Originally Posted by VanGoghGaming

Many WinRT functions don't work in administrator mode (when the IDE is run elevated) so I had to compile the project just to see how it works!

---

This should mainly affect the WinRT dialogs when the IDE is running in elevated mode.

This project is the most valuable ever, and if you add OPENCV image recognition, face recognition will be even better

@xiaoyao: this was already asked and answered:
https://www.vbforums.com/showthread....=1#post5603360