Re: BitBlt from minimized / not visible form ? - C# Discussion Boards

Re: BitBlt from minimized / not visible form ? [modified]

26-Nov-07 9:04

Hi there.

Developing some FF plug-in, i've finally managed to embed my c# dll into
a c++ FF plug-in template, wrote a wrapper class to access my c# functions
and members and made it so far the c# app can be run from within the
FF plugin.

Now, to display the c# app's content, i'm using BitBlt from the c# app's
HDC to bitblt to the plugin space.

Problem is: when the c# app is not visible [ e.g. minimized or hidden by another
window ], the contents of the app will no longer be bitblted to the plugin space.
[ but instead whatever is hiding the app window, or just nothing, if the app window
is minimized ]

For i want to have the app finally to be run in 'background'
[ that is, invisible to the user ] and all graphical content bitblted to the plugin
space instead [ plus mouse pointer position reported back to the invisible app, so
to 'bridge' between the app and the plugin ] it is crucial to my project that i'm
able to bitblt the app's contents to the plugin space, even it's not visible at all.

Any help on getting this done is, as always, highly appreciated.

Skippums26-Nov-07 10:05

26-Nov-07 10:05

I have spent days of man hours trying to figure this out to no avail... If you do get it to work, be sure to post your solution so the rest of us can benefit. I also figured that I will tell you another caveat that bothers me about the solution I ended up using.

I make a call to ShowWindow prior to performing the bitblt. Sometimes, if the window isn't drawn fast enough, my bitblt doesn't get the window's contents, so I have to call it multiple times to get it to work. This is really annoying, as I actually have to wait for the screen to redraw itself before copying the contents of that screen. Again, any progress you make on this should be posted here so others like us don't waste as much time as I have, and as much time as you presumably will have spent on figuring this out.

Jeff

-- modified at 16:49 Monday 26th November, 2007

gordon2427-Nov-07 4:52

27-Nov-07 4:52

Jeff, just to let you know: I surrendered.

There ARE some more or less interesting approaches to get this task done:

- Using the <control>.DrawToBitmap() method to paint each control to the target
bitmap iteratively.
This ist pretty useless for such controls, that do not implement the DrawToBitmap()
method, like ActiveX controls. [ Needless to say it's of no worth for elements
that AREN'T controls at all ... ]

- 'Abusing' the OnPaint event.
[ see here[^] ]
While this sounds somewhat interesting, it does not seem to work for everyone, plus it
did not for me :[

- Other methods, like Graphics.CopyFromScreen, BitBLTing, and so on.
All of them only capture the visible and not obscured parts of the window.

There ARE also two promising approaches i'll investigate further:

- Overriding the OnPaint() method for every control to have the graphics backbuffered,
then copy from this backbuffer.

- Using a single bitmap / image / graphics object to paint all the important
things onto, have this bitmap or a kept current public, copy from it.

I'll try the latter.

Skippums27-Nov-07 6:33

27-Nov-07 6:33

Yeah, I didn't write the code for the window I was getting the image for, so I don't think any of the other methods will work for me. Since the image is dynamic, I have to continually update by sending a showwindow message before and after capturing the image (to restore and minimize). Anyway, keep us posted on your results!

Jeff

gordon2427-Nov-07 15:48

27-Nov-07 15:48

Aaaah, JEFF.

It took me that long to figure out you also responded to my previous posts.
[ see here[^] ]

Well, i spent the day getting things working.

First of all, to pay some credit to the post / repsonse mentioned above, that snippet
didn't work 'out of the box', it had to be modified to this to get it working:

   <br />
       RECT rc;<br />
   GetClientRect(hWnd, &rc);<br />
   HDC trgDC = GetDC(hWnd);<br />
<br />
   System::IntPtr _srcDC = iForm.getHDC();  // iForm.CreateGraphics()->GetHdc();<br />
   HDC srcDC = (HDC)_srcDC.ToPointer();<br />
   <br />
   BitBlt(trgDC, 0, 0, rc.right, rc.bottom, srcDC, 0, 0, SRCCOPY);<br />
   ReleaseDC(hWnd, trgDC);<br />

This is mainly due to the C# dll delivers no HDC, but IntPtr instead, which, as you
can see above, can simply be casted to HDC. [ Which took me ages to find out. ]

"iForm" is a wrapper i wrote for the C# class in the .Net ddl i'm using:
[ This also allows me to have the class being global in C++ context, which is
impossible for 'native' managed objects. (using the /clr directive) ]

class IMEMFormWrap<br />
{<br />
private:<br />
    gcroot<IMEMForm ^>  _iForm;<br />
<br />
public:<br />
    IMEMFormWrap()<br />
    {<br />
        _iForm = gcnew IMEMForm();<br />
    }<br />
    <br />
	IntPtr getHDC()<br />
	{<br />
		return _iForm->CreateGraphics()->GetHdc();<br />
	}<br />
<br />
// (...)<br />
<br />
};

And for my 'bitblting hidden window / form / whatever to plug-in space' struggles:
Well, it did work for me using a bitmap backbuffer in the C# dll.

Everything that is of concern for the plug-in to show is cloned to that bmp object
which is then continuously grabbed from the C# dll via wrapper and bitblted to
the plug-in space.

Well, at this point, my concern is to clean up my C# .Net code,
[ making all the debug and dirty stuff go away ( 'sh*t-be-gone' (tm) ) ]
putting all useful things into a 'new' dll.

And then there's some concern about performance.
I'm glad, i know there is a LOT of space for some speed improvements in
my previous code, so i'm sanguine it can be sped up to some extend.

Plus i'll have to set up some [maybe bidirectional] communication
between the plugin and the C# dll, involving the evaluation and
reaction to user events [ mouse move and so on ].

Also, i've encountered some memory leakage in the plug-in bitblting parts ...
well, i'll also have to dive into GDI and HDC usage as well.

Still a lot of work to be done.

But, at least, things are going forward.

Skippums28-Nov-07 4:50

28-Nov-07 4:50

Yeah, I usually just import my methods using an IntPtr, so I can just send the value returned from GetHDC to the imported methods. Just to give you a heads up, sometimes the HDC returned from GetHDC will NOT function correctly with the Windows API (for me it is when I make a call to Graphics.FromImage, followed by an ExtFloodFill). In that case, you will need to call GetCompatibleDC (or CreateCompatibleDC, I don't remember which). Your current memory leak may be plugged by doing the following cleanup (I think)...

Graphics g = null;
IntPtr _srcDC = IntPtr.Zero;
HDC trgDC = null;
try {
RECT rc;
GetClientRect(hWnd, &rc);
trgDC = GetDC(hWnd);

g = iForm.CreateGraphics();
_srcDC = g.GetHdc();
HDC srcDC = (HDC)_srcDC.ToPointer();

BitBlt(trgDC, 0, 0, rc.right, rc.bottom, srcDC, 0, 0, SRCCOPY);
} finally {
if (trgDC != null)
ReleaseDC(hWnd, trgDC);
if (g != null) {
if (_srcDC != IntPtr.Zero)
g.ReleaseDC(_srcDC);
g.Dispose();
}
}

I'm glad you got it working,

Jeff

gordon2413-Dec-07 0:14

13-Dec-07 0:14

Sorry for it took me so long to respond.

Well, i'm [dead] stuck.

The method you described in your last post works well, BUT ...
it's also a 'simple' BitBLT of the form, so it suffers from all
the disadvantages linked to that [ that is, overlaying 'things'
are blted as well and nothing is blted when the form is not visible ]

My approach to bitBLT from a Bitmap object still did suffer from
memory leaks; when i tried to avoid that using a picturebox
object, all 'the known' bitblt disadvantages reappeared.

Also i noticed that every 'clone bitmap' approach doesn't run fast
enough for my project. [ let alone the need for a semaphore implementation
to manage collision-free access to such bitmap objects ]

So, i'm stuck.

I suppose, i'll end up using the app in it's own frame for now.

:[

Skippums13-Dec-07 6:41