Can SDL be used on an existing window?

Hi!

I’m writing a visualization tool in form of an activex control (ocx).
This means I’ve either got a handle to an already existing window, or,
if the control is windowless, only the container’s window handle.

I’d like to use SDL/SGE inside this control.
Can I somehow create an SDL surface from (part of) an existing window ?

I know this is very platform dependent, but maybe there’s some way to
tell the sdl win32 video drivers to do this ?

Thanks,
-Markus-

I myself wrote:

Hi!

I’m writing a visualization tool in form of an activex control (ocx).
This means I’ve either got a handle to an already existing window, or,
if the control is windowless, only the container’s window handle.

I’d like to use SDL/SGE inside this control.
Can I somehow create an SDL surface from (part of) an existing window ?

I know this is very platform dependent, but maybe there’s some way to
tell the sdl win32 video drivers to do this ?

Of course, as soon as you ask somewhere, you find the solution yourself :slight_smile:

Just found out about SDL_WINDOWID.
Part of my question still remains, can I get SDL to only draw into a
part of my window and leave the rest totally untouched (no blits, no
clears) ?

Probably it’s enough to just create a backbuffer surface and blit it
onto the container’s window at the location of the control,
but I fear SDL may UpdateRect() the entire window and cause flickering
all over the place or even destroy the window’s contents.

Thanks again,
-Markus-

I don’t know anything about this, but there’s an environment variable
that might help you. I know people have used this to embed SDL in GTK
applications and such.

SDL_WINDOWID
For X11 or Win32, contains the ID number of the window to be used by
SDL instead of creating its own window. Either in decimal or
in hex (prefixed by 0x).On Sun, Feb 24, 2002 at 10:30:29AM +0100, Markus Ewald wrote:

I’m writing a visualization tool in form of an activex control (ocx).
This means I’ve either got a handle to an already existing window, or,
if the control is windowless, only the container’s window handle.

I’d like to use SDL/SGE inside this control.
Can I somehow create an SDL surface from (part of) an existing window ?

I know this is very platform dependent, but maybe there’s some way to
tell the sdl win32 video drivers to do this ?


Mike.
You read it, you can’t unread it.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020224/6d9c66ff/attachment.pgp

Probably it’s enough to just create a backbuffer surface and blit it
onto the container’s window at the location of the control,
but I fear SDL may UpdateRect() the entire window and cause flickering
all over the place or even destroy the window’s contents.

May I take a headcount here? Raise your hand if SDL_WINDOWID EVER worked
correctly for you, on any platform.

(sound of crickets)

Don’t use SDL_WINDOWID. Use a different toolkit. If you MUST draw into
an existing win32 window (or GTK+ window, or whatever window), than use
the system-dependent API.

SDL_WINDOWID is a hack, it was never a good idea, and it should really be
removed from the library, because it never, never works the way people
hope it will.

–ryan.

Maybe a reverse way of addressing the original concern (sharing
Window between Windows application & SDL) is to create the SDL
window first, and then let your program grab the window handle.

Here is what you can do:

SDL_SysWMinfo info;
SDL_VERSION(&(info.version));
r = SDL_GetWMInfo(&info);
if (r < 0) {
    /* report the error */
}
HWND hWnd = info.window;

But really, you have to hack around a lot if you really want
to share the window. What I did is to modify the message
processing function inside SDL in order to use my own routine
to handle keyboard input with IME support.

Regards,
.paul.On Sun, Feb 24, 2002 at 07:15:36AM -0500, Ryan C. Gordon wrote:

Probably it’s enough to just create a backbuffer surface and blit it
onto the container’s window at the location of the control,
but I fear SDL may UpdateRect() the entire window and cause flickering
all over the place or even destroy the window’s contents.

May I take a headcount here? Raise your hand if SDL_WINDOWID EVER worked
correctly for you, on any platform.

(sound of crickets)

Don’t use SDL_WINDOWID. Use a different toolkit. If you MUST draw into
an existing win32 window (or GTK+ window, or whatever window), than use
the system-dependent API.

SDL_WINDOWID is a hack, it was never a good idea, and it should really be
removed from the library, because it never, never works the way people
hope it will.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I can think of some interesting designs in C++ that would allow you to
do this and would in fact work on systems that support it without
affecting systems which don’t. A sort of policy template class design
is what I have in mind. Its definitely and interesting an idea.

Like what if I wanted SDL in a canvas of a QT window or some sub-widget
contained in a window?

I don’t know that this sort of extension agrees with the philosophy of
SDL though.

DaveOn Sunday, February 24, 2002, at 03:30 AM, Markus Ewald wrote:

Hi!

I’m writing a visualization tool in form of an activex control (ocx).
This means I’ve either got a handle to an already existing window, or,
if the control is windowless, only the container’s window handle.

I’d like to use SDL/SGE inside this control.
Can I somehow create an SDL surface from (part of) an existing window ?

I know this is very platform dependent, but maybe there’s some way to
tell the sdl win32 video drivers to do this ?

Thanks,
-Markus-


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

May I take a headcount here? Raise your hand if SDL_WINDOWID EVER worked
correctly for you, on any platform.

OK I’ll raise my hand. I have gotten SDL_WINDOWID to work correctly for
me. I have integrating SDL inside a GTK window under X11. I still run into
the occassional “xlib unexpected async response” errors but I think this
because I haven’t fully mutex locked SDL/GTK drawing access.

John.

Probably it’s enough to just create a backbuffer surface and blit it
onto the container’s window at the location of the control,
but I fear SDL may UpdateRect() the entire window and cause flickering
all over the place or even destroy the window’s contents.

May I take a headcount here? Raise your hand if SDL_WINDOWID EVER worked
correctly for you, on any platform.

Works for me, and the way I expect too ;).

DaveOn Sun, 24 Feb 2002, Ryan C. Gordon wrote:


David MacCormack
@David_MacCormack

:wq
damn!

May I take a headcount here? Raise your hand if SDL_WINDOWID EVER worked
correctly for you, on any platform.

i did some testing once with SDL and wxWindows on windows. it worked
great from what i tested. actually this was all in python, so it was
really pygame and wxpython. nevertheless, i’d assume it works in
straight C since all it required was setting the environment var.